I do wish Signal would be more transparent though. Given that this is such a difficult problem and they've been struggling with it for years, it reasons that it is time to seek help. This is like when a student just studies for hours and hours on end, spinning their wheels. They aren't learning anything. At some point you need a tutor, help from a friend, or asking the professor for help. (Or analogy in work if that's better)
Signal, it is time to be transparent.
Opening up usernames (in the conventional sense) you will end up needing to verify and act as an arbiter. This is due to the fact that certain usernames have real world meaning behind them and you don't want to create an ecosystem where it is really easy to honeypot whistleblowing platforms (how do you ensure that CNN gets {CNN, CNN-News, CNNNews, etc}?). They've suggested that this might be the case given that the "Notes to self" and "Signal" users are verified with a blue checkmark. The issue is that verifying users not only makes Signal a more trusted platform but the act of verification requires obtaining more information about the user. It also creates special users. All things I'm very against. I'd rather hand out my phone number than have Signal collecting this type of information. So yeah, it isn't completely trustless, but I certainly don't want to move in the direction of requiring more trust.
And that's where I have to trust Signal, but as a protocol not a "trusted source" of information.
You mean like updating their privacy policy to explain that they are keeping sensitive user data in the cloud? They refuse. There are people in this very discussion who are (or were at least) unaware that Signal is collecting and permanently storing user data on their servers. Signal's communication on what they're collecting and how has been a total joke. I cannot consider them trustworthy and at this point I suspect that refusing to update their privacy policy is a giant dead canary intended to warn users away from their product.
They encrypt it using a pin which they ask you to set or one they generate for you. They (and anyone else) can decrypt that data by brute forcing what is often just a 4 digit number.
https://support.signal.org/hc/en-us/articles/360007459591-Si...
https://community.signalusers.org/t/dont-want-pin-dont-want-...
https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin...
They've never updated their privacy policy to cover their new data collection practices even after requests (see https://community.signalusers.org/t/can-signal-please-update...)
The scheme they came up with to store user data in the cloud was described here: https://signal.org/blog/secure-value-recovery/
The code is here: https://github.com/signalapp/SecureValueRecovery
This site does a pretty good job of explaining why this isn't a good design: https://palant.info/2020/06/16/does-signals-secure-value-rec...
Lots of discussion here: https://community.signalusers.org/t/proper-secure-value-secu... and also https://community.signalusers.org/t/sgx-cacheout-sgaxe-attac...
Even more details here: https://community.signalusers.org/t/wiki-faq-signal-pin-svr-...
The major change was that pins were mandatory initially but the UX was so bad they had to give people a way to opt out of setting a pin. There is no opting out of having your profile/contacts data collected and stored in the cloud though.
You linked to a repository that uses Intel SGX which is used in this instance specifically to address your false claim that the e2e encryption used is easily bruteforced.
It also doesn't store any lists of who you contact; this claim is false. You've already been asked once for code references for your inaccurate claims, it's time for PoC or GTFO.
Here is the data that gets collected and stored in the cloud:
https://github.com/signalapp/Signal-Android/blob/3553a28683d...
> It also doesn't store any lists of who you contact; this claim is false.
The entire point of Signal adding pins was to protect the data Signal now stores so that you can recover it. That includes: your contacts, profile, and settings. Signal is required to store your contacts in order for that to happen.
Signal does not even try to deny that they collect and store your contacts. They just don't say so plainly and they often present the fact in misleading ways. Here's one example of them explaining their reasoning for storing your contacts on their servers:
"We're trying to add support for identifiers that aren't phone numbers, since that's what we've heard from users. If we do that, your signal contacts can't live in your address book anymore. Every other app just stores that in plaintext on their servers, which we don't want to do." [source](https://twitter.com/moxie/status/1277737851107471360?s=20)
> You linked to a repository that uses Intel SGX which is used in this instance specifically to address your false claim that the e2e encryption used is easily bruteforced.
It doesn't "address my false claim" it supports it. Again, please read the links. Especially https://community.signalusers.org/t/proper-secure-value-secu... since it addresses both the brute force issue, and why SGX is not able to protect the data. You might find https://community.signalusers.org/t/sgx-cacheout-sgaxe-attac... helpful as well.
As for SGX, my understanding is that 1) this exploit is pretty technical 2) it requires physical access and 3) that it is not the primary method of security, but a secondary one. If I understand this correctly I don't really see why this is an issue.
I'm not quite sure what I'm missing here, but I do appreciate your responses. I'm more than willing to admit that I just don't know/understand. I'm not sure where the breakdown in communication is happening (I'm not a security expert so it very well might be me).
https://github.com/signalapp/Signal-Android/blob/main/app/sr...
You wanted to know what Signal was storing and if they could decrypt it. I linked to an FAQ which says:
Storage Service (the “cloud”) What is stored?
All information stored is encrypted; note again that each storage record uses a different derived key for encryption.
This protobuf file explains which information is stored, and how it is structured. You’re probably most interested in this part which shows the actual data that’s stored; it should be self-explanatory, so not copying the list here. Notably, message history is currently not backed up using Storage Service.
The "You’re probably most interested in this part" bit linked to that same github page.
The same FAQ continues:
What is it used for?
Restoring some information upon re-installation/registration of the Signal app (on same or new device) by entering your Signal PIN. This is only possible if you are re-registering with the same phone number you used previously. Not available if you’ve disabled the Signal PIN (in this case only possible with manual backup/restore (Android) or transfer (iOS); these methods additionally preserve your message history).
Syncing contacts and groups to linked devices (this is made possible by syncing the “base” storage service key to linked devices). This is still partially being done using Signal Protocol sync messages, but that is unreliable
This tells you what they are collecting, but you also wanted to know if they could access it, and the answer is yes. I linked to one article explaining some of problems with the security of Signal's set up, but here is another https://www.vice.com/en/article/pkyzek/signal-new-pin-featur...
> As for SGX, my understanding is that 1) this exploit is pretty technical 2) it requires physical access and 3) that it is not the primary method of security, but a secondary one.
Finding exploits is hard, using them is often pretty easy. As the article put it SGX enclaves are “a sort of wet paper bag for clustering sensitive info.” but if you're interested here's a discussion on some of the issues with SGX here: https://news.ycombinator.com/item?id=23468746
Physical access isn't a problem for state actors or Signal employees, and without the enclave we're back to being protected by 4 digit PINs again which is no protection at all.
I've asked for evidence twice and you have supplied none.
Instead of linking to source code examples, which is easily misunderstood, here is Matthew Green's summary:
https://blog.cryptographyengineering.com/2020/07/10/a-few-th...
Alternatively, you can just open the app settings, which tells you that it will attempt to restore your contacts if you create a PIN:
> PINs keep information stored with Signal encrypted so only you can access it. Your profile, settings, and contacts will restore when you reinstall. You won’t need your PIN to open the app
If you want to go on believing that someone at Signal has found a way to backup your contacts so that you can recover them when you use a new device that does not in any way involve Signal collecting your contacts and storing that data to push back down to you later be my guest. You believe in magic, and I'll continue to believe their own statements, code, and documentation.
Are you arguing that the feature to restore contacts doesn't exist or just stating that you can't make it work?
> We're trying to add support for identifiers that aren't phone numbers, since that's what we've heard from users. If we do that, your signal contacts can't live in your address book anymore. Every other app just stores that in plaintext on their servers, which we don't want to do.
I'm not a sec person, but isn't this along the lines of what I was getting to with my original post? Seems like you can't have your cake and eat it too.
- No way to back up this information without cloud storage: why not let users backup their settings and contacts and profile to an encrypted file stored locally that can be copied to SD card, transferred via USB, or even uploaded wherever the user wants?
- No way to opt out entirely: What if I don't want this functionality at all and I don't care if my new phone doesn't have my settings and contacts and profile picture?
They've stated that they have plans to expand the data they're keeping in the cloud for other things down the road. It's not clear yet what they will do with it, but I get the impression that the reason they chose to start collecting user data was to enable them to grow into whatever they become.
There are lots of ways Signal could have improved their data collection and storage practices to better protect their users. Requiring strong passwords instead of pins would have been great! Not depending on the security of an enclave that has already been proven to be vulnerable to attacks would have been even better. Not storing user data at all would be ideal, but yeah, I get that they are within their rights to change the scope of their product to include data collection and cloud storage in order to offer new features.
My real issue with Signal is that this change was so poorly communicated that a lot of people (as evidenced by many in this discussion) aren't even aware that they are collecting data at all. All of the this confusion is entirely Signal's fault, and it'd be a bad look for any company, but this is a product where trust is critical. Where literal lives are on the line. Anyone using Signal deserves to know what their risks are, and Signal has worked to make that extremely difficult.
The fact that they are being deceptive, even after all this time, makes me think it's possible the service has been compromised and they are communicating to users to avoid using Signal as loudly as the law will allow. Not updating their privacy policy works wonderfully as a canary.
For what it's worth, I was a big fan of Signal. I loved the app. I recommended it to everyone! One of the most disappointing things about this entire fiasco is that there's no replacement I've seen that is as good! I've been playing around with a few alternatives, but Signal had the polish that made it ideal for both secured communications and plain old SMS/MMS. It's damaged goods now though. If I were fine with using an app I couldn't trust I might as well use whatever shipped with my phones.
I fail to see any fundamental difficulty here.
Or in other words: suppose the definition of "phone number" was expanded to include alphanumeric characters and @. What aspect of Signal's current design would break? By saying "without phone numbers, they can't use clientside contact lists", you seem to be suggesting that something would break, but I can't imagine how, unless it's as trivial as a database constraint that says "this field must contain only digits".
I feel like you're mis-analyzing a social problem or some other design goal as a low-level technical problem.
I don't know their real reason, but I can say that my email contact list is waaay messier and less curated than my phone contact list. It would probably be annoying is I'd get a "So-and-so joined Signal!" notification for a bunch of randos I've emailed once and had their email auto-added to my address book.
I'm mostly just confused because this is being presented as a technical limitation: using email addresses would supposedly "require Signal to keep a database of contacts serverside". I don't understand how or why that's true.
I don't know what the real reason is, what I said was just something that popped into my head. Another comment mentioned spam-prevention as a reason (by making it infeasibly expensive), and that actually makes more sense. Honestly, there probably isn't just one reason, but a cluster of tradeoffs.
> Isn't it better to have a larger pool of people with whom I can communicate securely using Signal?
IMHO, the number people who care deeply enough about the phone number thing to boycott Signal is vanishingly small; not even a rounding error. Sure they're loud on HN or maybe even Twitter, but giving tiny but loud minorities whatever they demand is bad policy.
What I meant was: "it's better if I can use Signal to communicate with people even if all I know is their email address".
One of the reasons I wish I could use something other than my phone number and access to my contact list to work with signal is these notifications creep me the fuck out and I would rather never get them, or have anyone get them about me.
I'm fine with it being a feature for people who want it, but I don't. I want to make my own damn choices about who I talk to through it.
OS functionality? There no "Grant access to Gmail contacts" (= email addresses) on Android/iOS, so that client-side list would have to be manually maintained, while (practically) everyone already has a contact list containing phone numbers of their friends.
That said I don't see why a user would have to have a stored social network at all, why can't it simply be opt-out?
But this is all moot because phone numbers aren't just opaque binary strings. They are more useful than other forms of identification.
Addendum: also, there is nothing preventing this type of contact book data from being backed-up/synced to a new phone, like any other data and settings of any other app. iOS has this feature since like 7 years now. Android, too, I'm sure.
How do you transmit said anonymous user token securely? Using the secure messaging app you're already using? Meeting up in real life? Posting it on keybase? Each of these has downsides that are all solved by a phone number.
I regularly DM people I haven't seen in person in years. I'm not going to fly cross-country to bootstrap a communication channel.
> or exchanging account names in whatever way you initially exchanged phone numbers?
Well because I exchanged phone numbers irl 7 years ago. I do not have a time machine.
> You don't seem concerned over the security problem of account activation codes being sent over SMS, so I don't see why you should be concerned over exchanging anonymous account names in the same or more secure ways.
Correct, because the bit of information "I have a signal account" is far less revealing than the bit of information "I have shared my signal account with a particular individual".
You avoid that only with some kind of public attestation of your signal identity (in keybase or on twitter or whatever) which is the best option, but generally requires everyone have a known public index of their forms of contact, which my friends from high school, generally speaking, don't.
(I still consider it a major downside that the phone number is the only lookup key)
I don't understand why you state this, when you obvioulsy know that data is connectable and joinable across discrete sources. Being "the only social network available to service X" is the inherent case for every single online service on the entire planet when viewed as an isolated entity. But this isn't a case of anonymized UUIDs. It's a case of personal phone numbers.
Apart from using the device contact list (which contains email addresses as well as phone numbers) the client can also keep a private contact list.
E-mail as a complement should work fine and supported in all contact lists. It wouldn't change a thing wrt what you're describing.
1. Support phone number contact discovery, with persistence provided by the contacts provider. This is seamless and causes the least amount of complaints.
2. Support username discovery, with persistence provided by passphrase-encrypted online storage. This is painful and risks backlash from people losing access to data. Also, now the threat model must account for or ignore weak derived keys (which is probably most of them).
- 2a. Enforce strong passphrase requirements. Many users will abandon the product.
- 2b. Sync usernames between linked devices (using a generated key). Requires multiple devices, risks people losing data, more complaints.
- 2c. Sync usernames using custom contacts provider fields (e.g. email). Nobody is accustomed to doing this, but it might work. Automatic discovery rates would be low. Possibly requires an odd workflow for people adding Signal contacts by their email/username.
Now they use a solution based on Intel SGX and server-side trusted computing [2].
- Having a server to hold your contacts
- Or having signal app to maintain contact list and sync it across devices
Are you sure that it makes sense to require people to pick something longer and non-numeric for a PIN?
Or is your claim (wrongly) that people don't have longer non-numeric PINs (lots of us do) ?
The "brute-force attacks" imagined here are a bad guy somehow controls Signal's systems, or else the US government seizes them and then decides to try to brute force them, right ?
But these are attacks where for various rival systems it was already game over. So your assumption is that Signal's casual users, people who maybe were also considering Whatsapp or iMessage or something, should be required to have a cryptographically strong passphrase so as to defeat this unlikely circumstance, as a minimum?
Moxie's whole deal is that this stuff only works when it's for everybody. If there are a five people in your country who use Signal, guess what, the Secret Police can round them up as suspected terrorists and execute them. Were they planning to bomb the President For Life? Or just organising a pizza party? Don't care, it's just good policy. But if there are five million people who use Signal that's a different matter.
Even if all five million are terrorists, that's numbers where you're going to have to tear up your "no negotiating with terrorists" policy, 'cos there are just too many of them.
As it stands now, people who create a Signal PIN aren't even warned about the security implications of using weak numeric PINs, which is among the worst of all possible worlds.
If this feature is critical, it should have been gated behind prominent passphrase entropy warnings, along with the data being put at risk [1], or it should have enforced actual strength requirements.
Signal is still better than most other messengers. I am mostly comparing it to its former self. And its former self worked flawlessly without needing to upload persisted contacts information.
1. https://github.com/signalapp/Signal-Android/blob/main/libsig...
But brogrammers will. /s
It'd also be nice to let the current user of your old number to be able to join Signal without issues.
I'd say don't play with fire and migrate as soon as possible before having issues.
You probably could follow https://support.signal.org/hc/en-us/articles/360007062012-Ch...
Then the people with who you discussed on Signal will be notified of your number change. If you can't follow this, better decide to handle it the best way you can instead of having to deal with this when you have lost access.
Basically if someone tries to register to Signal with your phone number they'll need to enter that PIN Signal consistently reminds you of.
You see, if the other person didn't use registration lock, now you've got access to complete strangers account.
Problem solved!
If you view Signal as "a service that allows you to send E2E messages to phone numbers" then this is fine. Your friends will even get a message that says the chat has been rekeyed once the new person sets up Signal.
And if you're worried about government's compelling your cell carrier to turn over your phone number then rest assured that usernames wouldn't help you since they could just compel Signal to turn over your username. So much safer.
As long as the source of identity is something other than a private key that is owned and controlled by the user and devices must have their keys signed by that key to be considered valid it will be the same issue.
I have no respect or interest in using any service which requires a cellphone to use it by fiat.
I don't really have any great concern about the government requesting my information, not because I "don't have anything to hide" or "because I'm too boring to care about" but simply because I don't care if they do. They will do what they will do. I will do what I will do. It's immaterial for me to worry and fret over the actions of someone else. Governments are simply a form of authority which protect those who pay up, and harm those who don't. It's neither my protector or my enemy, it's just a thing that demands money from me from time to time.
As far as secure communications are concerned, if someone is truly concerned about such things, the only reliable method I'm aware of is a one-time pad. [1] For most, such a system would be far too bulky and cumbersome to bother with, meaning that the communication itself is, in actuality, not worth securing to the highest degree. This, in turn, makes the thousands of digital alternatives "good enough" for all but nation-state threat actors. [2]
To replace the numbers with usernames, Signal users would have to either give up contact lists altogether (at which point nobody would use the service), or allow Signal to keep a serverside database of contacts ready at all times for users who log in. This is what other messaging services do, and the result is that the servers have a plaintext log of who talks to who on their service, which is the most valuable information a secure messaging service can make available to a state-level adversary.
This makes sense for contact discovery, which is important for normal people who just want a chat app that works.
But there are a very important segment of signal users, people with an elevated threat model, who I would be willing to bet a good portion of them would gladly sacrifice contact lists if it meant not having to share their phone number.
Why couldn't they just keep using the current system, alongside usernames, for phone number contact discovery? Of course for those who opt into it; imo that's what it should be.
Could you please explain how Signal does not have a social network map, when 1) user accounts are equal to mobile phone numbers, and 2) Signal servers route messages between user accounts.
Even if Signal's server saves a message (they claim not to, once downloaded), Signal's server by design has no way of knowing who sent the message.
Also, wasn't "sealed sender" broken (again) earlier this year by a group of researchers?
There is no authentication by the sender, and the sender does not upload any credentials.
> Without authenticating, hand the encrypted envelope to the service along with the recipient’s delivery token.
Source: https://signal.org/blog/sealed-sender/#:~:text=Without%20aut...
The sender's client sends a certificate derived from the recipient's profile key.
This certificate is sent to the server as the header "Unidentified-Access-Key" - you can see how this header is derived from the Signal clients' source.
So yes, these API calls are authenticated, but not using the sender's credentials in any way.
The server and clients are open source: https://github.com/signalapp
Also, everyone not sharing their contacts with the signal app already have that UX. Minus the privacy benefits of course.
A) Most contacts have phone numbers
B) Most contacts don't have email addresses?
Are you also assuming that it just adds a lot of complexity to be willing to search by both phone numbers and emails?
That's the part of your argument I'm not grasping. Signal has to be willing to intersect known-account-identifiers with this-device's-local-contact-handles, what's the problem with preferring phone numbers but allowing emails?
Is there a reason why a user's address book can't be encrypted as well?
I just want to be able to communicate without sharing my phone number (since my phone number is bound to Swedish "Swish") meaning someone can get my ID from my phone number here.
This is why drug dealers use Wickr, Threema and others, because they don't expose identity, not because they're "safer".
I have a contact on Threema who I've met many times, but I have no idea how to contact him outside of Threema, because I don't know his identity and we'd both like to keep it that way.
Email can absolutely be used for with e2e encryption keeping the content of exchanges from external eyes.
Email can absolutely not be used for hiding metadata of who talks to who.
In many countries, registering phone numbers anonymously is illegal and/or impossible.
Where? Gmail and hotmail both don't allow this.
Do you just care about making burner anonymous emails that just work all the time? There are vendors that you can pay for that service (my go to is protonmail), and there are free options out there as well (my go to is riseup). The problem is finding the vendor that suits your need, since these are niche services for the most part.
If you care more about the privacy / sovereignty side of things, you can set up your own mailserver, and once thats done, its incredibly trivial to spin up new burner emails. But that's an even bigger knowledge gap, to the point where its fairly common even on tech forums like HN for folks to be like "Self host email? nope thats to hard".
So yeah, I agree. This is not really an option for an average user. But in the context of signal, I think it makes perfect sense to allow it as an option, even if its not the default.
On Telegram this is rampant, on average probably one person per day. It shifted from e-gold scams to sex since a few months, but both are still present. People that aren't in big groups (where the spammers scrape user IDs) have zero problems, so the trick is revealing your random identifier only to those you want to contact you. Phone number identifiers are the antithesis to spam protection: we keep our ranges just full enough that we can't shorten it by a digit, but empty enough that we have small growth possibilities. You're very likely to hit a subscriber, by design, by trying random numbers.
That also sounds like a good way to limit adoption as well, at least for anyone with more the N contacts, particularly >= 2N as that means likely a minimum waiting period before you can transfer over "more" contacts since some people will never accept/reject the invite because they don't use the app much.
If it were me and I had to wait on others to accept or reject my invite before I can continue transferring contacts, I'm gonna move on.
Spam via sms doesn't seem to really exist here, maybe two per year now, up from zero until three years ago.
...eh, who am I kidding?