this is one of the problems content addressed stores like nix and ipfs can prevent. every version of the code is immutable and impossible to delete. if the devs update the "latest pointer" to a backdoored release users can just stay on the old version or move to a fork. and in the happy case (honest developer) you get all the benefits of auto update.
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.
> 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…
One thing you can do is have your adversary put their money where their mouth is and use the very same products, sourced independently, that they use to protect their own sensitive information.
There are limits to this of course. You can’t buy a TACLANE[1], but you can buy many of the other products[2] USG uses to protect its own classified information.
The 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.
Absolutely, and the claim is somewhere between nonsense and pedantry bordering on nonsense.
The exact same thing is true for, say, Signal. The provider delivers the client, and they aggressively block non-official clients from participating. So the “ends” in end-to-end are ultimately controlled by Signal. But as long as you trust the Signal company not to insert a backdoor into your client, it’s still true that the company can’t read your texts.
The 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.
If 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.
Many comments suggest that the definition and criteria proposed are infeasible and useless. They are not wrong.
But still it points out something the layperson misses (or even many tech-savvy people): An E2EE service from A does not provably protect your data against A.
Two 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 <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."
There are a lot of other implementations of this idea that don't necessarily rely on trust-on-first-use. The securedrop team explicitly includes malicious JS served by the primary-domain in the threat-model and made WEBCAT[0] as an outcome of that research. Their article on webcrypto is much better than this one.
The solution obviously is to go out-of-band:
> When a user visits a website that has enrolled in WEBCAT, before the site can load the content is checked against a signed manifest to ensure that it has not been tampered with (more on enrollment later). If everything checks out, the page loads normally. If, however, any content does not match what’s expected, the page load is aborted and a warning is displayed, protecting the user from potentially malicious content before it can execute.
Isn't non-web-based cryptography affected (as per this take) in the same way but with extra steps?
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.
As 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.
I'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 think it is fair to conflate it to be the Web.
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 executed at any moment, swapping implementation on the fly. And due to skills needed to actually read and understand executed scripts), so you can only believe and trust. At which point usual TLS is surely enough.
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.
This 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
Before reading this article, I used to believe that IT companies deeply respected users’ human rights, spending millions of dollars to build end‑to‑end encryption. But thanks to this very article, I learned that they were actually saving tens of millions in administrative litigation costs – costs they would otherwise have had to pay every month to respond to wiretap warrants.
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.
End-to-end encryption is about protecting data at rest on the vendor's servers. TLS only secures data in transit.
The article's argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.
Sure, the article makes good arguments about the trust that is still implicit in E2EE, but it goes too far in its dismissal of it.
I never believed that the messages were truly E2E encrypted and I know for sure when WhatsApp retroactively censored a message I sent to a friend a while back, I found that super sus.
Can you be sure WhatsApp retroactively censored a message? Implying someone else but the direct recipient could read and delete/change it? (I believe group chats are different, forgot the details.) I don’t want to be dismissive but.. well i dont believe this is the best explanation given just these observations.
this is one of the problems content addressed stores like nix and ipfs can prevent. every version of the code is immutable and impossible to delete. if the devs update the "latest pointer" to a backdoored release users can just stay on the old version or move to a fork. and in the happy case (honest developer) you get all the benefits of auto update.
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.
> 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…
One thing you can do is have your adversary put their money where their mouth is and use the very same products, sourced independently, that they use to protect their own sensitive information.
There are limits to this of course. You can’t buy a TACLANE[1], but you can buy many of the other products[2] USG uses to protect its own classified information.
[1] https://gdmissionsystems.com/encryption/taclane-network-encr...
[2] https://www.nsa.gov/resources/Commercial-Solutions-for-Class...
The 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.
> Isn't this conflating encryption with trust?
Absolutely, and the claim is somewhere between nonsense and pedantry bordering on nonsense.
The exact same thing is true for, say, Signal. The provider delivers the client, and they aggressively block non-official clients from participating. So the “ends” in end-to-end are ultimately controlled by Signal. But as long as you trust the Signal company not to insert a backdoor into your client, it’s still true that the company can’t read your texts.
The 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.
technically you could audit your local copy of tor source code, build it, and then never upgrade it.
still this wouldn't guarantee that all the other nodes are not compromised
If 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.
Many comments suggest that the definition and criteria proposed are infeasible and useless. They are not wrong. But still it points out something the layperson misses (or even many tech-savvy people): An E2EE service from A does not provably protect your data against A.
> The purpose of cryptography theatre is not to deliver actual security from a cryptographic perspective but act as a kind of magic spell
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.
Two 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 <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."
The discussion on the proposed solution is interesting
https://github.com/w3c/ServiceWorker/issues/1680
There are a lot of other implementations of this idea that don't necessarily rely on trust-on-first-use. The securedrop team explicitly includes malicious JS served by the primary-domain in the threat-model and made WEBCAT[0] as an outcome of that research. Their article on webcrypto is much better than this one.
The solution obviously is to go out-of-band:
> When a user visits a website that has enrolled in WEBCAT, before the site can load the content is checked against a signed manifest to ensure that it has not been tampered with (more on enrollment later). If everything checks out, the page loads normally. If, however, any content does not match what’s expected, the page load is aborted and a warning is displayed, protecting the user from potentially malicious content before it can execute.
[0]: https://securedrop.org/news/introducing-webcat-web-based-cod...
[1]: https://securedrop.org/news/browser-based-cryptography/
Isn't non-web-based cryptography affected (as per this take) in the same way but with extra steps?
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.
As 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.
I'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 think it is fair to conflate it to be the Web.
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 executed at any moment, swapping implementation on the fly. And due to skills needed to actually read and understand executed scripts), so you can only believe and trust. At which point usual TLS is surely enough.
But we are talking about protecting data at rest on the vendor's servers. Unless the vendor stores no user data at, how does TLS protect that data?
Your argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.
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.
This 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
Before reading this article, I used to believe that IT companies deeply respected users’ human rights, spending millions of dollars to build end‑to‑end encryption. But thanks to this very article, I learned that they were actually saving tens of millions in administrative litigation costs – costs they would otherwise have had to pay every month to respond to wiretap warrants.
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.
End-to-end encryption is about protecting data at rest on the vendor's servers. TLS only secures data in transit.
The article's argument is a bit like saying TLS protects plain-text passwords in transit, so there is no need to store them in hashed form in the database.
Sure, the article makes good arguments about the trust that is still implicit in E2EE, but it goes too far in its dismissal of it.
having E2E encryption is a marketing feature, you need it if you want to be competitive in the market, so this is another incentive to add it
I never believed that the messages were truly E2E encrypted and I know for sure when WhatsApp retroactively censored a message I sent to a friend a while back, I found that super sus.
Can you be sure WhatsApp retroactively censored a message? Implying someone else but the direct recipient could read and delete/change it? (I believe group chats are different, forgot the details.) I don’t want to be dismissive but.. well i dont believe this is the best explanation given just these observations.