3 ms·
Correction. ONLY the contacts WITHIN Signal contact address book is used. Signal contact address book is wholly kept separate from your phone OS contact addre
by 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 agoAs 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 agoIf 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.