This is both true, and also useless: pretty much any E2E system is falling under this definition.

By definition you can't protect yourself from the entity that provides you the software you use, because you have now way to guarantee that they aren't going to backdoor you.

That doesn't mean it's snake oil though, as the entity you want protection against is generally not the software provider but a third party. Using e2e from a US-based entity means you are prone to spying from the US government, but at least you know you're reasonably secure against the IRGC, the Chinese intelligence service, the FSB, and so on.

It also means you are safe from data leaks, which are by far the most common threat today.

No system can be secure unconditionally, it's always secure under a particular threat model. And in practice “the attacker is able to deploy arbitrary code on your behalf for an extended period of time without being detected ” is a much narrower attack surface than “the attacker is able to obtain read-only access to your DB or your backups for at least a few minutes”. In the former case, the encryption being broken is also the least of your concern, as you've basically given remote access to all of your user's devices at this point…

Isn't this conflating encryption with trust? Of course whoever claims to encrypt your data needs to be trustworthy, and whether they actually are is another matter, but If my app allows you to generate a client side key, export it and use it to encrypt data client side and we only get the encrypted data, that is verifiably valid encryption.

I could be malicious and also send a copy of your actual plaintext to the server as well, but that is trivial to check (unless I'm being targeted and I am the only user that gets the malicious code, still, I can check). It's a risky proposition for an organization with vested interest in being seen as pro privacy.

But I get it, different conversation if the government coerces you, and the outcome depends on your bank account and ability to handle pressure.

E2E makes it less likely that your information will get hacked and reduces the risk that employees will access your information.

The reality is that these security claims are generally subject to internal audit and would need company wide collusion and the risk of a whistleblower or disgruntled former employee if they were violated provides some level of protection that a large tech company offering of e2e doesn’t mean some level of benefit from the user compared to perfect encryption security.

for this to work in practice it needs to be paired with reproducible builds, open source and either p2p or server choice (use signal.mydomain.net instead of signal.org). but these are all things that already exist and none of them is really hard to set up. the harder problem is distributing community block lists of bad package versions but that can be done with atproto or simple ublock style filter files.

i think the real bottleneck for adoption is that the only browser with built in ipfs support is brave, the one thats full of crypto ads and affiliate link fraud. i dont know if firefox would ever take it up or we need to build a brand new browser. or find a way to do it one layer down with a system service.

This reminds me Telegram, which promises to be secure, but requires giving it my phone number, which is the most insecure thing one can do.

1. Aren't E2EE systems designed to prevent decryption of content already created in the past sitting on the vendor's servers? Yes, the vendor could go rogue, but, assuming they currently have implemented E2EE right, it means any change to the client can only compromise content created in the future from that point onward, no? So why is the article implying Apple could have provided a back-doored iOS to bypass the encryption for existing content?

2. I also don't find the argument that E2EE is only a legal trick fully convincing. There are several other incentives for a vendor to implement it apart from avoiding legal issues: preventing insider abuse, reducing liability, improving customer trust, and resisting mass surveillance

These are real engineering motivations. The threat model is not: "Protect you if <vendor> becomes actively malicious tomorrow." Its more like "Protect messages stored on <Vendor>'s servers from attackers, employees, hackers, routine legal requests, and passive surveillance."

https://github.com/w3c/ServiceWorker/issues/1680

It's on the level of "you can't trust your OS unless you wrote it yourself" -righteous sounding but utterly stupid in practice

This effect was seen in the Apple vs FBI incident described in the article. The public perception of Apple as a brave defender of user privacy was greatly increased due to that dispute. For all we know, the FBI was in on the conspiracy. In return they might receive the fruits of such surveillance with the only limitation that they would have to disguise the source with parallel construction[2].

[1] https://en.wikipedia.org/wiki/Crypto_AG

[2] https://en.wikipedia.org/wiki/Parallel_construction

Articles like this remind me that non-devs think "end-to-end encrypted" means it's always the case and they can't turn it off at will. This is not the case.

A sophisticated actor might as well also control the application that ends up on my device. It does not have to be the same delivery mechanism as long as I did not write it myself.

So all cryptography is snake oil?

___

I mean I kinda sorta get the point and there would be some merit to discuss there, but the weird framing makes that very hard to do.

Of course it's easier to break web e2ee if you are for example cloudflare compared with someone also having to compromise the Debian repos.

But that's not what snake oil means.

I think what makes the Web special is precisely that there are different browsers beyond Chromium. If the Web was Chrome I would tend to agree but even though popular I do not think it is fair to conflate it to be the Web.

Some might call this a “cryptographic innovation.” I call it “the technical outsourcing of legal disclaimers.” Unfortunately, I don’t seem to have a Harvard Law School legal team on my side.

This means that, in practice, iMessage is not e2ee.

Before you say "But what about Advanced Data Protection that enables e2ee for iCloud Backup?" - virtually nobody has this on, Apple prohibits you from turning it on in the UK, and even if you enable it - the people you iMessage with don't, so your conversations are in their backups. This means that if either endpoint of the iMessage conversation is in the UK, and both parties have iCloud Backup enabled (the default), then your iMessages are not e2ee as a non-endpoint has an escrowed copy of the plaintext or keys.

Also no OS integrated system that does this for you automatically / conveniently has ever existed that was widely adopted because that application would have the ability to read all of your private communication, and impossible to install on an uncracked phone.

Still it would take literally minutes to vibe code an app that sits in front of a WhatsApp client and automatically handles these things. Maybe the future is just to write it yourself (not the security) so you can trust it and it’s convenient.