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
- 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
- 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 - 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
- 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 - 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 - > 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