[flagged]
Web-based cryptography is always snake oil
11–20 of 137 posts
Re: Web-based cryptography is always snake oil
#12As a developer, when some company says that some platform is end-to-end encrypted, you know that it means "the default client provides encryption, by default" but you know very well that they could selectively turn it off for anyone, at any time and it may be impossible to know that they did this this unless the target was tech savvy and actively monitoring their network packets during the brief period that encryption was turned off... Especially on the web, they could just serve a different JavaScript library with a backdoor to a specific IP address only and the target would have no idea.
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.
Re: Web-based cryptography is always snake oil
#13This entire article is... Nonsense? It categorically dismisses e2ee, without any supporting evidence whatsoever, other than the notion that a provider might push a update that doesn't encrypt messages anymore.
It's on the level of "you can't trust your OS unless you wrote it yourself" -righteous sounding but utterly stupid in practice
Re: Web-based cryptography is always snake oil
#14The entire argument is based on the definition of an “Incoherent cryptosystem”, which is too restrictive to be useful for cases that you want eg. Tor is also developed and distributed by Tor people and it is supposed to protect you against everyone, including the Tor people.
I think the article raises interesting questions about trust, but I am also doubtful if the definition of the “incoherent cryptosystem” is useful:
The article argues that Signal is an incoherent cryptosystem, because they ship the E2E-encrypting Signal client (and could, hence, backdoor it) that should protect me, the user, against their own infrastructure snooping on me.
As I understand the definition, we would not have an incoherent cryptosystem if I used a third-party client on Signal's infrastructure. Said Non-Signal client would implement E2E encryption, and use the Signal infrastructure, so the entity running the infrastructure is different from the entity providing the client. But is this any better?
Couldn't “Non-Signal Corp.” be coerced by the government (or decide to build a backdoor for their own gain) just as easily as “Signal”?
So I don't think it matters if the entity distributing the client is the same as the one running the infrastructure. It matters if I trust the client. How to implement this (audits, OSS, version pinning, ...) is still an open question to me.
Re: Web-based cryptography is always snake oil
#15I'm confused, is the argument that it doesn't work because Google is fueled by surveillance capitalism? If so what about Apple which is only partly so? What about Firefox and in particular its de-branded ones without Google search as default? 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 t…
I could not find anything about google or other browser vendors in the article. My take is that you should trust provider (developer, hoster) of said encryption app to send you actual implementation, not something that looks like the real deal, but does not encrypt anything. From a regular user's point of view: you can not inspect what you run (due to technical reasons, that on the web anything can be downloaded and…
Like I said I'm confused, genuinely trying to figure the article out.
"A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against."
What is the cryptosystem then on the Web? Who is the entity? It's not the server or the Website so I don't see what's left except the browser and browser vendor.
Re: Web-based cryptography is always snake oil
#16> A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against.
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…
Re: Web-based cryptography is always snake oil
#17Two problems I see with the authors argument. Maybe someone more knowledgeable can chip in to correct me if I'm wrong:
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 becomes actively malicious tomorrow." Its more like "Protect messages stored on 's servers from attackers, employees, hackers, routine legal requests, and passive surveillance."
Re: Web-based cryptography is always snake oil
#18Earlier quoted context omitted.
I could not find anything about google or other browser vendors in the article. My take is that you should trust provider (developer, hoster) of said encryption app to send you actual implementation, not something that looks like the real deal, but does not encrypt anything. From a regular user's point of view: you can not inspect what you run (due to technical reasons, that on the web anything can be downloaded and…
Like I said I'm confused, genuinely trying to figure the article out. "A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against." What is the cryptosystem then on the Web? Who is the entity? It's not the server or the Website so I don't see what's left except the browser and browser vendor.
There's also a long list of government (or subpeonable) entities on your certificate trust list.
Without which TLS is not gonna work.
The article is arguing that in practice you could just send your "encrypted" communications to the browser vendor, or one of the governments on the certificate root list, or someone else in the distribution chain, and have them be the middle man. The security properties of your communications would be the same. Hence "snake oil".
Things like stapling don't change this much, or reduce to TOFU.
Re: Web-based cryptography is always snake oil
#19The author is basically saying if you participate in any part of the encryption process, you're deceiving users in saying things are e2e encrypted.
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.
Re: Web-based cryptography is always snake oil
#20If you’re not running PGP commands yourself to encrypt and read your messages, it’s not secure.
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.