Web-based cryptography is always snake oil

Join the discussion

• Hacker News
• 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.

  by haburka
• "Thus the client-side code is always distributed by the operator of the web server."

  The same goes for client side code distributed by the operators of free "communication services", e.g., Meta (WhatsApp), Signal, etc.

  "In other words, web-based "E2E" applications claim to secure against malice on the part of the server operator using encryption implemented in client-side JavaScript, but this is obviously not true, since if the server operator was malicious, they could just push different client-side JavaScript."

  Another way to state this is the third party, e.g., the website (server) operator, incorporated as a so-called "tech" company, controls the client software

  "It is worth noting that this law also applies to non-web applications where the service provider supposedly being secured against is also the client software distributor; thus, the "end-to-end encryption" offered by WhatsApp and Signal, amongst other proprietary services, is equally bogus. (Both WhatsApp and Signal ban use of third party clients, and enforce this policy.)"

  The vociferous advocates of these "services" in online comments simply refuse to acknowledge this issue

  "A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against."

  "The problem is, of course, that "there's nothing we can do" isn't true. The service provider could develop and ship a backdoored version of the client software."

  Auto-updates

  The number of online commenters that praise auto-updates, is not small

  "There are at least two such cases:"

  It's possible a client app could have been "updated" with a backdoor, e.g., for some user(s) in some location for some period of time, and no one would be the wiser

  It's not possible to know how many cases of compromise by the third party there have been, whether forced or not

  Alt least two, perhaps many more

  "Eve: But, just to be sure, take this software. It'll encrypt your communications with Bob so that even we can't see them.

  Alice: ...Oh, neat. Thanks!

  Alice: ...But hold on... you supplied this software.

  Eve: Of course.

  Alice: So how does it prevent you from seeing my communications?

  Eve: It encrypts everything you send before it reaches us. We can't see a thing!

  Alice: But this software auto-updates, right?

  Eve: Right.

  Alice: So you could update it at any time.

  Eve: Right.

  Alice: So if you ever wanted to spy on my conversation, what's to stop you from just pushing an update to undermine the encryption?

  Eve: Ah... well... you know, that's just paranoid. Why would we ever do that?

  Alice: In other words, it can't secure my communications against you in case you turn out to be untrustworthy.

  Eve: Well... yes...

  Alice: So what exactly is it supposed to be securing against?

  Eve: OK, you have to trust us, but what about other people? There's all sorts of people trying to eavesdrop on things. So you have to trust us, good old Eve, but nobody else, at least!"

  Is "all sorts of people" referring to Eve's competitors and other Eve adversaries such as Eve's users

  Eve doe snot want her competitors to be able to collect the data, perform the same surveillance and provide ad services

  Eve does not want users to observe Eve's data collection or Eve's client-server protocol lest they might create their own client software

  by 1vuio0pswjnm7
• 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.

  by utopiah
• 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.

  by omgtehlion
• 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

  by amarant
• 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.

  by hypfer
• How about GPG distributed with a Linux distribution like Debian as a counterexample? It would be fairly difficult to backdoor GPG in that case without getting caught. Everything happens in the open both at the GPG level and the Linux distribution level. The binaries are signed by the distribution and are distributed by a bunch of mirrors. An evil Debian maintainer would have to make a change that was well enough disguised as something else to evade scrutiny.
  by upofadown
• > Isn't non-web-based cryptography affected (as per this take) in the same way but with extra steps?

  Yes, but it's a whole lot of extra steps spread across multiple independent parties, each of them adds large delays to the actions and increasing the chance that it is discovered long before it ends up on the users machine.

  When you hack GPG it will take years before it trickles down into every Linux distribution, especially LTS releases. And ideally, you want an encryption protocol, not one app, thus you have some people running GPG, some running Sequoia PGP and some running OpenPGP.js. If somebody fiddles with the encryption, different clients won't be able to decode the messages anymore and it will be clear pretty quickly that something is wrong.

  Meanwhile on the Web or smartphones, you remove or backdoor the encryption, everybody gets auto updated to the latest version and nobody will know that something went wrong.

  by grumbel
• I’d rather make up my own mind, read the docs/code. All I read was unsubstantiated claims, with zero real world evidence.
  by sscaryterry
• While there is _some_ truth to what they are saying, it is an unnecessarily hostile and nihilistic take, intentionally eschewing nuance.

  Often hot takes like this can serve a good purpose. I'm not sure that this does.

  by eximius
• > the code which implements a client-side web application is distributed by the given website

  Incorrect, and trivially falsifiable. Examples:

  - Self hosting, where you control both client and server.

  - Loading a web app from file:///

  - Loading a web app from localhost.

  The author's "no exceptions" is simply wrong.

  The author also seems to assume the same server is required to both serve the code and store/transmit encrypted messages which obviously isn't the case. In addition the statements about service workers are ignorant.

  The rest of the analysis is largely correct and the threat outlined (where somebody can replace your client) is a serious one that many underestimate. In particular the proprietary native mobile app model is vulnerable to this, as mentioned.

  by chr15m
• 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."

  by prmph
• Alright, I'm ready. These are engineering motivations, as you said. So, which one of these isn't a cost center? Because an insurance policy would handle the first two, but probably cheaper. Customers have repeatedly proven they will buy the product lacking the trust. Resisting mass surveillance? They are the mass surveillance. Which is now a legal compliance based cost center.

  * preventing insider abuse * reducing liability * improving customer trust * resisting mass surveillance

  by taormina
• If, say, Signal was completely controlled by the CIA[1] and was thus evil, then having incoherent cryptography as described in the article would be a feature, not a bug. Being able to reject law enforcement requests would produce a false sense of security for the people the CIA was interested in surveilling. Responding effectively to law enforcement requests would reduce the value to the CIA of the ability to secretly backdoor Signal.

  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

  by upofadown
• The word "if" is doing a whole lot of work in that first paragraph. Holding the entire world on its shoulders, so to speak.
  by tptacek
• PGP remains the only pretty good privacy

  (Said tongue-in-cheek, I don’t know if there’s other comparable systems out there)

  by wolttam
• Reminder: iMessage claims to be e2ee, but the on-by-default iCloud Backup on iOS backs up material that is sufficient to defeat this (either the endpoint keys, in the case of "Messages in iCloud" disabled, or the messages themselves, in the case of "Messages in iCloud" enabled).

  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.

  by sneak
• Contrary to the title this isn’t about the web but rather makes an argument against trusting suppliers to hide your messages from the same suppliers.
  by nailer
• in fact, this could be generalized more and doesn't neccessarily have to be about hiding messages. We've all heard the discussions about using VPNs "for privacy" (i. e. for hiding your IP metadata), when it's really just shifting trust away from your ISP and towards the VPN supplier.

  It always comes down to who the alternative party to trust would be. In the fictional dialogue, the alternative appears to be to not send the message. Which may or may not be the better option than to give Eve eavesdropping capabilities.

  by zzril
• The discussion on the proposed solution is interesting

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

  by prophesi
• 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/

  by captn3m0
• Anything you see rendered onto a screen is no longer secure though, or is it a hyperbole to phrase it this way?
  by evrimoztamur
• That is basically true for every such system. Trust Signal? They could ship a backdoor in the next release. Same with Threema, WhatsApp (if you want to trust it today) and other services. You can expand that to the operating system as well. And who able to verify hardware security, anyway?
  by cryptos
• 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.

  by jdw64
• 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
  by memoriyato3
• 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.

  by prmph
• 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