How checklists lie with facts, and are bad for figuring out privacy of apps etc.
-
Don't forget to breathe, kiddo.
LMAO, I'm probably older than you.
-
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.
wrote last edited by [email protected]So Soatok advocates for signal as pretty much the "gold standard" of e2ee apps, but it has a pretty big problem.
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.
-
I'm surprised this article doesn't mention privacytests.org by name, but it reaches a conclusion that may as well:
If you see a dumb checklist trying to convince you to use a specific app or product, assume some marketing asshole is trying to manipulate you. Don’t trust it.
Thankfully there's a good recommendation in the very next paragraph for all things (messaging apps, browsers, etc):
If you’re confronted with a checklist in the wild and want an alternative to share instead, Privacy Guides doesn’t attempt to create comparison tables for all of their recommendations within a given category of tool.
Also: shots fired at XMPP throughout, as the poor protocol limps along trying desperately to catch up to the encryption baseline that was set over a decade ago by the first versions of Signal.
Ultimately, both protocols are good. They’re certainly way better choices than OpenPGP, OMEMO, Olm, MTProto, etc.
Why OMEMO is "bad" is indirectly answered earlier:
The most important questions that actually matter to security:
- Is end-to-end encryption turned on by default?
- Can you (accidentally, maliciously) turn it off?
If the answers aren’t “yes” and “no”, respectively, your app belongs in the garbage. Do not pass Go.
Similar discussions have skewered the federated Delta Chat for having an even worse version of this issue.
wrote last edited by [email protected]If the answers aren’t “yes” and “no”, respectively, your app belongs in the garbage. Do not pass Go.
Please see my comment about this issue. Signal does not pass this test due to not having (working) reproducible builds.
-
So Soatok advocates for signal as pretty much the "gold standard" of e2ee apps, but it has a pretty big problem.
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.
Very good and well thought out reply! Thanks so much!
