You just sent a private message on WhatsApp Web. You saw the lock icon. Your friend saw the same. You both felt a little safer. But here’s the part nobody tells you: that lock is painted on a glass door.
If you can’t audit the code running in your browser, you’re not encrypted—you’re just making a promise.
The promise is seductive. Big companies spend millions on cryptography. Engineers with PhDs design algorithms. Audits happen. But the moment that encryption runs in a web browser, the entire system becomes a trust exercise. Because the browser doesn’t belong to you. The JavaScript that executed that encryption just now? It could be swapped out five microseconds later. The provider—Google, Meta, whoever—can change the client code at any time, for any user, without you ever knowing.
This isn’t a bug. It’s architecture. The web was built for delivery, not for security. Code-on-demand means the server controls what the client does. End-to-end encryption in a web app is like handing someone a sealed envelope—but letting them keep the key under their own doormat.
I first read this argument in a brutally honest post by a developer named H. L. (the essay is called “Web-based cryptography is always snake oil”). It stuck with me because it’s not about whether AES-256 is strong. It’s about who controls the computer that runs it. On the web, that’s always the provider. Not you.
Cryptography is not a spell. It’s a physical process. And if you don’t control the machine, the spell is theater.
Think of Signal’s desktop app. The core encryption libraries are open source. But are you running the version you think you are? Unless you compile it yourself and verify every update, you’re trusting the Signal team to not inject a backdoor. Now multiply that by every web app you use—banking portals, email clients, password managers. They all rely on the same broken delivery model.
The industry’s response is usually: “But we have audits! We have transparency!” Those audits check a snapshot of code. The code that runs in your browser five minutes later might be different. The provider can silently A/B test a compromised version on 1% of users and nobody would catch it until months later—if ever.
Let’s be clear: I’m not saying every web app is malicious. I’m saying the architecture makes trust mandatory, not optional. And mandatory trust is the opposite of what encryption is supposed to deliver.
True security requires that the user can verify the encryption at the point of execution. On the web, that’s structurally impossible.
What can you do? Start by admitting that web-based crypto is at best “provider-guaranteed privacy” and at worst a placebo. For truly sensitive data—health records, legal documents, intimate conversations—use native apps where the code is static and you can audit the distribution channel. Or better, demand tools that let you inspect what’s actually running.
But don’t fall for the lock icon. It’s a promise, not proof. And on the web, promises are made to be broken.
FAQ
Q: But what about Signal or WhatsApp? Aren't they audited and open-source?
A: Yes, but audits check a static version of the code. The provider can dynamically change what code runs in your browser at any moment. Unless you compile and verify every update yourself, you're trusting the provider not to serve you a compromised version. That's not encryption—that's faith.
Q: So should I stop using all web apps for sensitive stuff?
A: If the data matters—banking, health, private conversations—use native apps with a verifiable distribution (App Store, direct download from a trusted source). Web apps are fine for non-sensitive tasks. Just don't assume the encryption protects you from the provider. It doesn't.
Q: Isn't this argument overblown? Aren't we safer with web crypto than nothing?
A: Safer than plaintext, yes. But the illusion of end-to-end security is dangerous—it makes people share things they'd never send in plain sight. The real risk is a false sense of security. Better to understand the limits and choose tools that match your threat model.