When Signal was designed, our threat model was protecting the communications of civil society, journalists, just regular citizens ...
The threat model of military operations & sharing your hate of Europeans was not what Signal was designed for. Ephemeral messages and cryptographic deniability are not fit for communications that require accountability.
But I appreciate their effort to make government more efficient by adding journalists to the chat instead of requiring to go through FOIA.
@kkarhan@fj I still think @signalapp has fundamental flaws like demanding #PII (#PhoneNumbers can't be obtained anonymously around the globe and are trivial to track down to devices and thus users), being subject to #CloudAct as an unnecessary & 100% avoidable risk as well as #Shitcoin-#Scam shilling (#MobileCoin) and it's #proprietary, #SingleVendor & #SingleProvider nature that makes it inferior to real #E2EE with #SelfCustody like #PGP/MIME & #XMPP+#OMEMO!
@kkarhan@infosec.space @fj@mastodon.social some of these are issues, but to be real the suggestion to use PGP and MIME instead of signal is laughable, not only is it nonviable as a replacement, but also is just bad to deal with and use in comparison
firstly, try to achieve similar security as signal with only PGP (or OMEMO), secondly after pulling off that technically impossible feat, try to use it without causing 100x more avoidable security issues than signal does right now
after doing that I think you can appreciate that although signal has many flaws (phone numbers being my biggest issue with them) they are actually still doing state-of-the-art security/privacy/cryptography services and can't easily be replaced by random other tools like this lol
@forthy42@mastodon.net2o.de@froge @kkarhan @fj You confuse crypto security with operational security, a common mistake. While Signal has a ridiculously high level of cryptographic security (much of which it needs, because it does store-and-forward of messages it never should see at all), it is shitty for the reasons above.
Because I'm not happy with either way, I'm working on my net2o protocol, which is peer2peer, and state-of-the-art with how it deals with encryption. It doesn't jump through the hoops to try making store-and-forward on hostile servers feasible, because that's a bug. You never should design your protocol to include this, not even as option.
The reason why people wanted store-and-forward in the not so recent past was that they were offline most of the time, batch-fetched their e-mail through a per-minute landline, and then answered their e-mails and went online again.
This is how I used the Internet 30 years ago. Today, people have their always-online devices, and while there are still interruptions, you don't need that central instance. Especially for group chats, reliable instant transfer (with the exception of those participants which are offline at the moment) is always possible.
@forthy42@mastodon.net2o.de @kkarhan@infosec.space @fj@mastodon.social it's not that I actually confuse these things, it's that the alternatives presented have equally bad operational security problems too, just in new and interesting ways, so it's hardly worth mentioning as a point of comparison to me in general
@kkarhan@infosec.space@froge @forthy42 @fj to me, @signalapp being centralized and not even doing tue absolute minimum of supporting @torproject / #Tor and having at least an #OnionService as #API-Endpoint makes them #UsefulIdiots.
It's several things like that that rubvme the wrong way and that make it uncomfortable.