this post was submitted on 08 Jul 2025
17 points (94.7% liked)

Privacy

3151 readers
80 users here now

Welcome! This is a community for all those who are interested in protecting their privacy.

Rules

PS: Don't be a smartass and try to game the system, we'll know if you're breaking the rules when we see it!

  1. Be civil and no prejudice
  2. Don't promote big-tech software
  3. No apathy and defeatism for privacy (i.e. "They already have my data, why bother?")
  4. No reposting of news that was already posted
  5. No crypto, blockchain, NFTs
  6. No Xitter links (if absolutely necessary, use xcancel)

Related communities:

Some of these are only vaguely related, but great communities.

founded 8 months ago
MODERATORS
 

cross-posted from: https://beehaw.org/post/20989376

Where Soatok goes over why checklists are meaningless when trying to figure out if something is private or just for comparisons in general.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 day ago* (last edited 1 day ago) (1 children)

So Soatok advocates for signal as pretty much the "gold standard" of e2ee apps, but it has a pretty big problem.

  1. Having signal be the distributor of the app, sorta breaks the threat model where you trust the app to encrypt data and hide it from the sever

  2. Signal is hostile to third parties packaging and distributing signal

The combination of these problems is suppose to be fixed with reproducible builds, where you can ensure that any user who builds the code will get the same binaries and outputs. Soatok mentions reproducible builds and the problems they solve on another blogpost

But signal's reproducible builds are broken.

The problem is that the answer to Soatok's second question "Can you accidentally/maliciously turn it off" is YES if you are using packages directly from the developer without signing to verify their identity and reproducible builds. They could put a backdoor in there, and you would have no way to tell. It's not fair to pretend that signal doesn't have that flaw, while dissing OMEMO

To understand why this is true, you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can)

(Although there is an argument to be made that having e2ee always on by default would minimize user error in improperly configuring it).

Now, I still think signal is a great software choice for many things. It's basically the best choice as a replacement to text messaging, universally.

But some people need something more secure than that, if you're seriously concerned about certain entities compromising the signal project, than you must have the ability to install clients from third party distributors and developers, even though they can have security issues, which Soatok notes in a post about Matrix (see the heading "Wasn’t libolm deprecated in May 2022?").

I thought the whole point of choosing Matrix over something like Signal is to be federated, and run your own third-party clients?

Yes Soatok. Depending on your threat model you may need to be able to choose from more than client implementation, even if all of them are trash except for 3. (Although I wouldn't recommend Matrix as a private messeger due to metadata like users/groups being public, but it's shaping up to be a great discord clone with PM feature. Is the crytography as secure as signals? No. But it checks the box of "Discord but doesn't sell my data" (yet ofc, Matrix is VC funded).).

Anyway, it's frustrating how he seems to have become more of a hardliner about this. It used to be that these were the bar to clear to become a signal competitor. Now these standards are the bar to clear to be recommended entirely (see the main section about "How do experts recommend secure messaging apps"), even though Signal itself doesn't clear them.

[–] [email protected] 1 points 1 day ago

Very good and well thought out reply! Thanks so much!