3 ms·

I don't see how account-based systems, or Wire in particular, must "effectively store[] a log of every pair of users that have spoken to each other on the platf

by gojomo 7y ago

I don't see how account-based systems, or Wire in particular, must "effectively store[] a log of every pair of users that have spoken to each other on the platform, in a database, constantly available". As far as I can tell – and just like Signal – they just need to hold (destination-ID, blob) for all as-yet undelivered messages. And if the destination-ID isn't a phone-number, it's harder to correlated with other extant databases of (phone-number -> IMEI) or (phone-number -> person). That is, this undelivered-log has less metadata in an account-based system than a phone-number-based system. I get that using the contact-lists, and the constant re-uploading of contact-lists, is great for Signal's bootstrapping. Anchoring IDs to phone numbers might also work as an abuse throttle. But I don't see how it minimizes metadata. Can you clarify?

tptacek 7y ago
The contact graph isn't necessary to deliver messages, but it is necessary to make the system usable: when people open up the application, they expect to see a contact list. To make that feature work, most systems just store the contact list on the server; the aggregation of all those contact lists is the entire contact graph for the service. That's the thing Signal won't store.
- gojomo 7y ago
  Sure, it makes it more usable. (Though, I use Telegram & WhatsApp with many contacts just fine without sharing my contact list with them, neither once nor the repeated-uploads Signal wants.) But Signal could still be keeping a database log of everyone who's actually ever sent a message to anyone else. (To the extent anyone's using 'sealed sender', it'd be harder – but apps like Wire could do something equivalent to 'sealed sender', too.) And that database is way more valuable to many attackers if it's keyed by the phone-numbers Signal has, compared to the aliases other systems have. And to the extent the Signal client wants to keep re-uploading my entire contact-list, even a one-time, temporary compromise of their SGX-based system would reveal all my phone contacts.
  - tptacek 7y ago
    The synchronized contact list feature of other messengers requires them to keep the contract graph stored. We don't have to wonder whether they're logging it; they have to be.

by gojomo 7y ago

tptacek 7y ago

The contact graph isn't necessary to deliver messages, but it is necessary to make the system usable: when people open up the application, they expect to see a contact list. To make that feature work, most systems just store the contact list on the server; the aggregation of all those contact lists is the entire contact graph for the service. That's the thing Signal won't store.

gojomo 7y ago
Sure, it makes it more usable. (Though, I use Telegram & WhatsApp with many contacts just fine without sharing my contact list with them, neither once nor the repeated-uploads Signal wants.) But Signal could still be keeping a database log of everyone who's actually ever sent a message to anyone else. (To the extent anyone's using 'sealed sender', it'd be harder – but apps like Wire could do something equivalent to 'sealed sender', too.) And that database is way more valuable to many attackers if it's keyed by the phone-numbers Signal has, compared to the aliases other systems have. And to the extent the Signal client wants to keep re-uploading my entire contact-list, even a one-time, temporary compromise of their SGX-based system would reveal all my phone contacts.
- tptacek 7y ago
  The synchronized contact list feature of other messengers requires them to keep the contract graph stored. We don't have to wonder whether they're logging it; they have to be.