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...
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 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.
There is no hard evidence that it was backdoored.
You don't need E2E for that, using https/TLS for transport and servers hosted in the US would be enough.
Data breaches happen literally every day.
> 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.
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.
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.
But with repro builds and system transparency, hiding backdoors is impractical.
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.
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.
If the software is open source and you only install new versions after their source code has been audited, you should be ok.
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.
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…
Because that what quite literally the claim I was arguing with in the first place.
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.
> 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.
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.
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.
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.
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.
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 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.