I think this is a dangerous view. As we've seen with the libxz attack, skilled developers are very capable of hiding backdoors/vulnerabilities in security software, even when it is open source. So it's very important whether the developers building the software are trustworthy.
Authoritarian jurisdictions with a modus operandi of compelling their businesses and citizens by force are thus much riskier than Western democracies, even flawed ones. I at least expect it's a lot harder to say no to demands to break your promises that come with credible threats of torturing your family.
I'll also say that it's quite hard to make a messaging app without the servers that run the service having a great deal of power in the protocol. Many types of flaws or bugs in a client or protocol go from "theoretical problem" to "major issue" in the presence of a malicious server.
So if end-to-end security is a goal, you must pay attention to not only the protocol/algorithms and client codebase. The software publisher's risks are important (E.g., Zoom has a lot of risk from a China-centric development team). As are those of the hosting provider (if different from the publisher).
And also less obvious risks, like the mobile OS, mobile keyboard app, or AI assistant that are processing your communications even though they're sent between clients with E2EE.
Reflections on Trusting Trust is still a great read for folks curious about these issues.
I think you misinterpreted the most important nuance in this post. The rest of your comment is about jurisdiction in the context of who develops the client software.
The blog post is talking about jurisdiction in the context of where ciphertext is stored, and only calls that mostly irrelevant. The outro even acknowledges that when jurisdiction does matter at all, it's about the security of the software running on the end machine. (The topic at hand is end to end encryption, after all!)
So, no, this isn't a dangerous view. I don't think we even disagree at all.
I think we agree here that the US/Europe jurisdiction difference is relatively minor compared to questions about the software itself.
What's dangerous is the framing; many E2EE messengers give the server a LOT more power than "just stores the ciphertext". https://news.ycombinator.com/item?id=33259937 is discussion of a relevant example that's gotten a lot of attention, with Matrix giving the server control over "who is in a group", which can be the whole ball game for end-to-end security.
And that's not even getting into the power of side channel information available to the server. Timing and other side channel attacks can be powerful.
Standard security practice is defense in depth, because real-world systems always have bugs and flaws, and cryptographic algorithms have a history of being eventually broken. Control over the server and access to ciphertext are definitely capabilities that, in practice, can often be combined with vulnerabilities to break secure systems.
If the people who develop the software are different from those who host the server, that's almost certainly software you can self-host. Why not mention self-hosting in the article?
If you're shopping for a third party to host a self-hostable E2EE messenger for you. The framing of the server as just "storing ciphertext" would suggest trustyworthyness of that hosting provider isn't relevant. I can't agree with that claim.
> The framing of the server as just "storing ciphertext" would suggest trustyworthyness of that hosting provider isn't relevant.
In point of argument, it should not be relevant - beyond metadata exposure or failure to provide service. Metadata exposure is mentioned in the post, and is a rather important aspect to consider. Having service turned off when you need it also might be an important consideration depending on the threat model. If I were cabinet members planning military operations, it is quite likely that I would care about both of those.
Beyond that, the 2025 table stakes for a 'secure' messaging service are: "a totally compromised server should not be able to read messages or inject messages that will be acceptable to legitimate clients. It should also not be able to undetectably remove, reorder, or replay messages." [1]
> What's dangerous is the framing; many E2EE messengers give the server a LOT more power than "just stores the ciphertext". https://news.ycombinator.com/item?id=33259937 is discussion of a relevant example that's gotten a lot of attention, with Matrix giving the server control over "who is in a group", which can be the whole ball game for end-to-end security.
I'm a vocal critic of Matrix, and I would not consider it a private messenger like Signal.
When Matrix pretends to be a Signal alternative, the fact that the server had control over group membership makes their claim patently stupid.
> And that's not even getting into the power of side channel information available to the server. Timing and other side channel attacks can be powerful.
A lot of my blog discusses timing attacks and side-channel cryptanalysis. :)
> If the people who develop the software are different from those who host the server, that's almost certainly software you can self-host. Why not mention self-hosting in the article?
Because all of the self-hosting solutions (i.e., Matrix) have, historically, had worse cryptography than the siloed solutions (i.e., Signal, WhatsApp) to the point that I wholesale discount Matrix, OMEMO, etc. as secure messaging solutions.
> If you're shopping for a third party to host a self-hostable E2EE messenger for you. The framing of the server as just "storing ciphertext" would suggest trustyworthyness of that hosting provider isn't relevant. I can't agree with that claim.
It's more of an architecture question.
Is a self-hosted Matrix server that accepts and stores plaintext, but is hosted in Switzerland, a better way to chat privately than Signal? What if your threat model is "the US government"? My answer is a resounding, "No. You should fucking use Signal."
Authoritarian jurisdictions with a modus operandi of compelling their businesses and citizens by force are thus much riskier than Western democracies, even flawed ones. I at least expect it's a lot harder to say no to demands to break your promises that come with credible threats of torturing your family.
I'll also say that it's quite hard to make a messaging app without the servers that run the service having a great deal of power in the protocol. Many types of flaws or bugs in a client or protocol go from "theoretical problem" to "major issue" in the presence of a malicious server.
So if end-to-end security is a goal, you must pay attention to not only the protocol/algorithms and client codebase. The software publisher's risks are important (E.g., Zoom has a lot of risk from a China-centric development team). As are those of the hosting provider (if different from the publisher).
And also less obvious risks, like the mobile OS, mobile keyboard app, or AI assistant that are processing your communications even though they're sent between clients with E2EE.
Reflections on Trusting Trust is still a great read for folks curious about these issues.