[hypfer]

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.

[grumbel]

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

[upofadown]

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.

[jancsika]

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

[hypfer]

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.