I would still consider them patent trolls at this point. Legitimate patent holders use patents immediately or hold them to use defensively. They do not sit on patents for an entire decade, waiting for the patented technology to be ingrained in the industry, and then use them to earn income. The patent having been created in-house rather than acquired doesn't change the fact that the behavior is fundamentally similar.

Dolby Atmos was 2012. Dolby Vision was 2014. How are they not basically a non-practicing entity at this point?

Yes, but using them offensively after sitting on them violates the doctrine of Laches. In effect, they sat on the patents so that people would end up depending on AV1, because if they sued too early, AOMedia would have designed around the patent, and they would get nothing. So they deliberately delayed action to cause prejudice to the defendant.

At this point, it would be entirely reasonable for a judge to declare that because they failed to act against AOMedia within the 6-year window prescribed by patent law, they lost their right to sue AOMedia for damages in creating the patented technology, and that patent exhaustion applies to all downstream users. And if that happens, I will laugh so hard.

Dolby is not a startup. It was founded in 1965.

Also, the doctrine of Laches says you cannot unreasonably delay filing a lawsuit. Waiting ten years from the first release of the specification is clearly unreasonable. Waiting eight years from the first finished implementation is clearly unreasonable.

The bigger problem for Dolby is that patent law won't let you recover damages at all for damages more than six years ago, and the standard has been available for eight. So unless somehow this is some wacky patent where Dolby claims that some use of an otherwise non-patent-protected codec is patented (which should almost certainly result in that patent getting overturned for obviousness), Dolby should be laughed out of court.

But I'm sure they're hoping that Snapchat caves and agrees to go back to a Dolby codec or pay them royalties rather than fight them in court. This is patent troll behavior. Dolby has effectively become a patent troll, IMO.

From a patent law point of view, it is illegal to create something that violates a patent, not just to use it. Patent law kicks in when you create, offer for sale, sell, import, or otherwise distribute a patented invention.

IMO, one of the biggest flaws in patent law is that it covers the use of inventions in all cases except for patent exhaustion (sale of an already-licensed product). With the exception of pure process patents, IMO, that should not be a violation, as a user has no realistic way of knowing that something they bought violates someone else's patent, and should not even need to worry about such nonsense.

This "feature" of patent law exists solely to give the patent holder more leverage to screw the company accused of violating the patent by holding their innocently infringing customers liable, causing irreparable reputational damage to both companies, irreparable harm to countless others, etc., and it should have been eliminated decades ago.

That said, having seen this behavior by Dolby, I hereby vow to never knowingly buy any product that they manufacture, nor support their products or technology, nor use it except in situations where the content creator or distributor leaves me no alternative. They've gone from being a legitimate technology company to a glorified patent troll. Instead of innovating and making the world better to enrich themselves, they are suing anybody and everybody and making the world worse to enrich themselves.

Moreover, absent gross incompetence by Dolby's legal counsel, it seems clear that Dolby flagrantly and willfully violated the doctrine of Laches to allow damages to accumulate for eight full years from the final release (and ten years from the first specification release), thus allowing AV1 to become the dominant codec so that they could then predatorily use their patents to squeeze money out of the industry. Their behavior is nothing short of unconscionable, and whether due to incompetence or malice, their legal counsel should be formally sanctioned for it.

Finally, if Dolby wins, it is paramount that the entire technology industry agree to never license *any* future Dolby technologies going forwards, because doing so will only encourage them to use the patent system to prevent free and open standards. The only way to prevent patent abuse is to stop feeding the companies that abuse patents.

It is my fundamental believe that data formats should not be allowed to be protected by copyright or patents under any circumstances, because doing so fundamentally violates the rights of the owners and creators of that content. It makes it so that users can potentially lose access to data that they created. And this is wholly unacceptable for the same reason that renting software is unacceptable.

In short, Dolby and its lawyers can go f**k themselves with a shovel.

If Putin had been around, he'd have been in the Epstein files, too. It's vanishingly-unlikely that any strongman like that wouldn't also be a sexual abuser. It's all part of the same disrespect for others.

Linux has a large number of highly-paid developers. If you look at the kernel, specifically, there are basically no unpaid volunteers contributing significantly to it, and there haven't been for a long time. The right way to understand kernel development is as a collaboration between a large number of corporations, each of whom contributes the paid work of skilled engineers and most of which also contribute cash to a foundation that employs the highly-paid engineers who coordinate all of the work (notably Linus, who makes a seven figure salary -- honestly, ought to be eight figures, but he's certainly not hurting).

If you look beyond the kernel to the other tools and desktop environments, the volunteer participation rises significantly, but there's also a lot of paid work.

You cannot possibly know that.

This seems plausible, but it implies that you cannot possibly know whether we're going to get AGI this century. If it's true, it means that we'll get AGI when we discover that as-yet-missing knowledge, and there's no way to predict when that might happen. It might have happened yesterday and we just don't know it yet. What is certain is that (a) the knowledge exists and (b) we're looking for it, really hard.

Y2K is a better example. Y2K could have been a castrophe. A decade before it happened we started working to fix all the systems. Hundreds of millions of dollars (maybe billions) were spent on Y2K remediation. Then Y2K came and... nothing much happened. Lots of people pointed and said "Haha! All that money spent fixing the problem was a waste!", but they were wrong. All of the money spent fixing the problem fixed the problem.

This is what we have to do with cryptography and quantum computers. If we wait until practical QCs arrive, we'll be in big trouble. Not only will it take years to replace all of the classical crypto infrastructure, so we need to do the work before the QCs arrive, there are some cases where there will be no possibility of remediation. There are two major categories:

1. Harvest-now-decrypt-later (HNDL). Any cases where data needs to be protected for decades is subject to attacks that involve storing the data now and holding it until quantum computers can decrypt it. We undoubtedly have a lot of data that is already stored for later decryption, but we want to avoid increasing that risk further.

2. Hardware trust. Secure hardware requires trusted firmware, which requires burning public keys and verification algorithms into ROM, and many of these devices will be in service for decades. So we need to be able to deliver secure firmware updates for decades, using keys and algorithms we burn into ROM now. This is particularly relevant to me, because I'm working on firmware for automobiles, which have a 5-year development window, and a ~20-year (or more!) service life. So I'm working on systems that need to be securable through 2051, and it's pretty important because these vehicles have some degree of self-driving capability. A vulnerability that enables mass compromise and takeover could be used to mount a horrific terror attack.

So, yes, this matters. Probably. It's possible that practical quantum computing will never emerge, but given the tremendous progress over the last few years, that seems like a bad bet. Google's 2029 target is wise.

These statements are too strong -- in both directions!

First, although Grover's algorithm is proven to be the optimal quantum algorithm for generalized search, you don't necessarily need a generalized search algorithm to break a block cipher. Block ciphers have internal structure that may be exploitable by quantum algorithms. Indeed researchers have made some progress in designing quantum algorithms to break Feistel network-based ciphers (which AES is not, but the previous standard cipher, DES, is). The result of that work, Simon's algorithm, is not a practical way to break Feistel network ciphers, but more research may improve it. So it's certainly possible that researchers could identify AES substructure that can be attacked with quantum computers, and this could result in a quantum algorithm that breaks AES. We have no hint of anything like that, and no one is really considering it to be likely, but "quantum resistant forever" is too strong.

Second, the claim that QCs get you a halving of the bits for block ciphers using Gover's algorithm is technically correct, but overstates the practical reality. Even assuming we had large, reliable and cheap quantum computers, the way Grover's algorithm would be applied to breaking AES requires 2^(n/2) sequential operations, each of which is a non-trivial quantum circuit. Moreover, other practical considerations, which are way too complicated to get into here -- in large part because I don't really understand them; I'm repeating what more-knowledgeable colleagues say here -- mean that AES-128 will probably retain ~90 bits of security, which means it will probably remain secure forever, assuming no better-than-Grover's algorithm exists.

No.

What was shown is that one random number generation algorithm was found to have been backdoored at the NSA's request. There is no evidence that this has ever happened with any of the other NIST-standardized algorithms, and it's also known that the NSA has stepped into strengthen other NIST algorithms (notably, DES -- though the the NSA both strengthened that by improving the S boxes and weakened it by asking for a smaller key size, though that wasn't a secret weakening; everyone understands the implications of smaller key sizes, and where necessary there are easy workarounds, hence triple-DES, which is still secure today).

All of this was in the past when the NSA held a considerable lead in cryptographic knowledge over academic cryptographers. It seems very unlikely that this is the case any more, and in fact at this point basically all novel cryptographic knowledge seems to be flowing in the other direction.

The only other case that people do wonder about a little bit is the choice of the elliptic curves used for ECDSA and ECDH. NIST never published any rationale for those curve choices, or any publicly-verifiable information about their choices. Most likely this is because there was no systematic choice process; they chose curves at random, verified their security properties and went with it, but it's possible that these specific curves have some internal structure that the NSA knows about and can exploit, but the rest of the world doesn't. After decades of fruitless scrutiny this isn't likely, but it's possible, which is why Daniel J. Bernstein ensured that his Curve25519 did have a clear, rational and publicly-verifiable construction process, and that's part of why many systems prefer Ed25519 and X25519 over ECDSA and ECDH (Curve25519 is also faster and has smaller public keys).

In the case of the PQC algorithms, all of them were created by academic cryptographers, and there are no suspicious modifications. So if the NSA has backdoored them they've done it really, really subtly. IMO, it's not a risk worth worrying about unless you're specifically defending against the NSA, and probably not even then. For commercial work, like I do, it's sufficient to trust that if the NSA is smart enough to have learned from the Dual_EC_DRBG debacle. In that case, not only did the backdoor eventually come out fully, along with evidence that the NSA had paid at least one company to use that algorithm, academic cryptographers suspected its existence even before the standard was published, and spoke publicly about it. That was probably what motivated the NSA to pay for its use, since it was under a cloud of suspicion from the beginning. So it was a very foolish move by the NSA, driven by extreme and obviously unjustified overconfidence in their lead in cryptographic knowledge.

This isn't true.

Yes, one of the finalists was broken, utterly. There are no successful attacks against ML-DSA, ML-KEM or SLH-DSA, and they have good security proofs. Note that "successful attack" and "security proof" both have different meanings to cryptographers. A successful attack is one that reduces the security even a little from what it theoretically should be, even if the reduction still leaves the algorithm completely unbreakable in practice. A security proof is a proof that the construction is secure if the underlying primitives satisfy security assumptions. There is no cryptographic algorithm in existence that has a security proof that a mathematician would consider to be a proof; we just don't know how to do that. In the case of ML-DSA and ML-KEM, the underlying assumptions are about the hardness of the underlying mathematical problems, Module-LWE and Module-SIS. In the case of SLH-DSA the underlying assumptions are about the security of hash algorithms.

Module-LWE and Module-SIS are fairly new problems, and have only been studied for a little over a decade. The whole field of mathematics they're based on is less than 30 years old, so it's more likely that some mathematical breakthrough will destroy their security than it is that some breakthrough will wipe out ECC, which has been studied for about 50 years, and which builds on 150 years of algebraic geometry. Still, a mathematical breakthrough could destroy ECC or RSA, too.

In contrast SLH-DSA is rock solid, from a security perspective. We've been studying hash functions for a long time, and, really, our entire cryptographic security infrastructure is based on the assumption that our hash functions are good. If that turns out not to be the case, then quantum computers will be the least of our problems because to a first approximation every cryptographic protocol in existence relies on secure hashing. It's far more likely that ECC or RSA will be broken than that SLH-DSA will be broken. Unfortunately, SLH-DSA is orders of magnitude slower than what we're used to.

It's worth noting that SIKE (the NIST PQC finalist that was broken) also had a security proof. The problem was that the proof showed that SIKE was secure if the supersingular isogeny problem was hard -- but what SIKE actually used wasn't that problem, exactly. SIKE required additional data to be published, and that additional information reduced the hardness of the problem. This is why the break was so total, and was found immediately when researchers began scrutinizing SIKE. All it took was the observation that SIKE relied on a less-hard problem, then a mathematical solution to the less-hard problem.

NIST chose these three algorithms for good reasons. ML-KEM and ML-DSA have larger keys than we're used to with RSA and especially ECC, but they're not that much larger, not so large that they simply can't be used in existing protocols. And they're fast, with performance on par with what we're used to. So they are feasible drop-in replacements in most cases.

SLH-DSA is not a drop-in replacement. The keys are very small (on par with ECC, a bit smaller, even), but the signatures it produces are enormous: the smallest is 8k, the biggest is 50k (depending on parameter choices). Also, signing is 50-2000 times slower than EC-DSA (depending on parameter choices) and verification is 10-30 times slower.

So, what NIST did was choose a pair of quite-usable and probably-secure algorithms (ML-KEM and ML-DSA) that cover all cryptographic needs and are very close to being drop-in replacements, plus a less-usable but absolutely-secure algorithm as a backstop. I don't know that they ever explicitly stated the strategy they were suggesting, but it's obvious: Use ML-KEM and ML-DSA as your everyday algorithms for operational security and for firmware signing, but for firmware signing specifically, burn an SLH-DSA public key into your devices that you can use to verify new firmware and new public keys that use new algorithms in the event the ML- algorithms are ever broken.

I don't think so, and neither does Google -- which employs a lot of professional academic cryptographers (which I'm not).

Whether you should move to these algorithms depends on what you're doing, and what your service lifetimes are. If the data you're encrypting or signing only needs to be secure for a decade, don't bother. Existing ECC-based constructions will be fine.

If the data needs to be secure for more than that, if you're really concerned about harvest-now-decrypt-later attacks that could be performed 20-30 years from now, you should move to ML-KEM, and do it soon. There actually isn't that much data that really needs to be secure for that long... but if yours is in that category it's more likely that it will still be secure in 2050 if it's encrypted with ML-KEM/AES than if it's encrypted with ECDH/AES. Both options are a gamble, of course. ML-KEM is more likely to fall to a cryptographic attack than ECDH, but ECDH is at risk from quantum computing.

Firmware signing is a very interesting case. Firmware security is foundational to system security. Phones today are expected to have an ~8-year lifespan, so a phone launched in 2029 needs to remain secure until 2037... and that is getting into the range where there's a non-trivial probability that quantum computers will be large enough, reliable enough and cheap enough to be a threat. That probability is only in the 1-5% range (IMO), but in the cryptographic security world 1-5% is utterly unacceptable. I work on automotive firmware these days (I left Google six months ago) and we have ~5 year development timelines, followed by 20-year operational timelines, so a project we start today needs to be secure until 2051. The probability of large, reliable, cheap quantum computers by 2050 approaches 100%.

On the other hand, can your hardware really accept a ~20X longer firmware verification time from using SLH-DSA? That's not a question with a universal answer. Some contexts can, some can't. ML-DSA is more computationally-practical, but there's a risk that it will be broken. I think the clearly-appropriate strategy for now is: Ship your hardware with ML-DSA verified firmware, but also burn an SLH-DSA public key into the ROM (or OTP fuses) and arrange things so you can use that SLH-DSA public key to verify and install a new firmware verification scheme in the future, should ML-DSA be compromised. Or, alternatively, stick with EC-DSA or Ed25519 for now, but include that same SLH-DSA-based infrastructure for migrating to something else. If your hardware lifetime is long enough, you almost certainly will have to actually use that to migrate to some PQC algorithm. If feasible, it would be better to start with ML-DSA now.

CPU performance. Now compare GPU performance against a PC built out with eight GPUs to do parallel 3D rendering.

The trash can was thermally limited by its design, and could never be upgraded to hold newer CPUs or GPUs. Anyone for whom the trash can Mac Pro would work could just as easily use an Apple Studio, give or take, ignoring the lack of ECC (which the Apple Silicon Mac Pro also lacked).

Depends on what you mean by covered. Can they do their work? Yes. Are they negatively impacted by hardware limitations? Also yes. A lot of professionals would be willing to pay extra for ECC. The fact that Apple doesn't offer ECC makes their machines less than ideal for use cases where a crash would be expensive. The fact that a lot of pros put up with crashes doesn't mean they like the situation. It just means that they dislike it less than switching platforms and tools.

But the pro users I was specifically talking about here are the ones doing high-performance computing tasks involving GPUs. Their only real option is to change platforms, because even though the new Apple Silicon CPUs are great in terms of performance per watt, the wattage is really low, so if you genuinely need boatloads of GPU, to the extent that Apple was still in the game without NVIDIA support, they completely dropped out of the game when Apple Silicon dropped support for AMD. At that point, Apple computers became nearly useless for most modern high-performance computing/AI workloads, people doing large-scale 3D video rendering, etc., because they're underpowered as shiped and can't be expanded with more GPUs, and parallelizing work across multiple machines is way more expensive and not always practical.

The historical definition of "pro" is people who are running software beyond what a typical user would run. Web browsers and productivity software (word processors, spreadsheets) are not pro apps; they are business apps. Pro apps are mostly things like high-end photo editing (think Photoshop/Pixelmator, not iPhoto/Capture One), 3D modeling, audio/video production, etc.

Developers at least arguably fall into that category, though they are borderline, because they don't have huge storage requirements or huge compute requirements. Developers can do most of their work on laptops, though Apple's non-Pro laptops are pretty thermally throttled, so they will be miserable. And developers are probably the group who care most about ECC RAM, because they understand enough to know why it matters, but they still often use laptops because they don't want to be tethered to a desk. It's a tradeoff.

No, and they never were. While the users might have professional occupations, their computing requirements are indistinguishable from a high school student. "Pro" in this context doesn't mean "users with money". It means "users with needs that exceed typical requirements". :-)

A truly non-lazy person, then, would have to conduct a detailed spectrographic assay of all of the pipes (or at least sufficient samples from each lot) to accurately determine the precise composition of each, because all of them contain impurities and aren't merely copper and phosphorous.

In general, getting a truly pure sample of almost any element is incredibly-hard, and outside of laboratories (and even in laboratories, most of the time) it just doesn't matter. In the case of transporting anti-protons, standard "pure" copper is apparently inadequate, because it's not pure enough.

Grok was constantly say it was doing something that it had ZERO ability to, and I kept calling it out and it kept apologizing and then immediately doing it again.

As a guy who spend 5 figures a year on Ai, the last thing I want is that. I know Claude and ChatGPT also do it, but Grok was doing it CONSTANTLY.

Oh. Today I learned that FCP regained live multicamera switching support in 2024... four years after everybody stopped caring and started using OBS, vMix, or Tricaster.