I think they are. I just also think the problem is a lot harder than people give it credit for. If they just go with a standard username (as in some form of a database lookup) then I'll be upset. But I'll be upset because this effectively doesn't solve any issue, and introduces others that have big privacy impacts and requires Signal to be a trusted source (which is antithetical to Signal's proposed mission).
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)
Sorry, let me clarify. We should trust Signal as little as possible. That's how the design should work. Zero trust is very hard to create but let's minimize it.
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.
Signal does not tell me which number is which user. I know which number is who myself. The most Signal does is presumably warn me when the key associated with the number changed (eg. new phone).
And that's where I have to trust Signal, but as a protocol not a "trusted source" of information.
> I do wish Signal would be more transparent though.
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.
The information they collect includes your name, your photo, your phone number, and a list of all the people you've been in contact with using Signal.
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.
Can you show me this? I'd guess it would have to be in the server code, so where is it? I don't see any real information about this on their site. Their website suggests that this information is stored locally
I know. I really wish they had a simple page that explains everything. They've gone to great lengths to be confusing about what they're collecting and how.
There were several complaints about misleading communication when this change rolled out Examples:
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.
Link to the lines of code on the server that store the data in the way you describe or stop slinging mud.
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.
> 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.
I guess I'm just confused because I don't see how what you're linking answers my question. For example, the github link here shows mostly bool values and bytes. The strings I do see do include name, so I do get the argument that your name is stored (though you choose your name). But the code makes me think it is only storing a string to tell the program where your profile picture is. As I understand it, the server holds this information (encrypted) but still requires your phone to decrypt and even provide the source for things like the profile picture. This doesn't seem as bad as what you suggested previously.
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).
> I guess I'm just confused because I don't see how what you're linking answers my question.
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.
The protobuf you linked does not support your claim that Signal uploads your contact lists. You'll note that AccountRecord does not contain a list of ContactRecords other than those pinned (4 max). Indeed the application UX does not either.
I've asked for evidence twice and you have supplied none.
protobuf files just contain data structure definitions. StorageService.proto contains only one reference to StorageRecord, but Signal actually syncs hundreds of StorageRecords.
Instead of linking to source code examples, which is easily misunderstood, here is Matthew Green's summary:
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
Look pal, I've given you all the information you need. It's really all right there. I can lead you to data, but I can't make you think.
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.
> 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.
I didn't have a problem with Signal wanting to provide a way to restore people's contacts. The problems I had initially were:
- 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.
Here's an idea that's been floated many times in the past: Add e-mail as an alternative alongside phone numbers. Support in contacts in both Android and iOS. The only real difference these days is that one requires government ID (by law in an increasing number of countries) and one does not.
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.