> 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 obvious counterexample is NOBUS[0] vulnerabilities, and intentional backdoors like the Clipper Chip[1] or Dual_EC_DRBG[2]: if you genuinely believe you are the only one who could possibly exploit it, there's no reason to avoid using it.
A more modern example is probably the NSA aggressively pushing[3] for replacing classical encryption with post-quantum encryption, rather than taking the more conservative and probably-more-secure approach of layering the two - while at the same time mandating the use of two layers of those same algorithms for their own use[4]!
> The obvious counterexample is NOBUS[0] vulnerabilities, and intentional backdoors like the Clipper Chip[1] or Dual_EC_DRBG[2]: if you genuinely believe you are the only one who could possibly exploit it, there's no reason to avoid using it.
The problem with these examples is that they weren't used in national security systems, which are the systems for which NSA has a legislated defensive responsibility.
Clipper was designed for use by the public; it was not intended to ever be used to protect classified (or even sensitive unclassified) information at all.
Likewise with Dual_EC_DRBG. The CSfC component requirements drew from the Common Criteria Protection Profiles, where Dual_EC_DRBG was never an option.
The NSA isn't aggressively pushing for PQC; the industry is. Note that the PQC standard we have was the product of a competition won by European academic cryptographers.
That is not what the comment to which you replied said.
There is a consensus about pushing PQC and about the PQC standard.
The dispute is about something else, about whether the current Diffie-Hellman based key establishment algorithms should be immediately and completely replaced by PQC (which is what NSA pushes), or to be more prudent and use for some time both methods (so that the key exchange cannot be broken when any of the 2 algorithms is broken), to afford more time for gaining confidence in the standardized PQC algorithms, until eventually one might decide that it is reasonable to omit the current algorithms.
What NSA wants reduces somewhat the costs, but not by much, because PQC is much more expensive, so most of the cost is determined by it and not by the classic algorithms, even when they are used together, and also because keeping the current algorithms does not require any development work, as there are mature implementations in SW or in HW for all applications. The opponents argue that this small cost reduction is not worthwhile, because it eliminates the serious risks that flaws may be discovered later in the current PQC standards.
Moreover what NSA wants would complicate the protocols, because many would not accept the risks of the NSA variant, so it would remain optional to omit the classic algorithms, increasing the number of choices in the protocol, which is always undesirable in security protocols.
No, I'm very clear on what the question was asking, and it is not in fact "NSA" driving this process.
This is 100% Daniel Bernstein drama. Bernstein is upset that the NIST contest selected MLKEM (Kyber). He's been running a yearslong crusade to impeach the standard, up to and including opposition to lattice cryptography writ large, despite himself signing on to a lattice entrant (SNTRUP) to the PQC competition.
Over the last several months, the focal point of this crusade has been the IETF TLS Working Group, where Bernstein has been canvassing opposition to an RFC that will establish code points and documentation for pure, non-hybrid MLKEM TLS. Few systems in the near future are likely to use pure MLKEM TLS, but there are conceivable systems that we can foresee needing the option: for instance, embedded systems like smart meters that do ECC today, and could do MLKEM if it was urgently needed because of a CRQC, but couldn't practically do both.
The arguments being made on TLSWG are in spectacularly bad faith. People have varying levels of confidence in pure MLKEM (the closer your job title is to "cryptography engineer", the more likely it is you think hybrids are silly). But outside of the federal government itself, nobody in the entire world is being forced to use pure MLKEM; the entire controversy is about documenting what TLS would look like if you needed pure MLKEM.
The "NSA" stuff is just more innuendo.
Apart from bytes on the wire, MLKEM is not in fact "much more expensive" than 25519. Also, you have the maturity argument wrong; it's not a concern that risks/flaws will be discovered "in the standards".
Your argument would be far more charitable if NIST had not already been caught pushing a broken standard at the behest of the NSA before. DJB might be combative and somewhat caustic, but the one thing he's never been, given enough time in the retrospect to show it, is wrong.
The logic you're using here would be just as valid in a campaign against SHA2. More valid, in fact, because unlike MLKEM, which was designed by European academic cryptographers, the NSA actually designed SHA2.
> As part of its efforts to foil Web encryption, the National Security Agency inserted a backdoor into a 2006 security standard adopted by the National Institute of Standards and Technology, the federal agency charged with recommending cybersecurity standards. Credit Patrick Semansky/Associated Press
Even if you believe they're lying, or think that it's impossible to know because it may be a kleptographic backdoor... the latter at least is understood to be a unique property that most other algorithms do not share, so I think for that reason alone it's enough to assume it is backdoored, insofar as that we should tell people to stay away from it regardless.
There is no source in the article to support that claim, it links to another article where it merely says that people suspected it of being backdoored, but those people had no proof either. There are objective reasons why it's not a good idea to use compared to better algorithms, but I wish the reasoning was not solely based off of a conspiracy theory or hate for the NSA.
> 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.
> This is not true. I can build Signal from source from GitHub
Sure, but can you find an NSA-designed backdoor in the source code?
> you can get it once and disable autoupdates
Try doing that with Signal, and you'll be unable to connect to the main network in just a few days because you get out of sync. Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code?
What you describe may be possible for an intelligence agency, but completely out of reach for an individual.
> unless Apple is colluding with them
Given the most likely adversary is the US intelligence with a warrant, it's absolutely not far fetched to assume that in your threat model.
> you can at least be reasonably confident that it's not specifically backdooring only you
>> This is not true. I can build Signal from source from GitHub
> Sure, but can you find an NSA-designed backdoor in the source code?
You're moving the goalpost. They were responding to the claim suggesting it's impossible to get non-Signal provided signal.
>> you can get it once and disable autoupdates
> Try doing that with Signal, and you'll be unable to connect to the main network in just a few days because you get out of sync.
That's demonstrably false. On one of my idle/backup phones I'm using Signal 8.8.2, released in April 2026, almost 3 full months ago. It can not only connect to the network but everything works, with every contact.
You might think of the official Signal client expiration, but that's client side (meaning that you can compile and use the version that doesn't have it) and..... 90 days, not "a few".
I don't have a concrete number for the server side of enforcement though (minimumVersions seems to be populated at start time, with the defaults not committed to the repo). It's not entirely unreasonable to assume that the lowest official supported version is the one that introduced the concept of usernames, and the only meaningful capability test is SPQR.
> Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code?
I think disabling auto update was shown as a possible strategy against a silent, targeted auto update. Not a way to remain protected against the general CVEs.
> You're moving the goalpost. They were responding to the claim suggesting it's impossible to get non-Signal provided signal.
That was never my claim. The claim is that you cannot protect youself from Signal being malicious if Signal is the maker of the software. Compiling the software yourself doesn't help against the kind of adversary in the threat model.
> That's demonstrably false. On one of my idle/backup phones I'm using Signal 8.8.2, released in April 2026, almost 3 full months ago. It can not only connect to the network but everything works, with every contact.
Lucky you, you only need to fully audit the codebase every 3 months.
I'm using the Signal apk directly so I'm painfully aware of the frequency of the breakages.
> I think disabling auto update was shown as a possible strategy against a silent, targeted auto update. Not a way to remain protected against the general CVEs.
I don't think you understand my point. I'm not talking about the CVE being exploited against you. The CVE will just push you to download the compromised update, breaking your “security through lack of update” policy.
Now the argument is shifting. It started out as "a cryptosystem can't be secured from the entity in control of its supply", and now it's "a cryptosystem can't be secured even given its source code because the NSA".
I don't really agree with much of anything you've said in this thread, but the only thing I'm pointing out here is that your argument has shifted and is chugging heartily towards non-falsifiability.
No the argument hasn't shifted. The core point is that any time you use a piece of software, you have to have some level of trust towards the entity that gave you the said piece of software.
The way I responded to one particular example “what if I download Signal and compile it myself” is just that a particular example, not a shift in argument.
If you think there's no trust assumption in the distribution of software, feel free to provide actual arguments to refute that argument of mine, because so far your comments have been disappointingly lacking in substance.
If you get an open source app from the App Store, is there any assurance it actually reflects the code in the repo? I’d think the signing step happening in isolation opens the door to tomfoolery.
> 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.
Craigslist used to have a Rants & Raves section for exactly these kind of things. I think they still have, but in old times it used to be so happening! Maybe hacker news needs to have one.
But claiming that your system is end to end encrypted means that you are claiming protection from you and your system. This is mainly a truth in advertising issue.
> means that you are claiming protection from you and your system.
Not necessarily. I push for e2ee everywhere I can for a completely different reason: when (not “if”, “when“) we get breached, we cannot leak sensitive data we don't have.
Only if you manage to deploy malicious code and have it stay there undetected. But in practice this is much harder than having access to a DB or a backup for a few minutes (that's all it takes to leak data).
(Just as an example, at my current employer, out of 8 people in the company, there are 8 people who have credentials that permit at least some db access in one way or the other (anyone that has at least one of this job: customer support, account managers, data scientists, devs). There are only 3 people who can push changes to production, and you need 2 out of 3 to do so, and all of three get paged when a release happen. Of course it's not infallible, but the probability of the app being corrupted is orders of magnitude lower than the DB being breached, by the mere scale of the number of people who have access to these things. And again, you only need transient access to the data to leak it, when you need persistent access to do damage by corrupting the code. Most companies I worked for had an even worse ratio between people having access to some sensitive data and people having the ability to push corrupted code in production).
> 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.
> This would be extremely difficult, I would say impossible from a practical standpoint.
It's not only practical and possible, it's so common it even has a name in software engineering circles: change control. It boils down to this: you delay installing the software until it's been reviewed, tested and deployed by others. Or as Linus would put it, until the many eyeballs have had their say.
As for "the person in control of the platform": the solution is to remove some of that control. You make new versions of the software available for anonymous download, so the provider has no idea who is upgrading. All open source distributions provide their software in that way. No proprietary platforms I'm aware of do, because they want a "billing relationship" with the customer. Once downloads are anonymous, the owner of the software can't target individuals with a tailored Trojan Horse binary. Everyone gets the same binary, and so there are lots of eyeballs looking at it.
The final piece of the puzzle is reproducible builds, which ensures the many eyeballs can see the code use to build the binary.
All this has been around for a while now, so it's largely a solved problem in open source distributions. The problem with web-based cryptography is it isn't managed like an open source distribution. Downloads aren't anonymous, the source isn't available or signed, and it changes so fast change control isn't possible. So yeah, as things stand it's snake oil. But it doesn't have to be - it's just the way things are now.
> 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.
But that's OP's point. If the server is pwned, the hackers can simply change the front-end of the app and have it send the confidential data to wherever after it was decrypted on the client.
> 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…
Data breach occur every day, rootkits being covertly deployed in production apps for a substantial period are much rarer. E2ee only protects against the former, like a safety belt only prevent you from frontal shocks. Nobody would say they are snake oil because of that.
I would say that they are snake oil because of that. Data breaches occur more often than rootkits because most developers see that this path adding easily-removable encryption does nothing in the long run.
> Data breaches occur more often than rootkits because most developers see that this path adding easily-removable encryption does nothing in the long run.
That logic makes no sense. A rootkit is much more valuable than a data breach (because it gives you access to a compromised device), the reason why you don't see more of them is because it's much harder to pull off, not because people don't use e2ee…
(For instance, if you can replace an e-commerce website's code with your own, you get access to the user's payment information, which you can't usually get from their DB since it's generally handled by the payment processor, or to the user's plaintext password…)
Anyone using reverse proxies, CDNs or anti-DDoS services already voluntarily give full MITM privileges of their unencrypted data to companies like CloudFlare, Amazon, Akamai, Fastly, etc., which is most of the top sites on the internet and a large percentage of the overall internet traffic.
>...pretty much any E2E system is falling under this definition.
The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example. There are other related issues but the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging which makes it so bad as to be worthless.
> 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.
But with repro builds and system transparency, hiding backdoors is impractical.
Not really, time and time again people have abused their position/influence to build backdoors almost into everything for good or bad reasons. The whole idea of third party audits was to ensure that there are checks and balances. Then again the auditors are lowest paid to get stuff done and they take word of the company for most part.
On other hand its quite natural, security is not really getting you direct revenue so business is least motivated in investing it or say continuously investing in it. The ones that do are doing partial lip service for most part.
> 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.
I think the whole US vs. non-US thing is total crap and there's nothing you can reasonably do with it in any direction, but I always think it's important to point out that US signals intelligence can lawfully compromise foreign communications; that's literally their chartered purpose.
> there's nothing you can reasonably do with it in any direction
I wholeheartedly agree. That's why bringing nation state threats into these kinds of discussions is so pointless. If you want security from governments, the amount of security work you have to do is so far beyond what any reasonable person is willing to endure that it makes no sense to talk about on hackernews. That stuff is for real professional discussions at real professional congresses.
> I think the whole US vs. non-US thing is total crap
It's not. US companies can be subpoenaed in the US.
> I always think it's important to point out that US signals intelligence can lawfully compromise foreign communications; that's literally their chartered purpose.
Of course they can. But it's significantly easier to get a warrant to target a company under US jurisdiction.
Foreign companies don't have to be subpoenaed. NSA can simply break in and take whatever they want, lawfully. In light of that, the warrant point you're making doesn't make sense: they don't need a warrant to go after foreign assets.
The NSA can break in the same way the Mossad can assassinate you anywhere in the world. That doesn't mean it's a it's going to happen anytime soon unless you're an exceptionally high priority target. Authorities getting legal access to your personal informations from US companies on the other hand is routine practice. Equating the two is a crazy take.
By the way, you read the argument completely backwards in the first place: the original argument was that even if using an American company means the US law enforcement have full access to your data if they want to, your data is still pretty safe from anyone else there (unless, of course, if you are a high priority target again).
See the original sentence:
> 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.
Saying someone's argument is “total crap” without even having taken enough time to properly read the sentence you're criticizing is kinda lame IMHO.
Maybe if you made your point straight instead of making laconic remarks this discussion would be more constructive…
All I got from your few words is that apparently you consider the NSA breaking into a random foreign app a reasonable threat model to design around. Abduction from the CIA being only marginally more unlikely, why bother with anything?
Or maybe I misunderstood your point but then again when you can't bother writing down two consecutive sentences how am I supposed to read your mind?
> 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:
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 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
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.
Signal does not aggressively block non-official clients. I constantly use a modified version of Signal Desktop containing a small set of my own patches, and it always works fine. Also, while autoupdate is on by default for the Signal client (and it includes a time bomb expiration to attempt to "force" you to upgrade regularly (removing this is one of my patches)), you are free to turn it off and remove their ability to modify the code on your own system.
Molly has been running just fine as a project for quite a few years at this point. Signal doesn't block them. I think it's fair to say they are fairly strongly opposed to them (for somewhat defensible reasons), but no, they've been fairly nice in allowing other clients.
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.
You could also audit the JavaScript / Wasm that's running in your browser. In fact, a security-focused e2e application might want to purposely keep all client-side code un-minified and highly readable for this very purpose, but decompilers and LLMs could provide reasonable auditability regardless
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.
This is precisely why I have autoupdates disabled for my Signal apps. They're on by default, which basically gives Signal-the-org remote code execution on my machine (same as Chrome's built in transparent autoupdate gives Google RCE on your machine).
I guess you could make a point for using messengers based on open protocols (like Matrix) that have plenty of different client implementations. It doesn't protect you from targeted attacks (it might if you can somehow hide from the outside world which client you're using, or if you write and maintain the client yourself) - but it makes it less likely to be affected if your favourite agency managed to backdoor some random client implementation.
Signal seems to be quietly warning people away from the service by refusing to update their privacy policy the very first line of which is a clear lie.
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.
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?
> 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!”
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.
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.
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.
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!"
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.
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.
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.
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.
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 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.
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].
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."
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.
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.
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.
Hm not necessarily. You "just" need to get code onto the system that is somehow being loaded into the gpg process or has the ability to load code into a gpg process.
Of course, still orders of magnitude harder than just modifying the js bundle, but not a counter-example.
Snake oil is just a fundamentally wrong label for the issues OP is seeing, even though those issues are of course real and relevant.
> An evil Debian maintainer would have to make a change that was well enough disguised as something else to evade scrutiny.
The xz utils hack got slurped up into sid before it was discovered by a researcher's performance regression in ssh. IIRC the hacked test file didn't even need to be added to the upstream source tree because Debian was blithely downloading release tarballs from Github. No evil Debian maintainer needed.
It's funny that when speculating about Debian's security you forget an actual state-level attack that got code into sid, but when speculating about Signal's insecurity in another thread you're quite happy to imagine potential state-level attacks.
> 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.
"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
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
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.
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.
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.
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.
It said the message was removed for violating some rule or something. The message was a link to a website meta does not approve of but it was removed like a day later.
Wow, that is honestly a bit freaky - first I’ve heard of anything like that. I will assume it was a client side action, but still horribly invasive if that’s how it went. I’ll try to find more about this possibility.
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.
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.
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.
> 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 obvious counterexample is NOBUS[0] vulnerabilities, and intentional backdoors like the Clipper Chip[1] or Dual_EC_DRBG[2]: if you genuinely believe you are the only one who could possibly exploit it, there's no reason to avoid using it.
A more modern example is probably the NSA aggressively pushing[3] for replacing classical encryption with post-quantum encryption, rather than taking the more conservative and probably-more-secure approach of layering the two - while at the same time mandating the use of two layers of those same algorithms for their own use[4]!
[0]: https://en.wikipedia.org/wiki/NOBUS
[1]: https://en.wikipedia.org/wiki/Clipper_chip
[2]: https://en.wikipedia.org/wiki/Dual_EC_DRBG
[3]: https://blog.cr.yp.to/20251004-weakened.html
[4]: https://defense-solutions.curtisswright.com/capabilities/tec...
> The obvious counterexample is NOBUS[0] vulnerabilities, and intentional backdoors like the Clipper Chip[1] or Dual_EC_DRBG[2]: if you genuinely believe you are the only one who could possibly exploit it, there's no reason to avoid using it.
The problem with these examples is that they weren't used in national security systems, which are the systems for which NSA has a legislated defensive responsibility.
Clipper was designed for use by the public; it was not intended to ever be used to protect classified (or even sensitive unclassified) information at all.
Likewise with Dual_EC_DRBG. The CSfC component requirements drew from the Common Criteria Protection Profiles, where Dual_EC_DRBG was never an option.
The NSA isn't aggressively pushing for PQC; the industry is. Note that the PQC standard we have was the product of a competition won by European academic cryptographers.
That is not what the comment to which you replied said.
There is a consensus about pushing PQC and about the PQC standard.
The dispute is about something else, about whether the current Diffie-Hellman based key establishment algorithms should be immediately and completely replaced by PQC (which is what NSA pushes), or to be more prudent and use for some time both methods (so that the key exchange cannot be broken when any of the 2 algorithms is broken), to afford more time for gaining confidence in the standardized PQC algorithms, until eventually one might decide that it is reasonable to omit the current algorithms.
What NSA wants reduces somewhat the costs, but not by much, because PQC is much more expensive, so most of the cost is determined by it and not by the classic algorithms, even when they are used together, and also because keeping the current algorithms does not require any development work, as there are mature implementations in SW or in HW for all applications. The opponents argue that this small cost reduction is not worthwhile, because it eliminates the serious risks that flaws may be discovered later in the current PQC standards.
Moreover what NSA wants would complicate the protocols, because many would not accept the risks of the NSA variant, so it would remain optional to omit the classic algorithms, increasing the number of choices in the protocol, which is always undesirable in security protocols.
No, I'm very clear on what the question was asking, and it is not in fact "NSA" driving this process.
This is 100% Daniel Bernstein drama. Bernstein is upset that the NIST contest selected MLKEM (Kyber). He's been running a yearslong crusade to impeach the standard, up to and including opposition to lattice cryptography writ large, despite himself signing on to a lattice entrant (SNTRUP) to the PQC competition.
Over the last several months, the focal point of this crusade has been the IETF TLS Working Group, where Bernstein has been canvassing opposition to an RFC that will establish code points and documentation for pure, non-hybrid MLKEM TLS. Few systems in the near future are likely to use pure MLKEM TLS, but there are conceivable systems that we can foresee needing the option: for instance, embedded systems like smart meters that do ECC today, and could do MLKEM if it was urgently needed because of a CRQC, but couldn't practically do both.
The arguments being made on TLSWG are in spectacularly bad faith. People have varying levels of confidence in pure MLKEM (the closer your job title is to "cryptography engineer", the more likely it is you think hybrids are silly). But outside of the federal government itself, nobody in the entire world is being forced to use pure MLKEM; the entire controversy is about documenting what TLS would look like if you needed pure MLKEM.
The "NSA" stuff is just more innuendo.
Apart from bytes on the wire, MLKEM is not in fact "much more expensive" than 25519. Also, you have the maturity argument wrong; it's not a concern that risks/flaws will be discovered "in the standards".
Your argument would be far more charitable if NIST had not already been caught pushing a broken standard at the behest of the NSA before. DJB might be combative and somewhat caustic, but the one thing he's never been, given enough time in the retrospect to show it, is wrong.
The logic you're using here would be just as valid in a campaign against SHA2. More valid, in fact, because unlike MLKEM, which was designed by European academic cryptographers, the NSA actually designed SHA2.
>Dual_EC_DRBG
There is no hard evidence that it was backdoored.
> As part of its efforts to foil Web encryption, the National Security Agency inserted a backdoor into a 2006 security standard adopted by the National Institute of Standards and Technology, the federal agency charged with recommending cybersecurity standards. Credit Patrick Semansky/Associated Press
https://archive.nytimes.com/bits.blogs.nytimes.com/2013/09/1...
Even if you believe they're lying, or think that it's impossible to know because it may be a kleptographic backdoor... the latter at least is understood to be a unique property that most other algorithms do not share, so I think for that reason alone it's enough to assume it is backdoored, insofar as that we should tell people to stay away from it regardless.
There is no source in the article to support that claim, it links to another article where it merely says that people suspected it of being backdoored, but those people had no proof either. There are objective reasons why it's not a good idea to use compared to better algorithms, but I wish the reasoning was not solely based off of a conspiracy theory or hate for the NSA.
> 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.
> This is not true. I can build Signal from source from GitHub
Sure, but can you find an NSA-designed backdoor in the source code?
> you can get it once and disable autoupdates
Try doing that with Signal, and you'll be unable to connect to the main network in just a few days because you get out of sync. Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code?
What you describe may be possible for an intelligence agency, but completely out of reach for an individual.
> unless Apple is colluding with them
Given the most likely adversary is the US intelligence with a warrant, it's absolutely not far fetched to assume that in your threat model.
> you can at least be reasonably confident that it's not specifically backdooring only you
That's not really reassuring…
>> This is not true. I can build Signal from source from GitHub
> Sure, but can you find an NSA-designed backdoor in the source code?
You're moving the goalpost. They were responding to the claim suggesting it's impossible to get non-Signal provided signal.
>> you can get it once and disable autoupdates
> Try doing that with Signal, and you'll be unable to connect to the main network in just a few days because you get out of sync.
That's demonstrably false. On one of my idle/backup phones I'm using Signal 8.8.2, released in April 2026, almost 3 full months ago. It can not only connect to the network but everything works, with every contact.
You might think of the official Signal client expiration, but that's client side (meaning that you can compile and use the version that doesn't have it) and..... 90 days, not "a few".
I don't have a concrete number for the server side of enforcement though (minimumVersions seems to be populated at start time, with the defaults not committed to the repo). It's not entirely unreasonable to assume that the lowest official supported version is the one that introduced the concept of usernames, and the only meaningful capability test is SPQR.
> Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code?
I think disabling auto update was shown as a possible strategy against a silent, targeted auto update. Not a way to remain protected against the general CVEs.
Non sequitur.
> You're moving the goalpost. They were responding to the claim suggesting it's impossible to get non-Signal provided signal.
That was never my claim. The claim is that you cannot protect youself from Signal being malicious if Signal is the maker of the software. Compiling the software yourself doesn't help against the kind of adversary in the threat model.
> That's demonstrably false. On one of my idle/backup phones I'm using Signal 8.8.2, released in April 2026, almost 3 full months ago. It can not only connect to the network but everything works, with every contact.
Lucky you, you only need to fully audit the codebase every 3 months.
I'm using the Signal apk directly so I'm painfully aware of the frequency of the breakages.
> I think disabling auto update was shown as a possible strategy against a silent, targeted auto update. Not a way to remain protected against the general CVEs.
I don't think you understand my point. I'm not talking about the CVE being exploited against you. The CVE will just push you to download the compromised update, breaking your “security through lack of update” policy.
Now the argument is shifting. It started out as "a cryptosystem can't be secured from the entity in control of its supply", and now it's "a cryptosystem can't be secured even given its source code because the NSA".
It's not shifting. It doesn't need to be the NSA, intelligence agencies are just, by far, the most likely attackers against Signal.
It's not the identity of the agency that makes the argument so slippery!
Do you seriously think that the average Joe is able to find a backdoor, planted by anyone, in a piece of software they aren't familiar with?
Because that what quite literally the claim I was arguing with in the first place.
I don't really agree with much of anything you've said in this thread, but the only thing I'm pointing out here is that your argument has shifted and is chugging heartily towards non-falsifiability.
No the argument hasn't shifted. The core point is that any time you use a piece of software, you have to have some level of trust towards the entity that gave you the said piece of software.
The way I responded to one particular example “what if I download Signal and compile it myself” is just that a particular example, not a shift in argument.
If you think there's no trust assumption in the distribution of software, feel free to provide actual arguments to refute that argument of mine, because so far your comments have been disappointingly lacking in substance.
If you get an open source app from the App Store, is there any assurance it actually reflects the code in the repo? I’d think the signing step happening in isolation opens the door to tomfoolery.
> 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.
The article is nothing but a rant.
Craigslist used to have a Rants & Raves section for exactly these kind of things. I think they still have, but in old times it used to be so happening! Maybe hacker news needs to have one.
Your comment is merely a comment and not an argument
But claiming that your system is end to end encrypted means that you are claiming protection from you and your system. This is mainly a truth in advertising issue.
> means that you are claiming protection from you and your system.
Not necessarily. I push for e2ee everywhere I can for a completely different reason: when (not “if”, “when“) we get breached, we cannot leak sensitive data we don't have.
The problem is that your system can be changed at any time such that you can have the information.
Only if you manage to deploy malicious code and have it stay there undetected. But in practice this is much harder than having access to a DB or a backup for a few minutes (that's all it takes to leak data).
(Just as an example, at my current employer, out of 8 people in the company, there are 8 people who have credentials that permit at least some db access in one way or the other (anyone that has at least one of this job: customer support, account managers, data scientists, devs). There are only 3 people who can push changes to production, and you need 2 out of 3 to do so, and all of three get paged when a release happen. Of course it's not infallible, but the probability of the app being corrupted is orders of magnitude lower than the DB being breached, by the mere scale of the number of people who have access to these things. And again, you only need transient access to the data to leak it, when you need persistent access to do damage by corrupting the code. Most companies I worked for had an even worse ratio between people having access to some sensitive data and people having the ability to push corrupted code in production).
> 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.
> if there is some kind of vetting process to verify that the version I'm currently running does not contain a backdoor
This would be extremely difficult, I would say impossible from a practical standpoint.
> This would be extremely difficult, I would say impossible from a practical standpoint.
It's not only practical and possible, it's so common it even has a name in software engineering circles: change control. It boils down to this: you delay installing the software until it's been reviewed, tested and deployed by others. Or as Linus would put it, until the many eyeballs have had their say.
As for "the person in control of the platform": the solution is to remove some of that control. You make new versions of the software available for anonymous download, so the provider has no idea who is upgrading. All open source distributions provide their software in that way. No proprietary platforms I'm aware of do, because they want a "billing relationship" with the customer. Once downloads are anonymous, the owner of the software can't target individuals with a tailored Trojan Horse binary. Everyone gets the same binary, and so there are lots of eyeballs looking at it.
The final piece of the puzzle is reproducible builds, which ensures the many eyeballs can see the code use to build the binary.
All this has been around for a while now, so it's largely a solved problem in open source distributions. The problem with web-based cryptography is it isn't managed like an open source distribution. Downloads aren't anonymous, the source isn't available or signed, and it changes so fast change control isn't possible. So yeah, as things stand it's snake oil. But it doesn't have to be - it's just the way things are now.
> 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.
It will be enough until the server is pwnd and the data is leaked to the world.
Data breaches happen literally every day.
But that's OP's point. If the server is pwned, the hackers can simply change the front-end of the app and have it send the confidential data to wherever after it was decrypted on the client.
See what I wrote above:
> 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…
Data breach occur every day, rootkits being covertly deployed in production apps for a substantial period are much rarer. E2ee only protects against the former, like a safety belt only prevent you from frontal shocks. Nobody would say they are snake oil because of that.
I would say that they are snake oil because of that. Data breaches occur more often than rootkits because most developers see that this path adding easily-removable encryption does nothing in the long run.
> Data breaches occur more often than rootkits because most developers see that this path adding easily-removable encryption does nothing in the long run.
That logic makes no sense. A rootkit is much more valuable than a data breach (because it gives you access to a compromised device), the reason why you don't see more of them is because it's much harder to pull off, not because people don't use e2ee…
(For instance, if you can replace an e-commerce website's code with your own, you get access to the user's payment information, which you can't usually get from their DB since it's generally handled by the payment processor, or to the user's plaintext password…)
Anyone using reverse proxies, CDNs or anti-DDoS services already voluntarily give full MITM privileges of their unencrypted data to companies like CloudFlare, Amazon, Akamai, Fastly, etc., which is most of the top sites on the internet and a large percentage of the overall internet traffic.
>...pretty much any E2E system is falling under this definition.
The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example. There are other related issues but the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging which makes it so bad as to be worthless.
> The definition is quite clear. It does not apply when the implementation is not distributed by the same entity that creates it for example.
How can you be sure that the entity distributing the software didn't backdoor it?
> the message here is that web based cryptography has a particular weakness when it comes to things like end to end encrypted messaging
There's literally no substance about that claim in TFA.
It's not useless, I don't think.
If the software is open source and you only install new versions after their source code has been audited, you should be ok.
a website can serve you a keylogger client and no one will ever know most likely, harder to do with binaries/sources
> 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.
But with repro builds and system transparency, hiding backdoors is impractical.
Not really, time and time again people have abused their position/influence to build backdoors almost into everything for good or bad reasons. The whole idea of third party audits was to ensure that there are checks and balances. Then again the auditors are lowest paid to get stuff done and they take word of the company for most part.
On other hand its quite natural, security is not really getting you direct revenue so business is least motivated in investing it or say continuously investing in it. The ones that do are doing partial lip service for most part.
Really? "Time and time again", "almost everything"? Make a list!
> 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.
I think the whole US vs. non-US thing is total crap and there's nothing you can reasonably do with it in any direction, but I always think it's important to point out that US signals intelligence can lawfully compromise foreign communications; that's literally their chartered purpose.
> there's nothing you can reasonably do with it in any direction
I wholeheartedly agree. That's why bringing nation state threats into these kinds of discussions is so pointless. If you want security from governments, the amount of security work you have to do is so far beyond what any reasonable person is willing to endure that it makes no sense to talk about on hackernews. That stuff is for real professional discussions at real professional congresses.
> I think the whole US vs. non-US thing is total crap
It's not. US companies can be subpoenaed in the US.
> I always think it's important to point out that US signals intelligence can lawfully compromise foreign communications; that's literally their chartered purpose.
Of course they can. But it's significantly easier to get a warrant to target a company under US jurisdiction.
Foreign companies don't have to be subpoenaed. NSA can simply break in and take whatever they want, lawfully. In light of that, the warrant point you're making doesn't make sense: they don't need a warrant to go after foreign assets.
> NSA can simply break in
You can't be serious …
The NSA can break in the same way the Mossad can assassinate you anywhere in the world. That doesn't mean it's a it's going to happen anytime soon unless you're an exceptionally high priority target. Authorities getting legal access to your personal informations from US companies on the other hand is routine practice. Equating the two is a crazy take.
By the way, you read the argument completely backwards in the first place: the original argument was that even if using an American company means the US law enforcement have full access to your data if they want to, your data is still pretty safe from anyone else there (unless, of course, if you are a high priority target again).
See the original sentence:
> 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.
Saying someone's argument is “total crap” without even having taken enough time to properly read the sentence you're criticizing is kinda lame IMHO.
I am 100% dead serious and I kind of don't understand the rebuttal you're trying to write here.
“Cryptography is useless because governments agencies will kidnap you and hit you with a wrench” isn't the hill I expected you to die on TBH.
> I kind of don't understand the rebuttal you're trying to write here.
Fill free to make the effort to read it (again).
I have no idea who you're responding to because nobody on this thread has made that argument.
Maybe if you made your point straight instead of making laconic remarks this discussion would be more constructive…
All I got from your few words is that apparently you consider the NSA breaking into a random foreign app a reasonable threat model to design around. Abduction from the CIA being only marginally more unlikely, why bother with anything?
Or maybe I misunderstood your point but then again when you can't bother writing down two consecutive sentences how am I supposed to read your mind?
Your access records are only as good as your ability to prevent someone from making unauthorized access.
> 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/
> 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
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.
Signal does not aggressively block non-official clients. I constantly use a modified version of Signal Desktop containing a small set of my own patches, and it always works fine. Also, while autoupdate is on by default for the Signal client (and it includes a time bomb expiration to attempt to "force" you to upgrade regularly (removing this is one of my patches)), you are free to turn it off and remove their ability to modify the code on your own system.
This doesn’t work on iOS, where you can’t selectively disable automatic updates for a single app.
I have all iOS automatic app updates disabled.
Molly has been running just fine as a project for quite a few years at this point. Signal doesn't block them. I think it's fair to say they are fairly strongly opposed to them (for somewhat defensible reasons), but no, they've been fairly nice in allowing other clients.
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.
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
You could also audit the JavaScript / Wasm that's running in your browser. In fact, a security-focused e2e application might want to purposely keep all client-side code un-minified and highly readable for this very purpose, but decompilers and LLMs could provide reasonable auditability regardless
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.
This is precisely why I have autoupdates disabled for my Signal apps. They're on by default, which basically gives Signal-the-org remote code execution on my machine (same as Chrome's built in transparent autoupdate gives Google RCE on your machine).
Perhaps Molly[1] could serve as an alternative client for you?
[1] https://molly.im/
The argument is that E2E encryption implemented by Non-signal may protect you against Signal but won't protect you against Non-signal
I guess you could make a point for using messengers based on open protocols (like Matrix) that have plenty of different client implementations. It doesn't protect you from targeted attacks (it might if you can somehow hide from the outside world which client you're using, or if you write and maintain the client yourself) - but it makes it less likely to be affected if your favourite agency managed to backdoor some random client implementation.
Signal doesn't have to backdoor the client (although they could) to be a risk. They upload and permanently store sensitive data in the cloud protected by nothing more than a pin and SGX (https://web.archive.org/web/20250117232443/https://www.vice....) which has already been shown to be vulnerable to side channel attacks (https://web.archive.org/web/20230519120156/https://community...)
Signal seems to be quietly warning people away from the service by refusing to update their privacy policy the very first line of which is a clear lie.
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.
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?
> 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!”
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.
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.
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.
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!"
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.
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.
Gajim recently got a modern PGP implementation: https://gajim.org/posts/2026-06-18-gajim-2.4.7-released/
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.
Anything you see rendered onto a screen is no longer secure though, or is it a hyperbole to phrase it this way?
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/
PGP remains the only pretty good privacy
(Said tongue-in-cheek, I don’t know if there’s other comparable systems out there)
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.
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 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.
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
The word "if" is doing a whole lot of work in that first paragraph. Holding the entire world on its shoulders, so to speak.
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."
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
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.
I’d rather make up my own mind, read the docs/code. All I read was unsubstantiated claims, with zero real world evidence.
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.
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.
Hm not necessarily. You "just" need to get code onto the system that is somehow being loaded into the gpg process or has the ability to load code into a gpg process.
Of course, still orders of magnitude harder than just modifying the js bundle, but not a counter-example.
Snake oil is just a fundamentally wrong label for the issues OP is seeing, even though those issues are of course real and relevant.
> An evil Debian maintainer would have to make a change that was well enough disguised as something else to evade scrutiny.
The xz utils hack got slurped up into sid before it was discovered by a researcher's performance regression in ssh. IIRC the hacked test file didn't even need to be added to the upstream source tree because Debian was blithely downloading release tarballs from Github. No evil Debian maintainer needed.
It's funny that when speculating about Debian's security you forget an actual state-level attack that got code into sid, but when speculating about Signal's insecurity in another thread you're quite happy to imagine potential state-level attacks.
> 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.
"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
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
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.
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.
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.
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.
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.
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.
It said the message was removed for violating some rule or something. The message was a link to a website meta does not approve of but it was removed like a day later.
Wow, that is honestly a bit freaky - first I’ve heard of anything like that. I will assume it was a client side action, but still horribly invasive if that’s how it went. I’ll try to find more about this possibility.
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.
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.
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.