2 ms·

By the virtue of having OS-based contact. Which is why you disable contact. It asked up front if you want Signal to access contact at install time. If you sa

By the virtue of having OS-based contact. Which is why you disable contact. It asked up front if you want Signal to access contact at install time. If you say yea, then only a hashed value of each phone number found in each contact is sent. Nothing else from each and all of your contacts in your contact address book. If you say no, then nothing of contact address book is looked at. In a new phone, typically contact address book is empty. If backup is restored at new phone, then it becomes important to ensure that you say no at Signal install time when prompted and asked for permission to access your contact address book.

autoexec 4y ago
Okay, so you're saying that if I install signal and don't give it access to my contacts (at the OS level) then when I manually add contacts in Signal itself, those never get uploaded to SVR or to storage service as anything other than a hash and those contacts can no longer be recovered in Signal using SVR? For example see: https://community.signalusers.org/t/faq-signal-pin-svr-kbs-storage-service-cloud/15690 https://community.signalusers.org/t/faq-signal-pin-svr-kbs-s... https://community.signalusers.org/t/what-contact-info-does-the-signal-pin-functionality-actually-save/16854/10 https://community.signalusers.org/t/what-contact-info-does-t... I haven't seen that documented anywhere. Do you have a source?
- egberts1 4y ago
  Correction. ONLY the contacts WITHIN Signal contact address book is used. Signal contact address book is wholly kept separate from your phone OS contact address book, even when you say yes to permission to share the OS contact address book. If you say no to the sharing of contact, then ONLY those contacts created WITHIN Signal’s own contact address book would have each Signal contact’s phone number as numerically big-hashed (within your own phone), then only those hash value of your limited Signal contact address book would be (naturally) sent to Signal server. This is why I said “if you don’t mind the obtuse associativity”. And that is OK for most OpSec. What is most important here is whatever you typed, only that other contact’s phone would be able to see this, no place else. That is, until the adversary gets their hand on one of the phone before its timed message deletion period. This is all in the source code here https://github.com/signalapp/Signal-Android https://github.com/signalapp/Signal-Android
  - egberts1 4y ago
    As to the SVR and a defined PIN that activates this, this is really an “ultra-bleeding-edge super nation-state” issue. Not many can crack the SVR (outside a few professors of cybersecurity). In the short term, preserving association seems paramount over the longer-term required to crack SVR … regularly. I’m using PIN (and thusly SVR) because most of my contacts within Signal contact address book are named with family nicknames). So, SVR is filled with avatar, phone, last access, creation time, and its computed hash UserID values is that weak point but SVR is not that weak enough to prevent its practical usage for near-perfect message content anonymity. That’s why I ask family members not to bother with avatar and keeping real name off of OS primary user contact info. If you are pushing the envelope of OpSec, then disabling PIN is fine too. It doesn’t matter as long as the phone is not in the hand of adversary but steps above will make it harder, forensically. https://blog.cryptographyengineering.com/2020/07/10/a-few-thoughts-about-signals-secure-value-recovery/ https://blog.cryptographyengineering.com/2020/07/10/a-few-th...
    - autoexec 4y ago
      If I were in Iran, disabling the pin seems like the best bet. Doing that would still cause my data to uploaded to storage service, but the only people who could access it at that point would be Signal employees or some three letter agency in the US. Same with any data you allow to be uploaded via private contact discovery. It seems like the real problem for someone in Iran would be SVR since if you were suspected of breaking the law they could brute force your pin and get a list of your contacts then go after them. Well, I'd also consider it a problem that signal will promote itself to people whose freedom/lives are at risk without being upfront and very clear about the risks. The very first line of their privacy policy is "Signal is designed to never collect or store any sensitive information." which is a lie, and the details surrounding this change to start collecting user sensitive data in the cloud was communicated so poorly that to this day many (most?) users are entirely unaware it's taking place, or uncertain about how it works. See for example: https://old.reddit.com/r/signal/comments/htmzrr/psa_disabling_pins_will_now_upload_nothing_to_the/fyjy7a5/ https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin... and the OP in that thread. I can't imagine a larger red flag. That's why I suspect that signal is telling its users as loudly as they can the service is compromised. although I do wish they'd stop promoting the app to highly vulnerable people who are at real risk if their contacts are discovered.

autoexec 4y ago

Okay, so you're saying that if I install signal and don't give it access to my contacts (at the OS level) then when I manually add contacts in Signal itself, those never get uploaded to SVR or to storage service as anything other than a hash and those contacts can no longer be recovered in Signal using SVR? For example see: https://community.signalusers.org/t/faq-signal-pin-svr-kbs-storage-service-cloud/15690 https://community.signalusers.org/t/faq-signal-pin-svr-kbs-s... https://community.signalusers.org/t/what-contact-info-does-the-signal-pin-functionality-actually-save/16854/10 https://community.signalusers.org/t/what-contact-info-does-t... I haven't seen that documented anywhere. Do you have a source?

egberts1 4y ago
Correction. ONLY the contacts WITHIN Signal contact address book is used. Signal contact address book is wholly kept separate from your phone OS contact address book, even when you say yes to permission to share the OS contact address book. If you say no to the sharing of contact, then ONLY those contacts created WITHIN Signal’s own contact address book would have each Signal contact’s phone number as numerically big-hashed (within your own phone), then only those hash value of your limited Signal contact address book would be (naturally) sent to Signal server. This is why I said “if you don’t mind the obtuse associativity”. And that is OK for most OpSec. What is most important here is whatever you typed, only that other contact’s phone would be able to see this, no place else. That is, until the adversary gets their hand on one of the phone before its timed message deletion period. This is all in the source code here https://github.com/signalapp/Signal-Android https://github.com/signalapp/Signal-Android
- egberts1 4y ago
  As to the SVR and a defined PIN that activates this, this is really an “ultra-bleeding-edge super nation-state” issue. Not many can crack the SVR (outside a few professors of cybersecurity). In the short term, preserving association seems paramount over the longer-term required to crack SVR … regularly. I’m using PIN (and thusly SVR) because most of my contacts within Signal contact address book are named with family nicknames). So, SVR is filled with avatar, phone, last access, creation time, and its computed hash UserID values is that weak point but SVR is not that weak enough to prevent its practical usage for near-perfect message content anonymity. That’s why I ask family members not to bother with avatar and keeping real name off of OS primary user contact info. If you are pushing the envelope of OpSec, then disabling PIN is fine too. It doesn’t matter as long as the phone is not in the hand of adversary but steps above will make it harder, forensically. https://blog.cryptographyengineering.com/2020/07/10/a-few-thoughts-about-signals-secure-value-recovery/ https://blog.cryptographyengineering.com/2020/07/10/a-few-th...
  - autoexec 4y ago
    If I were in Iran, disabling the pin seems like the best bet. Doing that would still cause my data to uploaded to storage service, but the only people who could access it at that point would be Signal employees or some three letter agency in the US. Same with any data you allow to be uploaded via private contact discovery. It seems like the real problem for someone in Iran would be SVR since if you were suspected of breaking the law they could brute force your pin and get a list of your contacts then go after them. Well, I'd also consider it a problem that signal will promote itself to people whose freedom/lives are at risk without being upfront and very clear about the risks. The very first line of their privacy policy is "Signal is designed to never collect or store any sensitive information." which is a lie, and the details surrounding this change to start collecting user sensitive data in the cloud was communicated so poorly that to this day many (most?) users are entirely unaware it's taking place, or uncertain about how it works. See for example: https://old.reddit.com/r/signal/comments/htmzrr/psa_disabling_pins_will_now_upload_nothing_to_the/fyjy7a5/ https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin... and the OP in that thread. I can't imagine a larger red flag. That's why I suspect that signal is telling its users as loudly as they can the service is compromised. although I do wish they'd stop promoting the app to highly vulnerable people who are at real risk if their contacts are discovered.