Web-based cryptography is always snake oil
Web-based end-to-end encryption is criticized as “snake oil” because the same party that serves a web app can silently change its JavaScript to disable or backdoor encryption at any time, especially via auto-updates, meaning users must ultimately trust that provider. Commenters debate how meaningful this limitation is in practice, noting that all cryptographic systems embed trust in software distributors, but also that web apps are uniquely easy to tamper with compared to audited, reproducible native binaries or open ecosystems with multiple independent clients. Many see E2EE as still valuable for protecting data at rest, limiting insider abuse, and reducing breach impact, while others argue its strongest guarantees rarely extend to protection against the service operator itself.
Core argument: incoherent cryptosystems & web crypto
- Central claim discussed: any cryptosystem is “incoherent” if the same entity both distributes the client and operates the service it’s supposed to protect against, especially with auto‑updates.
- For web apps, server‑controlled JavaScript and service workers can be changed at any time, so the provider can silently remove or weaken encryption for specific users.
- Several note this applies not only to web apps but also to proprietary “E2EE” messengers and mobile apps that auto‑update.
Trust, updates, and threat models
- Many comments stress: you always have to trust whoever supplies your software; you cannot fully protect against them becoming malicious or coerced.
- Auto‑updates (including time‑bombed clients) effectively give vendors remote code execution and the ability to selectively backdoor.
- Others emphasize threat models: E2EE can still be valuable against third parties, mass data breaches, and insiders, even if it can’t defend against the vendor plus their government.
Value of E2EE vs TLS / “snake oil” claim
- Critics of the article say calling web crypto “snake oil” is overstated and ignores real benefits:
- Protects data at rest from DB leaks and casual/insider access.
- Raises the bar vs simple read‑only database compromise.
- Supporters counter that if the provider can silently ship a keylogger or plaintext uploader, claims like “we can’t read your messages” are at best conditional marketing.
Legal, business, and government angles
- Some argue E2EE is also a legal strategy: shifting the burden by making compliance with wiretap orders “impossible” in practice.
- Others see real engineering incentives (liability reduction, insider abuse prevention), though skeptics question whether they outweigh business incentives for surveillance or government cooperation.
- Nation‑state threats are debated: some see US‑based E2EE as mainly vulnerable to US agencies; others say this is largely academic for typical users.
Mitigations and alternative designs
- Suggested mitigations: open source, reproducible builds, anonymous distribution, content‑addressed storage, third‑party code attestation (e.g., WEBCAT‑style manifests, external code verification services), and protocols with multiple independent clients.
- Several note that such practices are common in traditional software distributions but rare for web apps, making web‑based E2EE particularly fragile today.