Publishing “Cryptographic Right Answers” for developers is a tradition by now. Colin Percival started in 2009, Thomas Ptacek followed up in 2015, and then Latacora carried on in 2018 and 2024.

It might feel too soon for an update, but so much has changed. The timeline of the post-quantum transition dramatically shifted in early 2026, and there is now consensus that it needs to complete by 2029. 2029! We have three years!

The good news is that, despite what you might have heard, symmetric cryptography is going to be fine, because Grover does not matter. The bad news is that all asymmetric answers changed compared to 2018 and most even compared to 2024.

The answers below assume you are not constrained by any specific compliance regime, although they are mostly compatible with FIPS 140.¹ If you need to follow something stricter like CNSA 2.0, you’ll know. Just substitute as appropriate.

Finally, remember the other big change of 2026: LLMs are very good at finding bugs now. “Get a review from the best model you can afford” is now firmly a Cryptographic Right Answer, along with the long-time classic “use a memory-safe language.”

If you’re in a rush, here’s the cheat sheet:

• Encrypting data: If you’re in the cloud, KMS. Otherwise, XAES-256-GCM or XChaCha20Poly1305 with random nonces. If you’re encrypting more than a few MB, use Cobblestone-128.
• Symmetric key length: Don’t stress it. 256-bit keys if you need to pick.
• Symmetric “signatures”: HMAC-SHA-256.
• Hash algorithm: SHA-2 is still fine, but use a real multihash (SequenceHash) if needed.
• Random IDs: 32 random bytes, a.k.a. 256-bit random numbers.
• Password handling: Argon2id or scrypt. But have you considered passkeys instead?
• Key exchange: X25519+ML-KEM-768 in a secure, standard protocol.
• Asymmetric encryption: HPKE with (MLKEM768-X25519 a.k.a. X-Wing, HKDF-SHA256, AES-128-GCM), or age with PQ keys.
• Asymmetric signatures: ML-DSA-44.
• Website or client-server application security: If you’re in the cloud, use its ALB/NLB. Otherwise, rustls, Go’s crypto/tls, BoringSSL, AWS-LC, or s2n-tls with a popular, updated ACME client.
• Online backups: restic with a long random password.

Now let’s dive in.

Encrypting data

If you’re in the cloud, KMS. Otherwise, XAES-256-GCM or XChaCha20Poly1305 with random nonces. If you’re encrypting more than a few MB, use Cobblestone-128.

Percival, 2009: AES-CTR with HMAC.
Ptacek, 2015: NaCl/libsodium default, or ChaCha20Poly1305, or AES-GCM.
Latacora, 2018: KMS, or XSalsa20+Poly1305.
Latacora, 2024: KMS, or NaCl’s secretbox, or XChaCha20Poly1305.

Latacora’s reasoning for why and when you’d use your cloud’s KMS is still solid, so start there.

If you’re encrypting locally, you want an AEAD where you can avoid worrying about tracking nonces or how many messages you encrypted, so you want random nonces of at least 128 bits.²

NaCl/libsodium’s secretbox is just a paper-thin wrapper around a less common AE construction (XSalsa20+Poly1305), so instead I recommend XAES-256-GCM or XChaCha20Poly1305. The former is an efficient composition of a standard KDF and AES-GCM, packaged as an extended-nonce AEAD, so even if your library doesn’t provide it under that name you can assemble it from the KDF and AES-GCM APIs.³

Regular AES-GCM and ChaCha20Poly1305 with random nonces are only ok if you know for certain you won’t encrypt more than a billion messages with one key. AES-GCM-SIV is also a good AEAD choice if you happen to have it everywhere you need it, but that’s kinda unlikely. Some even newer options have nice properties like key commitment, but are not commonly available yet.

Since you have an AEAD, consider putting context in the additional data, like the user ID you’re encrypting for, or the version of the protocol. Anything not secret that you will definitely still know at decrypt time.

Very important is how you handle large messages, which KMS will not solve for you. Do not pass one large message to an AEAD, or you might be forced to process or store the plaintext before having authenticated it at decrypt time. Absolutely do not use unauthenticated stream ciphers. Instead, you should use STREAM (which is not a stream cipher but a way to use AEADs on a stream… I know, I know, terrible name). There are a lot of options—too many, in fact—and shamefully none are the consensus answer. Tink has one, libsodium has one, the AWS Encryption SDK has one, FLOE is one, age has one, and the list goes on. I recommend Cobblestone-128, which is a STREAM variant derived from TLS, and is available in pyca/cryptography and soon in the Go standard library (and in the meantime at filippo.io/cobblestone).⁴

Avoid: unauthenticated modes (CBC, CTR, raw stream ciphers), random 96-bit nonces unless you spent a lot of time thinking about how many messages you encrypt, rolling your own AEAD construction.

Symmetric key length

Don’t stress it. 256-bit keys if you need to pick.

Percival, 2009: 256-bit AES keys.
Ptacek, 2015: 256-bit keys.
Latacora, 2018: 256-bit keys.
Latacora, 2024: 256-bit keys.

Remember that Grover doesn’t actually matter and 128-bit brute-force attacks don’t exist. Still, 256-bit keys rule out multi-target attacks, which is nice.

However, don’t make other decisions based on this. For example, the recommended Cobblestone suite uses 128-bit keys and that’s fine because it has a careful analysis of multi-target attacks. Likewise, don’t go changing the default cipher suite preferences of your TLS library to enforce 256-bit keys; there’s no need.

AES-256 is slower than AES-128 because unfortunately Rijndael ties the number of rounds to the key size, but this probably won’t matter in practice.

Avoid: anything other than 128 or 256 bits, worrying too much about size, keys that are not uniform (e.g. using a password or ASCII hex string directly as a key).

Symmetric “signatures”

HMAC-SHA-256.

Percival, 2009: HMAC.
Ptacek, 2015: HMAC.
Latacora, 2018: HMAC.
Latacora, 2024: HMAC.

Yay for HMAC.

Just be careful to sidestep canonicalization and parser alignment bugs by always authenticating a verbatim string of bytes, not something you need to recompute.

Good:

{
    "inner": "{\"foo\":123}",
    "hmac": "MbPsZq7QGCllJgDnSSy/cyM10HjqiVu35UO7yyY5d3w="
}

Check the HMAC and then process or store or forward just {"foo":123}.

Bad:

{
    "foo": 123,
    "hmac": "MbPsZq7QGCllJgDnSSy/cyM10HjqiVu35UO7yyY5d3w="
}

You can use KMAC or keyed BLAKE3 if you already had a reason to use their underlying hashes. HMAC-SHA-512 is also fine.

Remember to compare tags with dedicated constant-time functions.

Avoid: rolling your own YoloMAC, encrypted hashes, standalone one-time MACs like Poly1305 or GMAC.

Hash algorithm

SHA-2 is still fine, but use a real multihash if needed.

Percival, 2009: SHA-256 (SHA-2), plan on SHA-3.
Ptacek, 2015: SHA-2.
Latacora, 2018: SHA-2.
Latacora, 2024: SHA-2.

The best option, if you have it available, is still SHA-512/256, which isn’t vulnerable to length-extension attacks. Otherwise, SHA-256 and SHA-512 are both fine.⁵

SHA-3 is unnecessary (because SHA-2 is fine) and slow,⁶ but not wrong. If you already have Keccak (SHA-3) around for ML-KEM and ML-DSA, and you want to use it for hashing, draw 32 bytes from SHAKE128.

BLAKE2 is a weird choice these days. BLAKE3 is very fast, but complex and uncommon enough that you want to have a good reason to use it and a good reason to trust your implementation.

Multihashing is when you need to hash multiple things at once. For example, multiple columns of a row, or a filename along with the file contents. It’s subtler than it sounds, so use SequenceHash with SHA-2, or TupleHash (SP 800-185) with SHA-3.

Avoid: SHA-1, MD5, all other hash functions, rolling your own multihash, truncating to less than 256 bits unless a cryptographer told you collisions are not a concern.

Random IDs

32 random bytes, a.k.a. 256-bit random numbers.

Percival, 2009: 256-bit random numbers.
Ptacek, 2015: 256-bit random numbers.
Latacora, 2018: 256-bit random numbers.
Latacora, 2024: 256-bit random numbers.

Note that UUIDv4 and APIs like rand.Text will give you ~128-bit values instead. That’s usually fine, unless you need more than 280 trillion (2⁴⁸) unique values. 256 bits is overkill, but why not.

Use your operating system’s CSPRNG: getrandom on Linux, ProcessPrng on Windows, arc4random_buf on macOS and BSD, getRandomValues on the web. A good library will wrap these for you.

Avoid: non-cryptographic PRNGs, userspace random number generators like OpenSSL’s, haveged, CPU jitter entropy.⁷

Password handling

Argon2id or scrypt. But have you considered passkeys instead?

Percival, 2009: scrypt or PBKDF2.
Ptacek, 2015: scrypt, then bcrypt, then PBKDF2 if you must.
Latacora, 2018: scrypt, then Argon2, then bcrypt, then PBKDF2 if you must.
Latacora, 2024: Argon2id, then scrypt, then bcrypt, then PBKDF2 if you must.

Everything my predecessors said is still spot on: “you can throw a dart at a wall to pick one of these.” I dropped bcrypt because the 72-byte truncation bites. One tip: you could argue to your auditors that scrypt is FIPS 140 compliant because its actual KDF step is PBKDF2, which is what they want. I heard it works.

For parameters, ignore RFC 9106 which apparently wants to murder your production system, and use m=64 MiB, t=2, p=1 for Argon2id (libsodium’s INTERACTIVE preset) or N=2^16, r=8, p=1 for scrypt. They use the same memory, but the scrypt ones will take ~1.5× the CPU time and ¼ the GPU time, which is why you should prefer Argon2id. If you’re doing non-interactive key derivation, feel free to crank up Argon2id’s m, and then t (or just N⁸ for scrypt) as far as tolerable.

Much more importantly, do you really need passwords? If you only need them for logins, could you use phishing-proof passkeys instead? Maybe with email magic links as a fallback? Or just support SSO (as long as it’s OIDC and not SAML)?

(Note that in 2026, passkeys are still not PQ. That’s mostly fine. They’re still phishing-proof and credential-stuffing-proof. All a quantum attacker can do is log in to a specific site if they obtain its database or intercept a login.)

Avoid: regular hashes, spending time thinking about password hashes instead of focusing on passkeys, phishable variants of email-based logins.⁹

Key exchange

X25519+ML-KEM-768 in a secure, standard protocol.

Percival, 2009: 2048-bit Group #14 with a generator of 2.
Ptacek, 2015: Probably still DH-2048, or NaCl.
Latacora, 2018: Probably nothing. Or Curve25519.
Latacora, 2024: X25519+ML-KEM-768.

The 2018 version of the Latacora answers is correct in asking “why are you as a developer thinking about this, and what does it even mean?!” Don’t roll your own key exchange protocol. Just pick X25519MLKEM768 in TLS, mlkem768x25519-sha256 in SSH, and/or MLKEM768-X25519 in HPKE and age. If you really need to obtain some keys and you know what you’re doing, both TLS and HPKE have “exporters” to derive them.

Non-PQ solutions are an active, urgent liability due to harvest-now-decrypt-later attacks, and PQ alternatives range from impractical (HQC-KEM, FrodoKEM) to impractical and broken (Classic McEliece).

For key exchange, using an ECC hybrid is cheap enough to be worth it, and indeed ML-KEM is usually deployed alongside ECDH. However, if picking or implementing the hybrid is going to make you stay even a single month longer on a classical, non-PQ key exchange, go straight to pure ML-KEM-768 now.

P-256+ML-KEM-768 is also fine, just less common. NIST P curves got a bad rep for many years, but I think it’s 90% because they came out before we knew how to do cryptography engineering particularly well (and because of… let’s say non-NPOV proselytizing). Almost none of the attacks against ECDH on NIST P curves even matter for ephemeral key exchanges.

Avoid: anything and everything without ML-KEM or X-Wing (a specific X25519+ML-KEM-768 combiner) in its name.

Asymmetric encryption

HPKE with (MLKEM768-X25519 a.k.a. X-Wing, HKDF-SHA256, AES-128-GCM), or age with PQ keys.

Percival, 2009: RSAES-OAEP with SHA-256, MGF1+SHA-256, and exponent 65537.
Ptacek, 2015: NaCl.
Latacora, 2018: NaCl/libsodium (box / crypto_box).
Latacora, 2024: Tricky, wait for established PQ solutions.

This is one of the most improved answers in recent years, as we now have a standard to do hybrid encryption: HPKE. (“Hybrid” as in asymmetric + symmetric, not as in classical + post-quantum, yay for overloaded names.)

MLKEM768-P256 is also ok as a choice of KEM, but less available. Pure ML-KEM-768 is fine if it’s all you have. All KDF and AEAD choices are fine, as well.

If your message is large, do the same chunking Cobblestone does, with multiple sequential HPKE Seal/Open calls in place of the AEAD.

Note that the PQ HPKE KEMs are maddeningly still a draft.¹⁰ Worse, they are unnecessarily spread over four drafts, such that I had to write filippo.io/hpke-pq. However, I made the authors solemnly swear they will not change the wire format, and then we all shipped them in our cryptographic libraries, so you can and should use them.

If you need something higher-level, with multiple recipients or a CLI, use age¹¹ with its new age1pq-prefixed keys, based on MLKEM768-X25519. PQ support is also rolling out for plugins like the YubiKey and the Secure Enclave ones.

Avoid: again anything not based on ML-KEM (RSA and NaCl’s box¹² in particular), OpenPGP, encrypting emails.

Asymmetric signatures

ML-DSA-44.

Percival, 2009: RSASSA-PSS with SHA-256, MGF1+SHA-256, and exponent 65537.
Ptacek, 2015: NaCl, Ed25519, or RFC 6979.
Latacora, 2018: NaCl or Ed25519.
Latacora, 2024: Ed25519 if short-lived, otherwise Ed25519+ML-DSA-65.

In January 2026, I would have told you to wait and see, and then everything started moving a lot faster. You need to move to PQ for auth, too.

Just use ML-DSA-44. If your message needs pre-hashing, use “external-μ (Mu)” signing, not HashML-DSA. Store keys as 32-byte seeds exclusively.

The two PQ alternatives are FN-DSA, which is stuck somewhere in the US Department of Commerce, and SLH-DSA, which is based on hash functions. The latter can make sense for some specialist use cases, but is slow, large, and not widely available in implementations.

Why not a hybrid or “composites”? Hybrid auth is more complex and less useful than hybrid key exchange. I need to write a long-form post about this, but in short either you already have a key rotation strategy that you can use to rotate back to RSA/ECDSA/Ed25519 in the unlikely case of a cryptanalytic break, or you have such a long time horizon that you should assume quantum computers will break the classical half anyway.

Also, ML-DSA is just such a better signature algorithm than its predecessors. It has hedged randomness (which is better than both random and deterministic nonces), built-in context, extra properties like SUF-CMA, and is relatively simple to implement and test.

Why the -44 parameter set, when I’m recommending ML-KEM-768? Unlike ML-KEM-512 (NIST category 1), ML-DSA-44 sits at NIST category 2, with some margin above the 128-bit security level already.

The one exception to the no-composites rule is SSH keys. OpenSSH 10.6 picked ssh-mldsa44-ed25519. I think they made a mistake, but it would be a mistake for you to go off the beaten path there.

Note that asymmetric signatures are overused, and especially now that they are not cheap, you should try to avoid them. Consider whether you could use a simple HMAC. Maybe you can replace signed JWTs with random session tokens. If instead you do want to commit to something publicly, consider whether you should use a transparency log, and get a more practically useful notion of non-repudiability (and potentially smaller sizes, if you amortize the signature over multiple proofs).

Avoid: all non-PQ options like RSA/ECDSA/Ed25519, stateful signatures (LMS/XMSS), HashML-DSA, ML-DSA “semi-expanded keys,” composite signatures, OpenPGP.

Website or client-server application security

If you’re in the cloud, use its ALB/NLB. Otherwise, rustls, Go’s crypto/tls, BoringSSL, AWS-LC, or s2n-tls with a popular, updated ACME client.

Percival, 2009: OpenSSL for websites, custom RSA protocol for applications.
Ptacek, 2015: OpenSSL, or BoringSSL if you can. Or just AWS ELBs.
Latacora, 2018: AWS ALB/ELB or OpenSSL, with Let’s Encrypt.
Latacora, 2024: AWS ALB/ELB or OpenSSL, with Let’s Encrypt.

Not recommending OpenSSL will probably be my least practical suggestion, but OpenSSL has been making consistently puzzling and problematic choices for years now. The pyca/cryptography authors, in a long post about OpenSSL’s issues, summarize it as:

Our experience with OpenSSL has been on a negative trajectory for several years.

They even presented at the 2025 OpenSSL Conference (!?), apparently fruitlessly. They’re not alone in criticizing OpenSSL: here are HAProxy from the server side, and curl from the client side.

I recommend rustls or Go’s crypto/tls,¹³ which are memory safe. If you need to stick to C, both BoringSSL and AWS-LC are very competently maintained OpenSSL forks, and the latter, unlike BoringSSL, has versioned releases. s2n-tls and rustls-ffi are interesting options if you don’t need libssl compatibility.

Whatever you use, make sure it prioritizes the X25519MLKEM768 key exchange, which requires TLS 1.3. Your cloud load balancer might require you to select a PQ security policy. On RHEL 9 and derivatives, you need to opt in.

Previous lists split websites and client-server applications. I merged them because these days you’ll just use the same TLS stack for both. What changes is the PKI. For applications where you control both ends, consider making your own ML-DSA-44 X.509 certificates, self-signed or from a private root. For websites, wire up a popular, well-supported ACME client and keep it up to date. Merkle Tree Certificates will roll out in 2027, and you want to be well positioned to be included in the transition.

Avoid: rolling your own transport protocol, TLS libraries that failed at their core job before (GnuTLS¹⁴, Mbed TLS^15 16 17, wolfSSL^{18 19 20 21 22 23 24 25}, Botan^26 27), offbeat TLS libraries, OpenSSL before version 3.5 (the first with X25519MLKEM768), any OpenSSL if you can, TLS 1.0–1.1, TLS 1.2 if you can, rolling your own ACME client.

Online backups

restic with a long random password.

Percival, 2009: Tarsnap.
Ptacek, 2015: Tarsnap.
Latacora, 2018: Tarsnap.
Latacora, 2024: Tarsnap.

I checked restic’s encryption a very long time ago and it was slightly weird but good. Fully symmetric, so it’s not scared of quantum computers. Doesn’t look like anything changed since. If you need cloud storage, rsync.net has a “secret” plan for restic users, and they support an append-only mode.

We all love Tarsnap, and I feel like I am betraying my elders right now… but its asymmetric cryptography layer is all RSA. Technically, I think the only things that truly break are the lower-capability keys: a write-only key can decrypt archives and a read-only key can forge archives. Server authentication is HMAC, and the RSA public keys are never sent to the server. In that sense, Tarsnap is as secure as restic, which is an impressive feat for a 2008 design. However, this feels like a major footgun with impending quantum computers.

The picture

Kinda incredible that you can just walk up to this thing.

Follow me on Bluesky at @filippo.abyssdomain.expert or on Mastodon at @filippo@abyssdomain.expert.

Updates (Oct. 9): To address some questions that keep coming up…

No, I’m not aware of any direct practical implications of any of these results. I certainly don’t expect the O(n log^{0.9999999999999} n)-time Fourier Transform algorithm to get practically deployed anytime soon! But anyone who harps on this, simply doesn’t understand what mathematical progress looks like, or how it eventually pulls the rest of science and technology and human civilization with it. If and when the relevant human mathematicians understood the clever new ideas in all 372 of these papers, I have no doubt that they’d be able to use the ideas to do all sorts of new things, and that some of those things would have practical value. That’s yet another reason to try to keep human understanding at the center of our enterprise—unless, of course, you’re happy to outsource the task of understanding and applying the ideas to AI models as well.

Meanwhile, something calling itself the Association for Human Mathematics put out a statement condemning OpenAI for its release. The statement included a sentence that’s since been widely mocked on social media: “Mathematicians did not ask for this work to be done.” (Imagine G. H. Hardy saying to Ramanujan, “who asked you to prove all these bizarre new identities?”)

If it wasn’t clear, the members of AHM speak for themselves, not for the math community as a whole. For my part, I think the math and CS theory communities should absolutely hold the AI companies’ feet to the fire to behave better, both within our little domains, and (much more consequentially) in pacing AI progress, figuring out alignment, and preventing a catastrophe for our whole civilization. So I’m glad that our communities have increasingly been doing that, and I hope to have played a tiny part.

At the same time, I regard the position “no one should spoil our fun by solving our open math problems using AI models” to be totally untenable. It offers no argument for why refraining would be in the broader public interest—as opposed to various mathematicians’ narrow career interests. It violates the core principle that math problems are there for absolutely anyone (yes, even a hated corporation) to try to solve. And of course, it’s not enforceable anyway, in a world where these capabilities will rapidly diffuse to anyone with a GPT or Claude subscription.

We will need to adapt to this new world.

---

… then they came for Navier–Stokes and I said nothing because I never worked on Navier–Stokes. But when they came for RL vs. L I realized that things are serious

–friend-of-the-blog Omer Reingold (shared with permission)

---

Last night my 9-year-old son was taunting my wife, complexity theorist Dana Moshkovitz, as follows: “mommy, I heard you got cooked! I heard that a robot solved the math problem you worked on for your whole career! OOF!”

While my son was being a brat, he also wasn’t wrong. Whether you’re thrilled, depressed, angry, or whatever else about it, yesterday was surely one of the biggest days in mathematical history. And yes, among the 372 huge results released yesterday by OpenAI, on the recommendation of its advisory group of Timothy Gowers, Edward Witten, and other distinguished mathematicians, was a proof of Subhash Khot’s Unique Games Conjecture (UGC), a statement that my wife has worked toward proving for the entire time I’ve known her. (The UGC implies that a whole slew of optimization problems really are NP-hard, even if you just want an approximation that’s slightly better than what you get from semidefinite programming relaxation, which is one of our main tools.)

Or at least, we’re pretty sure that it’s a proof! There’s a Lean certificate, as there are for some of the other 372 breakthrough results (not all of them). But it also appears that no human has understood just about any of these proofs yet; the race to do so has just started. If you want an on-the-ground sense of what that race is going to be like, here’s some of what Dana texted me last night:

It feels like something written by someone who’s on psychedelics. So much unclear and doesn’t make sense. Lots of name dropping of previous work without discussing why it can be used despite impossibility results

Basically the paper is so horribly written that it’s impossible to read it without AI help

I asked Astra for reasonable completeness and soundness claims of the noise gadget and it gave them by combining claims from all over the paper

They also have direct optimal NP hardness of approximation proofs for the main applications of the UGC (Max Cut and all CSP) that bypass the UGC.

The UGC proof invents a completely new bizarre code with a noise test. It’s some crazy recursive construction.

It’s not the long code, not the short code – some alien craziness

I still think that there maybe is a proof that uses the half space code (which is natural)

The citations are often irrelevant and confusing

A possible future is a math world that’s heavenly if you have vision/creative ideas that AI could help check and implement.

And of course there’s a lot for us to learn from the aliens

If you’re wondering what emotions Dana is feeling—well, probably all of them! Even while a central career aspiration has fallen to a robot, there are at least two mitigating factors for her. First, she can feel vindicated that the UGC was true after all, something she never doubted even while many of her colleagues did! Second, all of us in math and theoretical computer science and mathematical physics, at least those who cared about solving crisply-stated problems, are now in the same boat.

---

Besides the Unique Games Conjecture, here’s a small sampling of the treasures from Aladdin’s cave that I’ll probably be paying the most attention to over the coming weeks:

• L=BPL (i.e., probabilistic logspace and deterministic logspace are the same thing), one of the great derandomization conjectures short of P=BPP. Though its truth was never in serious doubt, there was a whole subcommunity focused on proving this.
• The Fourier Transform and integer multiplication in less than O(n log n) time, breaking a barrier that had stood since the 1960s. The new running time, if you’re curious, is O(n log^{0.9999999999999} n), give or take some 9’s.
• Positive solution to the Unitary Synthesis Problem, which Greg Kuperberg and I posed back in 2007. For every n-qubit unitary transformation U, there exists a classical oracle A such that U can be implemented in quantum polynomial time with access to A. This is the opposite of what most of us expected, and could have implications for e.g. the computational problem of decoding Hawking radiation from a black hole and many other problems in quantum complexity theory—if we had an efficient way to construct the oracle A, which this paper doesn’t give. (Added: Here’s a beautiful blog post by friend and colleague Dakshita Khurana about the years she spent working on this problem—unlike me and most others, she believed correctly in a positive answer to it—and her current feelings as she works through the AI’s proof.)
• Parity is not in QAC⁰, one of the great questions of quantum complexity theory since 1999 that many of my colleagues had been closing in on.
• Nearly 4^th-power separation between randomized and quantum query complexity for total Boolean functions. A favorite problem of mine since 1998 (!), when we knew only that the optimal separating exponent was between 2 and 6. For the past few years, we knew it was between 3 and 4. So, this finally closes that story.
• A superquadratic separation between sensitivity and block sensitivity.
• Area law for 2D gapped Hamiltonians. One of the main open problems in Hamiltonian complexity.
• Matrix multiplication in n^9/4+o(1) time—a rational exponent for once (!), and via a completely different approach than was used for O(n^2.373) and so forth
• $\Omega(n^3)$ lower bound on the determinantal complexity of the permanent, improving the previous best bound which was quadratic.
• A randomized polytime algorithm to approximately count the number of perfect matchings in a general graph, as well as a randomized nearly linear-time algorithm for finding a maximum matching in such a graph
• Uncomputability of solving polynomial equations over the rational numbers—this was arguably the biggest open problem in computability theory (note that uncomputability of solving Diophantine equations, i.e. polynomial equations over the integers, was proved in the 1970s, giving a negative answer to Hilbert’s 10th Problem)

Any of the above, alone, could easily have been “result of the year” in some area (and in some cases, like Unique Games and L=BPL, in all of CS theory). And there’s a lot that I’ve left out—feel free to share in the comments whatever is making your eyes bug out! There are equally astounding wonders in number theory, combinatorics, algebraic geometry, analysis, and pretty much every other area of math, most of which I’ll never understand, although I’ll note that it includes partial progress toward the Riemann hypothesis and the Hodge Conjecture and the Birch-Swinnerton-Dyer Conjecture (i.e., the majority of the remaining Millennium Problems).

We can take solace in what’s missing from the list. P≠NP isn’t there, nor even P=BPP or NEXP⊄P/poly, and surely not for lack of trying. Apparently the greatest open problems of theoretical computer science are indeed pretty hard!

---

Oh, lest I forget: one day before the OpenAI dump, meaning Monday evening, Virginia Williams and Josh Alman posted an arXiv preprint that solves the 3SUM problem in O(n^1.9992) time, and the All-Pairs Shortest Paths problem in O(n^2.9995) time, refuting half-century-old conjectures that the correct answers were n^2-o(1) and n^3-o(1) respectively. In this case, it wasn’t an OpenAI model that supplied the crucial idea; it was an Anthropic one! But Anthropic then took a different approach from OpenAI: rather than post the undigested solutions to the world, it gave Virginia and Josh the opportunity to write and announce a digested version in exchange for compensation.

These have emerged as the two main models for communicating AI math breakthroughs, and they both have strengths and weaknesses. The “OpenAI model” sets up a crazy race among humans to digest and explain a messy AI proof (work that could easily be some combination of thankless, barely-credited, competitive, and unfun), while the “Anthropic model” puts a private company in the position of picking and choosing which human mathematicians get to be the emissaries of the AI. Dunno, what do you guys think?

---

For those who are wondering: apparently, the AI model that produced all these wonders was not bespoke contraption of 10,000 agents burning millions of dollars worth of compute, as was used for example to construct a finite-time blowup for the Navier-Stokes equations. Instead, it was simply the latest internal OpenAI model—one that might be released to paying ChatGPT customers within the next couple of months, depending on the recommendations of OpenAI’s safety board! (My 9-year-old son: “Oh they definitely shouldn’t release that. If it could solve all those math problems, it can’t possibly be safe.”) Apparently they used about 3 hours of GPT-Pro level compute on average per problem solved.

Also, if you were wondering: apparently they tried the model on about 8,000 problems. So, right now it “merely” solves ~5% of the longstanding open mathematical problems that it’s asked about, the problems that whole communities have spent years on, after a single 3-hour attempt on them.

---

I’ve been glad to see the CS theory community rising to the occasion. At the Simons Institute in Berkeley, here at UT Austin, and elsewhere, I’ve hearing stories of researchers rushing to pore over the manuscripts and make sense of them and explain them—because what else do we do? How else do we continue the craft to which we’ve devoted much of our lives?

If you want some sense of what things feel like now in math, imagine a hunter-gatherer who’s spent his entire life learning to survive deep in an unforgiving rainforest, then a giant resort hotel springs up right next to him with a helipad and heated pools and AirBnBs, and without missing a beat, the hunter-gatherer says: “alright fine, so now my new job is to run wilderness retreats for the tourists, or something.”

In Quanta magazine, Jordana Cepelewitz attempted a different metaphor:

It’s as if you were teleported to the peak of a tall mountain. Surrounded by fog, you have no idea where you are, or what’s around you. You do not know how your mountain connects to others, and you have no equipment to help you explore, no way to help someone else join you. If you had climbed the mountain yourself, you would have experienced how the human body adapts to altitude and changes in oxygen levels. You might have had to invent tools to navigate, to climb steep cliffs, or to make a shelter. You might have encountered a fellow explorer, gotten lost together in a hidden valley, and found a plant that could be turned into a life-saving medicine.

Instead you’re perched on the peak but in the dark, while the maker of the teleportation machine tells you that it can explore the wilderness better than any human.

For any one of these mountains, if we care enough, I feel optimistic that we can do as we always have: clear the fog and figure out the path, except now using the teleportation machine to help guide us. The bigger challenge will be to nurture a community that still cares about the heroic adventure of finding the paths up these mountains in the world with the machine. (Oh, and I think one place where the metaphor breaks is that we still do have each other, as much as we ever did before!)

---

Experience has shown that, even now, there will still be people explaining in patronizing tones why none of this is real and none of it counts. If such people were capable of being impressed by anything that happens in the empirical world, of updating on anything, they would’ve already been impressed and already updated several years ago, long before things had reached the point of an actual Mathocalypse.

So, they’ll say, maybe the alleged solutions are not solutions at all, but just “AI slop.” Or maybe none of the 372 well-known open problems that were solved were real math problems, they were all just glorified contest puzzles and trivialities. (After all, there’s still no Riemann Hypothesis!) Or maybe the entire 4000-year-old discipline of mathematics needs to be jettisoned: turns out that it was all just puzzle-solving and trivialities; all that’s different is that now the triviality stands unmasked. In any case, what really matters is that the true inner sanctum of human creativity hasn’t been breached and probably never will be, and also, that Sam Altman and Dario Amodei are contemptible little nerds.

If you’re still a proponent of that doomed worldview, still aboard the sinking ship, I encourage you in the strongest possible terms to read yesterday’s other great contribution to AI discourse, besides the OpenAI Mathocalypse dump: namely, Scott Alexander’s open letter to Steven Pinker. I feel some responsibility for this, as the person who first introduced Steven Pinker to the existence of the rationalist community, and who also first introduced Steven Pinker and Scott Alexander to one another (they had both been fans of each other’s writing). And now Scott is challenging Steve to a literal duel, with guns!

For whatever it’s worth: Steve is a lifelong intellectual hero of mine, just as he is for Scott, and I also have to privilege of calling Steve my friend. But I found Scott’s post to be one of the most devastating rejoinders to anything that I’ve ever read. And I thought Scott’s conclusion was exactly right: when it comes to AI risk, Steve’s great challenge is now to accept and start using a more “Pinkerite” epistemology.

---

Last night, while I should’ve been poring over some of OpenAI’s hundreds of papers and/or writing this post, I decided to spend some time with my kids instead. They wanted a movie night, so I suggested something they’d never seen before (and that I hadn’t seen for decades), and that seemed chock-full of no-nonsense, practical guidance for the world in which they’re going to grow up: Terminator 2.

---

Update: As several people have pointed out, cryptography is a subfield that’s extremely conspicuous by its absence from OpenAI’s list of 376 papers! But my sources tell me that the AI companies have now started, gingerly and discreetly, investigating whether their latest internal models can break important cryptographic protocols and primitives. If they can, then it would certainly be nice to get ahead of things before the rest of the world figures out the same.

Another Update: The statement put out the Advisory Group on Mathematics and Artificial Intelligence is very carefully phrased, neither endorsing nor condemning what OpenAI did, and is worth a read:

As announced a few weeks ago, OpenAI has released a large collection of mathematical results generated by an internal model, reporting solutions to hundreds of open questions. This is an important event for mathematics, with consequences both for mathematics and for the mathematical community that extend far beyond the individual results.

AGMAI’s advisory role should not be interpreted as a judgment of the impact of these results or an endorsement of the process by which OpenAI obtained them. We do not speak on behalf of the entire mathematical community, and only the mathematical community can undertake the assessment that is needed. 

Making this work public is a first step. This release is the beginning, not the completion, of the process of human understanding and the incorporation of the work into mathematical knowledge. At the same time, the future of mathematical research cannot consist only of understanding results produced by AI labs. Mathematicians must be able to formulate their own questions, develop their own approaches, and explore directions that have not been selected as examples of an AI system’s capabilities. Equitable access to powerful research tools and adequate computational resources are essential to that freedom.

We reaffirm our published recommendations on responsible release. We have discussed them with OpenAI and appreciate the company’s willingness to engage. While we consider these discussions constructive, it is ultimately up to the mathematical community to assess the extent to which our recommendations were followed successfully, and whether there are others we should suggest. We remain committed to engaging with any frontier AI lab on these questions and have already been in contact with several of them.

The Museo de Historia de la Computación in Spain has unveiled a 1:1 scale visual replica of the famous Cray-1 supercomputer from 1976. Instead of sourcing expensive, cutting-edge tech to run the system, the creative team powered the project with 30 2012-era Mac Minis. Developed over 18 months, the project serves as a 50th-anniversary tribute to the Cray-1 and Apple's founding.

Mac Minis from over a decade ago might not seem like the obvious first choice for building a cluster supercomputer, but when networked together, the developers can orchestrate the 64 active processing cores into a combined 1.3 teraflops of performance in their most recent tests. The museum reportedly achieved 1.5 teraflops previously using all 70 available cores, prior to one node going offline. Benchmarks were obtained using a custom matrix-multiplication Python script. Five PCs are quad-core i7s, and the remaining 25 are dual-core i5 models. Except for two units from 2014, the rest of the array dates to 2012.

The replica is a valuable tool for museum-goers to understand the shifts in computer architecture since 1976. The original Cray-1 used vector processing, applying a single instruction to multiple data elements simultaneously, whereas the replica distributes work across independent processors in a parallel cluster. The peak theoretical performance of the original Cray-1 was approximately 160 megaflops. What was originally a purpose-built research machine has been re-created with consumer hardware that's vastly more capable than the machine that inspired it.

Rather than opting for a more standard Linux distribution, the team found that macOS Mojave (10.14) met their project needs by harnessing macOS's built-in support for MPI (Message Passing Interface), the software layer that allows all the nodes in the cluster to pass tasks to one another.

The Cray-1 replica, complete with iconic padded bench seating. The only thing missing is Robert Redford and Ben Kingsley having a discussion on SECTEC Astronomy. Credit: Museo de Historia de la Computación Credit: Museo de Historia de la Computación

Guests at the Museo de Historia de la Computación can watch in real time as the system runs matrix algorithms, mapping the scale of system performance from a single core to the full suite running in parallel.

Stealth supercomputing

Combining 30 consumer PCs into an operational cluster wasn't the only engineering challenge the team faced. If you've ever stepped inside a server room, or, like me, foolishly installed one in your own basement, you know that fan cooling can be loud. The museum team used passive convection cooling via a steel rack chassis and aluminum tray mounts for each Mac Mini. Compared to the roaring thunder of a modern data center, this cluster is nearly inaudible.

Macs are mounted vertically on aluminum racks in a steel chassis. Credit: Museo de Historia de la Computación

The secret to the near-silence comes from vertical mounting. The PCs' vertical orientation, combined with the steel chassis and aluminum trays, allows the tower to act as a natural thermal chimney. Hot air rises through the structure and out of the top grills without the need for added mechanical fans. According to the museum, the only noticeable noise inside the Cray-1 replica comes from two gigabit Ethernet switches at the base of the unit that register between 30–33 decibels, though the team plans to replace them with silent models. The fully assembled replica is said to make so little audible sound that you have to get right up next to the tower to be able to hear anything. While exact dB  measurements from inside the exhibit weren't available, each individual PC is stated to produce 12–15 dBA of noise at idle.

Mission control

To manage this quiet giant, designers built a custom terminal that looks straight out of a Cold War control room. The team combined elements of the DEC VT05 and Processor Technology Sol-20 Terminal Computer designs of the 1970s, even incorporating an analog control panel, with future plans to add original lamps from an IBM System/3. One master Mac Mini resides in the terminal and serves to direct all the other cluster nodes.

Classic design elements lend the Cray-1 control terminal some retro style. Credit: Museo de Historia de la Computación

The original design had planned for the terminal to feature CRT monitors for added authenticity, but modern flat Samsung displays eliminated the connectivity headaches that come from attempting to bridge different technological eras. Future design plans will see 3.5- and 5.25-inch floppy drives mounted to the underside of the desk, and a 3D-printed shell will encase the keyboard to mimic the look of the classic HP 250 design.

Mockup of the shell that will fit over the existing PowerMac G4 keyboard. Credit: Museo de Historia de la Computación

Targeting the TOP500

The Cray-1 team hopes to fill the currently empty second half of the tower through a crowdfunding campaign to secure 70–80 additional M4 Mac Minis. The goal: create a cluster capable of ranking on the TOP500 supercomputers list.

The Cray-1 replica among its classic computing peers. Credit: Museo de Historia de la Computación

The replica is on permanent display in the museum, alongside two unused authentic Cray CX1 systems. The Museo de Historia de la Computación offers guided tours on Saturdays from 11:30 am to 2 pm. Additional project information can be found on the museum website.

Read full article

Comments

Meta founder and CEO Mark Zuckerberg has gone to great lengths to hype the security of its new AI assistant Muse, claiming it is “built from the ground up for privacy and security.” A zero-day vulnerability that gives locally run apps and terminal commands complete control of the agent raises serious doubts. Further raising questions, Amazon on Sunday began blocking Muse from its site.

Meta introduced Muse a few weeks ago. The assistant “books appointments, fills out forms and handles customer service,” “proactively takes tasks off your plate,” and can “make purchases, generate images, create documents, and connect with your favorite apps and services.” The macOS app (curiously, there’s no Windows version) also works with a user’s WhatsApp, email, calendar, and social media accounts. When a task requires a tool that doesn’t exist, Muse creates one on the fly.

Meta doth hype Muse security too much

Of course, for Muse to do any of these things, users must first give it access to their accounts. This includes authenticating the assistant to each service and, because the app runs on macOS, giving it permissions to a broad range of operating system-restricted device resources like writing files to disk, accessing the mic and camera, and monitoring location and calendars. Apple has spent years developing these defenses to prevent installed apps or commands entered into the terminal from accessing these resources, clearly because the company considers them a security threat. Muse completely undoes these default measures.

The zero-day allows any app or terminal command to gain access to the token that authenticates users to their Muse account. Meta developers designed the assistant so that any locally installed app or executed code, regardless of the macOS permissions it has, can change a long list of undocumented settings. Most of them are fairly innocuous, such as controlling dark mode. One setting, however, is anything but innocuous. It allows processes to change the endpoint where transcription occurs. Normally, it’s a server address operated by Meta. Attackers can exploit this flaw by changing the location to their own endpoint. Once that happens, the attackers have the token that gives complete control over the Muse account.

“We can manipulate the agent and leverage its privileges to do whatever we want,” Patrick Wardle, the macOS security expert who discovered the zero-day, told Ars. “So instead of us having to write a very comprehensive Mac malware stealer, we can just leverage the AI assistant itself.” Wardle said he has developed several proof-of-concept attacks that do things like writing malicious files to disk and snapping pictures, in many cases with no indication to even an alert user.

Meta representatives didn't answer emailed questions.

Meta has published two posts in as many weeks documenting the design decisions that went into ensuring an assistant with such extraordinary access to user data and resources is secure and private. The posts come amid revelations that internal testing of models from Anthropic and Google has resulted in security breaches of external, third-party networks that the engineers involved never intended to target. In traditional human-only hacking, these actions could likely result in the filing of criminal charges. The Meta posts are likely mindful of the resulting blowback and the calls to slow down AI development in response.

Wardle said that Meta developers made several design decisions that made his exploit possible. One is the choice for Muse dictation to occur in the cloud, where Meta can log it. macOS has long provided a simple means for apps to handle dictation and transcription in processes that stay securely on the device. Had the developers chosen this safer alternative, the attack wouldn’t have been possible.

Another flawed decision is for any app to control all of the undocumented settings. It’s likely Meta intended for apps working with Muse to control UI settings, and for understandable reasons. The ability for any app or command to control an endpoint where sensitive user speech is processed is an entirely different matter. Together, the design decisions raise questions about just how much effort developers put into designing and testing the security and privacy of the new assistant.

“To me, the bar is infinitely higher in terms of the security of these apps. They don’t have to be perfect, but when you take a look at Muse, it’s like they didn’t, in my opinion, think about security, which is really worrisome," Wardle said. "At the very least, they should be thinking about security from the very start, and they are just not.”

Roughly 12 hours before Wardle disclosed the zero-day, Amazon started blocking people from using Muse to shop on the site. Users who tried received a message saying Muse was an “unauthorized AI agent [that] violates Amazon’s Conditions of Use.”

“We think it's fairly straightforward that third-party applications that offer to make purchases on behalf of customers from other businesses should operate openly and respect service provider decisions about whether or not to participate,” Amazon said in an emailed statement. "This helps ensure a safe, secure, and reliable customer experience, and it is how others operate including food delivery apps and the restaurants they take orders for, delivery services apps and the stores they shop from, and online travel agencies and the airlines they book tickets with for customers. Agentic third-party applications such as Muse have the same obligations, and we've requested that Meta remove Amazon from the experience."

A single ClickFix is all it takes

There are several ways for attacks to work. One is for an attacker's server to act as a proxy that’s placed between the Muse user and Meta endpoint. Once the user enters the voice prompt, the attacker's server adds a prompt invoking a malicious command, such as sending an archive of all WhatsApp messages to the attacker. Once that happens, the attacker gains permanent control over the Muse account because the token is automatically sent to the malicious server as well.

Wardle is the creator of the Objective-See Foundation, a nonprofit focused on macOS security. He is also the author of the "The Art of Mac Malware" book series, and a former employee of NASA and the National Security Agency. Wardle said he plans to discuss the vulnerability in more detail and other AI assistant threats at the Objective by the Sea security conference in November.

One of the counterarguments raised by developers of apps that can be exploited once a device is compromised is that once that happens, all security bets are off. This standard doesn’t fit well in this case. Wardle found that a simple variation of ClickFix attack—a technique that has become remarkably effective in tricking people into infecting their devices—is all that’s required for an attacker to take control of a Muse account.

Credit: Patrick Wardle

Credit: Patrick Wardle

In the first image above, Wardle can be seen using a simple terminal command to surreptitiously send a prompt to the Meta endpoint. The second image shows the response. To prevent attackers from cutting and pasting the prompt in live attacks, Wardle's prompt asks only how it's possible it's coming from an unprivileged attacker. Muse incorrectly responds that such an action isn't possible.

As already noted, the extraordinary access Muse requires to work as intended places an additional burden on its designers. Like most such AI agents—and contrary to Meta’s claims—Muse can’t be trusted. It’s not clear when or if it ever will.

Read full article

Comments

As the build-out of AI data centers has accelerated, the public has tended to focus on every possible downside of these industrial projects. Some wariness—about the developments and the companies behind them—is sensible. As with almost any new industrial development, and depending on where they are built and how they are powered and cooled, data centers pose risks of excessive carbon-dioxide emissions and noise pollution.

But the panic about the harms of these projects has well outpaced the evidence. In my years researching and reporting on AI and the environment, with support from a grant from Coefficient Giving (formerly Open Philanthropy), I’ve noticed that misconceptions abound. This panic, moreover, is leading communities to forgo massive amounts of tax revenue—largely because of threats that are inflated, confused, and sometimes nonexistent. The trade-offs are real.

In June, a Massachusetts city near where I grew up blocked a data center, in large part out of concern over the amount of water the development would use and pollute. Data centers do need a lot of water to cool their equipment, and—as with most industrial building projects—constructing these developments can introduce chemical additives into the local wastewater. But there are no confirmed cases of this data-center pollution harming people, and this city specifically has abundant fresh water.

[Elias Wachtel: The data-center panic is overblown]

Most of the fear about water seems to be the product of misunderstood details from news reports, spread like a game of telephone. The New York Times published a story last year about a Georgia couple whose water taps at home went dry after Meta broke ground on a $750 million data center nearby. The couple suggested that Meta’s construction created a buildup of sediment in the water, which caused water-pressure problems and damaged their well (many homes in the area use well water). Whether the construction actually caused these problems remains unclear, but the story is often read as evidence of the harms of data centers. Yet sediment buildup in groundwater is a standard construction risk, and most places don’t ban large buildings over it. Almost all stories about the harms of data centers cite such construction-related problems.

As for the concern that data centers add toxic “forever chemicals,” known as PFAS, to local water sources, this seems to involve some confusion over how centers use water to cool the machinery. Some systems use fluorinated fluids classified as PFAS to help cool servers and prevent fires, but these are designed as closed loops that stay contained in equipment. There’s always the threat of a leak, but contaminating local waterways is a risk of any major industrial project.

One known exception in which a data center was linked to a water-pollution problem was in Oregon, where Amazon data centers used groundwater that was already contaminated from decades of local agriculture and food processing. Because much of the water used to cool equipment ends up evaporating during the process, the wastewater that left the data center had a higher concentration of nitrates, which exacerbated the contamination problem in the local groundwater. Amazon agreed to settle the matter for $20.5 million without admitting guilt. The company accurately noted that the area had been suffering from polluted water for decades, even if the data center made it worse.

The data-center debate includes plenty of dauntingly large numbers without context, such as that they consume millions of gallons of water a day. This is a significant amount, but also comparable to the water use of other industries. The data center with the highest known water consumption, Google’s development in Council Bluffs, Iowa, consumes about 1.3 billion gallons a year. That sounds massive, but so is the amount of water used to irrigate Iowa’s corn crops. If Google had bought a cornfield four to six times as large as the data center’s plot, or about eight square miles (roughly 0.04 percent of the total area Iowa uses for corn), the company would consume the same amount of water irrigating it. All American data centers together will consume about 1 percent of the water that America uses to irrigate corn. This is not nothing, but hardly horrifying in context.

Another misconception is that data centers consistently raise local electricity prices. There is no clear positive relationship or broad pattern between data centers and household electricity prices, but people are happy to spread misleading claims on the subject. A common statistic that critics bandy about is that electricity costs near data centers have skyrocketed by as much as 267 percent in five years. Senator Elizabeth Warren cited this number in an op-ed earlier this year. But the figure comes from a Bloomberg analysis of wholesale electricity prices at specific nodes on the grid, not the prices that households pay. Although wholesale prices influence residential prices over time, residential prices are largely insulated from wholesale spikes and drops, and American-household bills have not risen anywhere near 267 percent during the data-center build-out. When price hikes have been linked to data centers, the amount looks more like 10 percent.

Perhaps the most pernicious misunderstanding of the facts involves the claim that data centers don’t pay taxes. Early reports about the sales-tax exemptions on machinery and equipment that data centers enjoy in most states have somehow morphed into a sweeping assumption that data centers are actually depriving states and municipalities of tax revenues. The reality is that data centers are a reliable and lucrative source of tax revenue wherever they are built. Real-estate and personal-property taxes ensure that the tax burden on these developments is high, regardless of sales taxes.

For example, Loudoun County, Virginia, which has the largest concentration of data centers in the country, collects $1.3 billion a year in county taxes from these centers—about $2,800 per resident. This represents nearly half of all local tax funding for county government and public schools, despite Virginia’s waiver of sales taxes on related machinery and equipment. Local opposition to new data centers has come to Loudoun too, but residents are unlikely to forgo hundreds of millions of dollars a year to shut down the data centers in operation.

[Matteo Wong: The truth about AI’s water use]

Another common concern is that data centers will “take up all the land” because these facilities consume a lot of space. Yet my own rough estimate puts the combined footprint of all data-center buildings in America at about 25 square miles by 2028—a little over half the size of Disney World and spread across the country. These projects also buy land around the buildings and for future expansion, but the combined landholdings of all new and existing data centers would cover about 1,400 square miles, a little more than three times the land used to grow Christmas trees in the United States.

For a sense of scale, again consider Loudoun County. Data centers take up 3 percent of Loudoun’s land, even as they generate nearly 40 percent of the county’s general-fund revenue. Despite concerns that these centers depress local land values, a 2025 study of home sales in Northern Virginia, including Loudoun, found that homes closer to data centers sold for higher prices, perhaps because the infrastructure that’s valuable for data centers is also valuable for homeowners.

Then there are the conspiracy theories, such as the idea that data centers emit harmful, inaudible low-frequency sounds, known as infrasounds. Such claims sometimes misrepresent the studies they cite. No infrasounds at the levels the data centers emit have been found to be harmful. This is not to say that data centers don’t cause some noise pollution, but the idea that imperceptible infrasounds have some mystical ability to make people unwell is not borne out by the evidence.

As for the underlying anxieties about AI that may be motivating the data-center backlash, slowing down the construction of data centers is not the same as slowing down the capabilities of AI. Yet banning data centers has become shorthand for political candidates who wish to seem tough on AI, when this is a distraction: The wiser and tougher move is to heavily regulate the industry.

No data center is a harmless boon for locals, but the real question is whether their downsides outweigh their benefits. Given the status-quo bias at play—whereby change seems inherently costlier than keeping things the same—I’ve discovered a simple trick to make the trade-off clear. I now ask people, “Would we spend as much tax revenue as the data center will bring in to avoid its downsides?” For example, would the residents of Loudoun County each pay $2,800 a year to reduce some of the county’s air pollution and water use, lower electricity bills by about $6 a month, and make about 3 percent of the county’s land available for something else? Since this is the actual question before communities, I find that spelling it out is handy. In Loudon, and in other jurisdictions around the country, many voters seem, on balance, to prefer the data centers.