3 ms·
Regardless of the merits of Signal, much of the criticism voiced in that article is nonetheless valid. Signal and other chat platforms employing the protocol ar
by Freak_NL 10y ago
Regardless of the merits of Signal, much of the criticism voiced in that article is nonetheless valid. Signal and other chat platforms employing the protocol are run as data-silos by design, using strongly identifying codes (phone numbers) as the required identifier — i.e., it is nearly impossible to create a throw-away account, because getting an anonymous phone number is no longer a practical possibility in a lot of (Western!) countries.
Whether or not such metadata is available to adversaries (either through OWS or gathered elsewhere) depends on who your adversaries are and whether or not a corporate entity can be trusted to be completely transparent about what kind of data they retain.
As for [0]; even if no relevant metadata is collected today by whoever owns the servers, nothing stops the party providing the service from doing so tomorrow.
- quonn 10y agoWe should learn from the failures of the past (PGP) and not forget that in practise all electronic communication (by phone, email, etc.) has been completely unprotected for pretty much everyone. With large services like Gmail and Facebook mining the data, the situation is arguably even worse. So the less than perfect steps we have been seeing recently (widespread transport encryption in email, end-to-end encryption in WhatsApp and Signal) are a huge improvement.
- bruo 10y agoThe critics are valid, the solutions are not (for activists, as it's it focus) Conversations.im was (or is, haven't checked in a month) logs encrypted chats on cleartext by default, and history shows why that is a bad idea [0] Until today I haven't seen a single XMPP that protects metadata, the roster is always on cleartext, to support omemo you are storing yet more info always, etc. If the answer to Signal issues is XMPP, there is a lot of work to do before to even suggest going this path. [0]: https://trac.adium.im/ticket/15722 https://trac.adium.im/ticket/15722
- jfindley 10y ago> As for [0]; even if no relevant metadata is collected today by whoever owns the servers, nothing stops the party providing the service from doing so tomorrow. This is a point I see bought up a LOT. I don't believe it to be useful however - proceeding down this rabbithole rapidly leads us to a place of advanced paranoia where we can't get anything useful done. Once you start assuming actual malice on the part of the software developer, even open-source code with the ability to run your own service doesn't protect you - there's multiple ways backdoors can be inserted in sufficiently subtle ways it's extremely unlikely they will be spotted before it's far too late for you. > using strongly identifying codes (phone numbers) as the required identifier — i.e., it is nearly impossible to create a throw-away accoun Identifiers are only valuable if there is something to link that identifier to. Account creation time and last active time are very unlikely to be valuable to your adversary (for any definition of "your adversary" you had a chance at defending against in the first place). In other words, as long as the only data they have is your phone number, then that's not helpful. All that is is a record of a) this phone number exists (which is not secret) and b) this phone number uses signal (which isn't a secret either to any even mildly motiviated attacker).
- zeveb 10y ago> proceeding down this rabbithole rapidly leads us to a place of advanced paranoia When it comes to security, today's advanced paranoia is next year's common sense. Remember that folks used to think that telnet over the Internet was harmless. Would OWS refuse to implement a court order directing them to collect and forward metadata? I don't know.