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.

▲

TuringTux 4 days ago | parent | next [-]

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.

	▲	autoexec 3 days ago \| parent \| next [-]
		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.
	▲	zzril 3 days ago \| parent \| prev \| next [-]
		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.
	▲	sneak 3 days ago \| parent \| prev \| next [-]
		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).
	▲	unbrice 3 days ago \| parent \| prev \| next [-]
		The argument is that E2E encryption implemented by Non-signal may protect you against Signal but won't protect you against Non-signal
	▲	subscribed 3 days ago \| parent \| prev [-]
		Perhaps Molly[1] could serve as an alternative client for you? [1] https://molly.im/

▲

memoriyato3 4 days ago | parent | prev [-]

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

	▲	bloppe 3 days ago \| parent [-]
		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