Frontier AI folks may be crazy, but not crazy enough to believe people read usage policies :-)

In the industry, transmission and distribution losses are called T&D losses. Pretty much all unaccounted losses will be written off as T&D losses. Often the right expansion for T&D losses is Theft and Decoity losses :-)

They sincerely welcome your vulnerability disclosures, except in cases where you have to "interact" with the device/service or download its data. Other than that TINY carveout, everything is okay.

Oh, if the vuln about configuration and hardening "preferences" like SSL/TSL - Sorry, not interested.

And also, infrastructure vulnerabilities like DNS config - no no, try harder.

I know what you're thinking..ha ha...but we are good guys. You can still report vulnerabilities in the above categories, but the onus is on you to convince us that we should care about them. It is only fair.

https://www.flocksafety.com/legal/vulnerability-disclosure-p...

People who have never known about Libre Office are now downloading and using Libre Office (often without realizing it).

https://news.ycombinator.com/item?id=49527396

Depreciation and write-offs are about accounting models. Hardware will still be running after five years and still be making money. They may not be as efficient as the new hardware, but they will still be making real money even though they are valued at $0 in the books.

As someone who has been implementing such systems for 20 years, I don't buy this. In my mind, it's equivalent to saying "Seatbelts add complexity to the safety system, and it's more work. So let's get rid of it."

In this argument, the benefits of hybrid/seatbelts are not factored in adequately.

Considering that this is an election for a professional organization with thousands of members, I am going to go out on a limb and say that it should be easily possible to assemble a group of 5 people that the community/board trusts woudn't largely collude to break their privacy. If I were in the room, I would have advocated for 3 of 5 quorum.

But the lifecycle of the key is only a few months. That limits the availability risk a little bit, so I can be convinced to support a 2 of 3 quorum, if others feel strongly that the incremental privacy risk introduced by 3 of 5 quorum is unacceptable.

- Availability is a security requirement. "Availability" of critical assets just as important as "Confidentiality". While this seems like a truism, it is not uncommon to come across system designs, or even NSA/NIST specifications/points-of-view, that contradict this principle.

- Security is more than cryptography. Most secure systems fail or get compromised, not due to cryptanalytic attacks, but due to implementation and OPSEC issues.

Lastly, I am disappointed that IACR is publicly framing the root cause as an "unfortunate human mistake", and thereby throwing a distinguished member of the community under the bus. This is a system design issue; no critical system should have 3 of 3 quorum requirement. Devices die. Backups fail. People quit. People forget. People die. Anyone who has worked with computers or people know that this is what they do sometimes.

IACR's system design should have accounted for this. I wish IACR took accountability for the system design failure. I am glad that IACR is addressing this "human mistake" by making a "system design change" to 2 of 3 quorum.

But it is not a uniquely free software world problem. It is there in the industry as well. But the marketplace serves as a reality check, and kills egregious cases.

[1] Granted, "Political non sense" is a dual-purpose skill. In our context, it can be used both for "defending simplicity", as well as "resisting meaningful progress". It's not easy to tell the difference.