Discussion summary
Discussions highlight skepticism about the security of web-based cryptography, emphasizing that client-side encryption often relies on trust in providers. Experts debate whether non-web cryptography faces similar issues, with some advocating for open-source tools like GPG.
What the discussion says
- Web cryptography is often considered insecure unless run locally.
- Trust in service providers is a recurring concern.
- Open-source tools like GPG are viewed as more secure.
“If you’re not running PGP commands yourself, it’s not secure.”
“Client-side code is always distributed by the web server operator.”
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Sounds logical to be honest.
The E2E encryption is not protecting you, it's protecting the company providing the software.
The only thing that is legit is the local use of PGP. But it's a shame we don't really progress much.
by hoppp - Gajim recently got a modern PGP implementation: https://gajim.org/posts/2026-06-18-gajim-2.4.7-released/by zaik
- > 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.
by Panzerschrek - 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.by hrmon
- > A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against.
So once you’ve solved this problem, you’ll need to ensure there’s no software running which can capture the screen and/or keyboard inputs.
Then make sure that every peripheral is running firmware which you know isn’t compromised.
Then make sure the hardware itself is not compromised.
Then make sure the user’s screen is not being recorded. Or visible on any CCTV camera.
There’s a line between utility and perfection. Everything in the real world lives somewhere to the left of “perfection”.
The article is not wrong that there’s a threat model that makes our current ways of doing E2EE less than perfect, but it doesn’t impugn the actual E2EE implementation at all, and is not much different to saying “your data is still not secure because someone could take screenshots!”
by d1sxeyes - I feel the legal part is on point. It's also increasingly used by governments to have their cake and eat it too: "We'll completely lock down your devices and run all kinds of analysis on your data, but don't worry, it's all done on-device and all communication is encrypted, so our promise to protect your privacy is kept!"by xg15
- Kind of a weird concern to be reading on HN, where the sentiment is overwhelmingly that these kinds of systems should be exempt from warrants and discovery.by tptacek
- I don’t agree with this. While, it may be true that E2E carries risks of government surveillance.
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.
by daft_pink - 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.
by tancop - Signal clients have a built in time bomb in each version to "force" you to upgrade after a period of time. It can, of course, be patched out (and I patch it out, along with other fuckery such as disappearing messages/expiring messages/remote delete) but to say that "reproducible builds + content-addressing distribution" solves this problem is basically false in practice.
Also, on iOS, almost everyone has app autoupdates turned on because that's the default.
by sneak - Something I don't understand about this argument, which has been made before, is you can tie JavaScript to a specific hash with SRI. So you release the cryptographic code in public where it can be audited and then what runs in the browser verifies that was what loaded.
The host could inject malicious JavaScript from the host or change libraries but I feel like this is an avoidable problem because it can be audited much more easily than expecting users to audit JavaScript every time. People could even build known, trusted, web frontends. So I think there are mitigations if not ways to assure the browser is running trusted code.
- 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.by somezero
- 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
by memoriyato3 - 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.
by TuringTux - 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.
by jongjong - Yeah, this argument is nonsensical as presented.
If web-based encryption is snake oil, then science-based medicine is also snake oil, because you trust your doctor not to secretly give you sugar pills instead of the real thing. In fact, this argument applies even more strongly to medication, because I can't really determine what a pill does, but I can determine what an app or website does and what it sends to the server.
- 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.
by figassis - > 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.
by p-e-w - > 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…
by stymaar - > 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.
Framing this in terms of governmental espionage is nonsensical. Using e2e from a US-based entity makes you completely sure that the US government is spying on you, because they assert direct control over the software you are running. There is no venue to seek justice against an unlawful contract if the government is in on it.
You should instead take a step back into reality and consider data misuse by normal non-government actors. Facebook claiming e2e encryption is a contractual matter, that you can litigate. That's where the actual protection is. That's also why real business demands not "unbreakable encryption" but reliable marker for access and tampering. It is much more useful to have a record of who accessed the data, than a claim that it's impossible.
by delusional - > 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's not completely true. If I can control when (and if!) the software updates and if there is some kind of vetting process to verify that the version I'm currently running does not contain a backdoor, I can treat it like a third party with respect to the server.
I agree with you though that most current software that are made to auto-update at any time without any oversight do not fall under this umbrella. Web apps definitely don't fall under it.
by xg15 - > 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.
There are levels to this (hermetic/reproducible builds & attestations, as one example). In fact, TFA is harsh for the only case it wants to make an example out of, WhatsApp Web:
https://blog.cloudflare.com/cloudflare-verifies-code-whatsap... & https://engineering.fb.com/2022/03/10/security/code-verify/Code Verify works in partnership with Cloudflare, a web infrastructure and security company, to provide independent, third-party, transparent verification of the code you're being served on WhatsApp Web. We hope this gives at-risk users peace of mind.by ignoramous - > the entity you want protection against is generally not the software provider but a third party.
This. The author is dismissing the whole web-based cryptography, or any end-to-end cryptography for that matter, on the basis of a one-dimension analysis.
by adirelle - > 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.
Well that’s just wrong, just make it open source and do reproducible builds
by echoangle - > 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.
You don't need E2E for that, using https/TLS for transport and servers hosted in the US would be enough.
by xg15 - 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...
by bigfatkitten - > This is both true, and also useless: pretty much any E2E system is falling under this definition.
This is not true. I can build Signal from source from GitHub, and use Signal-the-service with the client (which did not come from Signal, but GitHub/my compiler).
Many cryptosystems are like this. In any case, if you are getting something from the App Store, you can get it once and disable autoupdates, which prevents the service provider (presuming they are the same as the people who published the app) from backdooring you at some point in the future. Alternately, even with updates, unless Apple is colluding with them to serve only you* a specific backdoored app, you can at least be reasonably confident that it's not specifically backdooring only you* in an undetectable fashion.
by sneak