> genuine question - why was this code pushed now

Zuckerberg has aggressively been bribing politicians to enact this at the State level.

Several news stories about it though you have to search for terms like 'lobbying' and 'Meta' as fig leaves.

They had to say it that way, because the more accurate statement is that the dealership law unfairly advantages existing automakers. It's not about the dealerships being good or bad, it's about the fact that setting up a dealership network takes a lot of time and money and requiring it is a good way to keep new competition out.

The correct term is "regulatory capture". Private businesses use the power of the state to protect, subsidize or otherwise benefit them and harm competitors and potential competitors. It's extremely common and the more pervasive the regulation is, the more common it is. Red tape and government procedures benefit entrenched players who have built the institutional structures and knowledge to deal with them.

This isn't to say that all regulation is bad... but a lot of it is. There was never any consumer benefit to banning direct sales. All regulations should be thoroughly scrutinized for their effects on the market, direct and indirect.

The problem you get though is what I call the "California Cancer Warning Problem"
Basically, people can only pay attention to so many warnings. The more often people get false or trivial warnings, warnings where they have to continue to get things done as standard, the more likely they are to just plain ignore the warnings.

While hackers might be able to figure out a way to do something malicious without triggering the warning, the warnings back then were worse than useless, because they not only triggered for just about every document, users by default could not assess the document for safety without enabling the scripting. IE I couldn't by default open the document and look at the scripts to assess them (and some of them were only like a dozen lines) without enabling them.

Saying the warnings were necessary also ignores that there have been exploits that didn't even require opening a document to cause infection. Preview was enough.

Basically, if the hackers figured out something clever, just add that to the check. It would still be a better situation than what we had back then.

I thought exactly the opposite. I think Rocky is far too "human". I didn't mind it, though, because a lot of the humor would be lost if Rocky was properly alien.

I think that's necessary. Providing explanations of depth comparable to the book would require a 10-hour movie. Squeezing the story down to feature length requires cutting a lot of exposition. In many books there's a lot of description that can be replaced with visuals, but it's pretty hard to do that with a lot of the science.

I'm sure you'd have said the same about Y2K. It's a good thing that some people have more foresight.

I think you're describing the models from a year ago. Most of the improvements in capability since then (and the improvements have been really large) are directly due to changes that have the AI model talk to itself to better reason out its response before providing it, and one of the results of that is that most of the time they absolutely can explain why they did what they did. There are exceptions, but they are the exception, not the rule.

It's interesting to compare this with humans. Humans generally can give you an explanation for why they did what they did, but research has demonstrated pretty conclusively that a large majority of the time those explanations are made up after the fact, they're actually post-hoc justifications for decisions that were made in some subconscious process. Researchers have demonstrated that people are just as good at coming up with explanations for decisions they didn't make as for decisions they did! The bottom line is that people can't really provide useful insights on why they did what they did, they're just really good at inventing post-hoc rationales.

If you're asserting that Greg Kroah-Hartman can't code worth a damn, you might want to find out who he is and think again.

And the law of large numbers. Statistically, there will but patch clusters, the same way there are clusters of every other random-ish event. The fact that one happens to occur right after Microsoft promises a commitment to predictable patch schedules means not just nothing the but opposite. Any commitment to doing better means that they recognize they haven't been doing well enough, and obviously it's not possible to do significantly better immediately; changing processes takes time, and observing the effects of those changes takes even longer.

So, no, this cluster of patches doesn't tell us anything in particular beyond what we already knew: That emergency patches are relatively common.

Yes, but... I think you're confusing some things. We're talking about AES, which is a symmetric encryption algorithm, not asymmetric.

Of course, no cryptographic construction has been "proven" secure, in the sense that mathematicians use the word "prove", not symmetric or asymmetric. Asymmetric schemes have an additional challenge, though, which is they have to have some sort of "trapdoor function" that mathematically relates a public key and a private key, and the public key has to be published to the attacker. Classical asymmetric cryptography is built by finding a hard math problem and building a scheme around it -- which means that a solution to the math problem breaks the algorithm.

Symmetric systems have it a bit easier, because the attacker doesn't get to see any part of the key or anything related to the key other than plaintext and corresponding ciphertext (though the standard bar is to assume the attacker has an oracle that allows them to get plaintext of arbitrary ciphertexts, i.e. the Adaptive Chosen Ciphertext attack, IND-CCA2). And the structure of symmetric ciphers isn't usually built around a specific math problem. Instead, they tend to just mangle the input in extremely complex ways. It's hard to model these mathematically, which makes attacking them with math hard.

In both cases, we are unable to prove that they're secure. When I started working on cryptography, the only basis for trust in algorithms was that they'd stood up to scrutiny for a long period of time. That was it. Over the last 20 years or so, we've gotten more rigorous, and "security proofs" are basically required for anyone to take your algorithm seriously today... but they aren't quite like "proofs" in the usual sense. They're more precisely called "reductions". They're mathematically-rigorous proofs that the security of the algorithm (or protocol) is reducible to a small set of assumptions -- but we have to assume those, because we can't prove them.

For most asymmetric schemes, the primary underlying assumption is that the mathematical problem at the heart of the scheme is "hard". Interestingly, there is one family of asymmetric signature schemes for which this is not true. SLH-DSA, one of the post-quantum algorithms recently standardized by NIST, provably reduces to one assumption: That the hash algorithm used is secure, meaning that it has both second pre-image resistance plus a more advanced form of second pre-image resistance. Collision resistance isn't even required! This is striking because we actually have quite a lot of confidence in our secure hash algorithms. Secure hash algorithms are among the easiest to create because all you need is a one-way function with some additional properties. And we've been studying hash functions very hard, for quite a long time, and understand them pretty well.

This means that one of our "new" post-quantum asymmetric algorithms is probably the very strongest we have, not only less likely to be broken than our other asymmetric algorithms, but less likely to be broken than our symmetric algorithms. If it were broken, it would be because someone broke SHA-256 (which, BTW, would break enormous swaths of modern cryptography; it's extremely hard to find a cryptographic security protocol that doesn't use SHA-256 somewhere), and unless that same research result somehow broke all secure hash functions, we could trivially repair SLH-DSA simply by swapping out the broken hash function for a secure one.

This is an entirely different model from the way we looked at cryptography early in my career. SLH-DSA doesn't have decades of use and attack research behind it. Oh, the basic concept of hash-based signatures dates back to the late 70s, but the crucial innovations that make SPHINCS and its descendants workable are barely a decade old! BUT we have a rigorous and carefully peer-reviewed security proof that demonstrates with absolute mathematical rigor that SLH-DSA is secure iff the hash function used in it is secure.

So... a relative newcomer is more trustworthy than the algorithms we've used for decades, precisely because we no longer rely on "hasn't been broken so far" as our only evidence of security.

As for AES, the subject of the discussion above, there is no security proof for AES. There's nothing to reduce it to. There are proofs that it is secure against specific attack techniques (linear cryptanalysis and differential cryptanalysis) that were able to defeat other block ciphers, but those proofs only prove security against those specific attacks, not other attacks that are not yet known. So for AES we really do rely on the fact that it has withstood 20+ years of focused cryptanalysis, and that no one has managed to find an attack that significantly weakens it. That could change at any time, with or without quantum computers.

SLH-DSA, however, is one that very well may be secure forever, against both classical and quantum attacks. The security proof doesn't even care about classical vs quantum, it just proves that any successful attack, no matter how it's performed, provides a way to break the underlying hash function. Therefore, if the hash function is secure, SLH-DSA is secure. It's an incredibly powerful proof, like many proofs by contradiction.

I’d argue that slavery wasn’t “legal because nobody banned it.” It was legal because there were explicit laws that created, defined, and enforced the institution.

There were statutes specifying who could be held as slaves, rules that the child of an enslaved woman was automatically a slave, procedures for manumission, regulations on how slaves could be bought, sold, punished, or inherited, and laws requiring that escaped slaves be returned. That’s not a legal vacuum, that’s a full legal framework.

It’s similar to how segregation laws later forced discrimination on people who might not have engaged in it otherwise. The state wasn’t passively allowing something; it was actively mandating and structuring it.

Slavery existed because the law built and maintained it, not because the law failed to forbid it.

I remember those days where it would warn if there was any scripting at all, rather than look for dangerous commands first.
Just as a thought, not bothering if the script cannot reach outside of the document itself. Functions that access other files or documents, email functionality, and such triggering the warning instead would have been more effective.

An exception is the Zeropatch technique where they dynamically update machine code of the OS in memory on the fly for folks who can't tolerate downtime.

It's certainly not common on unix systems.

Or an IoT device running a 2.6 kernel that is never going to be updated. :)

Did Dolby break any countermeasures of Snap's copyrighted code in what would appear to be a significant reverse-engineering effort to make this determination?

Or do they only have a suspicion?

This scenario reminds me of the SCO lawsuits when the progress of technology made that company obsolete.