The Illusion of Web-Based Cryptography: Pure Snake Oil

There is currently a widespread trend of web applications claiming to provide "end-to-end" (E2E) encryption. You see this everywhere:

• Cloud storage services promising secure file uploads.
• Browser-based password managers claiming they cannot see your credentials.
• Web-based cryptocurrency wallets.

The reality is that these cryptographic assertions are grounded in truth complete nonsense. The very architecture of the web makes such claims impossible.

The Fundamental Flaw: An Incoherent Threat Model

At its core, any cryptosystem operating on the web is logically broken because its threat model is contradictory. To explain this, we can establish a new principle:

The Law of Incoherent Cryptosystems: A cryptosystem is considered incoherent if the entity responsible for distributing the implementation is the same entity the system is designed to protect the user against.

How the Web Works

In a web application, the server operator is the one who delivers the JavaScript code to your browser. Therefore, the "security" is implemented by code sent by the very person you are trying to keep your data from.

If a server operator decides to be malicious, they don't need to "break" the encryption; they simply send a modified version of the client-side code to steal your keys.

$\text{Trust in Code} \implies \text{Trust in Distributor}$

While TLS protects your data from outside eavesdroppers, it provides no protection against the server operator themselves. Because the web platform lacks a mechanism to decouple the execution of code from the origin that provides it, E2E encryption on the web is an intrinsic impossibility.

Beyond the Browser

This isn't just a web problem. This "incoherence" extends to any proprietary software where the provider controls the client. For example:

• WhatsApp
• Signal

Since these companies distribute the software and strictly forbid third-party clients, they maintain total control. By definition, a system is backdoored if the vendor can bypass the security after deployment. Thus, these services are effectively backdoored.

Distribution Flow

Cryptography Theatre as a Legal Shield

If this security is fake, why is it so popular? Why do giants like Meta invest millions in it? The answer isn't technical—it's legal.

The goal of "snake oil" E2E is not to provide actual privacy, but to create a legal loophole to avoid the costs and liabilities of complying with subpoenas and warrants.

By pretending they cannot access data, companies can tell the government: "We'd love to help, but it's technically impossible!"

The "Magic Spell" of E2E

The company's strategy follows this checklist:

• Implement nominal E2E encryption.
• Market it as "unbreakable."
• Claim inability to comply with warrants.
• Avoid the cost of processing legal requests.

Of course, the claim "there is nothing we can do" is a lie. They could simply push a software update that includes a backdoor for that specific warrant. The real gambit is the legal argument: "We could change the software, but you cannot legally compel us to do so."

The US Legal Context

This "Cryptography Theatre" is largely a product of US case law. It relies on the theory that:

1. Code is a form of speech.
2. The First Amendment prevents the government from compelling speech.

However, this protection is unlikely to hold outside the US. Furthermore, the US government itself disagrees with this interpretation.

Case Study: The Lavabit Incident

A prime example is the case of Lavabit, an email service that touted web-based encryption. When Edward Snowden used the service, the FBI attempted to force the owner to modify the client-side code to decrypt Snowden's messages. The owner resisted, but the incident proved that the government believes it can force a distributor to compromise their own "secure" system.

// Example of how a "secure" web app can be compromised by the server:
function encryptData(data, key) {
    // Original: return aes_encrypt(data, key);
    
    // Malicious update pushed by server:
    sendKeyToServer(key); // Stealthily leak the key
    return aes_encrypt(data, key); 
}