Web-based cryptography is always snake oil

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.