4 ms·

Given that we've seen exactly how little information Signal maintains about its users [0], this seems to me to be alarmist spreading of FUD, potentially to adva

Given that we've seen exactly how little information Signal maintains about its users [0], this seems to me to be alarmist spreading of FUD, potentially to advance the author's agenda of dfederation in Signal, which the developers have already addressed at length already [1]. For example, their assertion that "... metadata is abundantly available here" appears to be patently false, given [0]. 0: https://www.aclu.org/blog/free-future/new-documents-reveal-government-effort-impose-secrecy-encryption-company https://www.aclu.org/blog/free-future/new-documents-reveal-g... 1: https://whispersystems.org/blog/the-ecosystem-is-moving/ https://whispersystems.org/blog/the-ecosystem-is-moving/

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 ago
  We 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 ago
  The 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.
acqq 10y ago
> appears to be patently false Even if it is claimed that the metadata miraculously wasn't collected (provided it really wasn't collected under some other publicly invisible arrangement, which is still technically doable) that doesn't prove it is impossible to do so, especially as the result of another secret request. I don't see the "FUD" in the article. It seems very popular using labels instead of talking about issues, but please, please don't. The phone number problems were known since long, and the Signal's explanation "it's easier for the average user this way" doesn't explain why other alternatives aren't even allowed. It's obvious there are certain goals behind Signal, and those with different goals have to organize themselves. What they surely can't do is claiming to have right to decide what Signal (as a company) does. If those who have clear needs want to introduce their own solution, they surely have to demonstrate what the Signal doesn't solve, and that's surely not FUD.
throwaway98764 10y ago
Federation was only addressed insofar as Moxie Marlinspike the developer noted it would be hard to keep the protocol updated if the servers were shared (he compared his tech to Facebook and WhatsApp, and described federated email as "stuck in time"). There's nothing unduly alarmist about the article, but it makes appropriate claims about (among other things) the security limitations that Signal has resigned itself to by remaining unfederated. Read TFA.
sergiolp 10y ago
Centralization is a _huge_ privacy issue. Specially when combined with real world data, like a phone number. Let's assume OWS is playing nice, and they really don't store any relevant metadata. How can we be sure that a third party is not eavesdropping their communications? Even with end-to-end encryption, given enough time, an attacker can easily build a user relationship network, something _very_ dangerous in the wrong hands. If you really care about privacy, you should consider options like BitMessage, Onion.chat, Ricochet, Tox or GNU Ring. Or, as a middle ground between those (which are quite mobile unfriendly, due to its P2P nature) and Signal/WhatsApp/Telegram, a federated service like XMPP (as the article suggest) or Matrix.

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 ago
We 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 ago
The 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.

acqq 10y ago

> appears to be patently false Even if it is claimed that the metadata miraculously wasn't collected (provided it really wasn't collected under some other publicly invisible arrangement, which is still technically doable) that doesn't prove it is impossible to do so, especially as the result of another secret request. I don't see the "FUD" in the article. It seems very popular using labels instead of talking about issues, but please, please don't. The phone number problems were known since long, and the Signal's explanation "it's easier for the average user this way" doesn't explain why other alternatives aren't even allowed. It's obvious there are certain goals behind Signal, and those with different goals have to organize themselves. What they surely can't do is claiming to have right to decide what Signal (as a company) does. If those who have clear needs want to introduce their own solution, they surely have to demonstrate what the Signal doesn't solve, and that's surely not FUD.

throwaway98764 10y ago

Federation was only addressed insofar as Moxie Marlinspike the developer noted it would be hard to keep the protocol updated if the servers were shared (he compared his tech to Facebook and WhatsApp, and described federated email as "stuck in time"). There's nothing unduly alarmist about the article, but it makes appropriate claims about (among other things) the security limitations that Signal has resigned itself to by remaining unfederated. Read TFA.

sergiolp 10y ago

Centralization is a _huge_ privacy issue. Specially when combined with real world data, like a phone number. Let's assume OWS is playing nice, and they really don't store any relevant metadata. How can we be sure that a third party is not eavesdropping their communications? Even with end-to-end encryption, given enough time, an attacker can easily build a user relationship network, something _very_ dangerous in the wrong hands. If you really care about privacy, you should consider options like BitMessage, Onion.chat, Ricochet, Tox or GNU Ring. Or, as a middle ground between those (which are quite mobile unfriendly, due to its P2P nature) and Signal/WhatsApp/Telegram, a federated service like XMPP (as the article suggest) or Matrix.