3 ms·
All of your answers are in the links I provided, I'm more than happy to help, but please make an effort too. Here is the data that gets collected and stored in
by autoexec 4y ago
All of your answers are in the links I provided, I'm more than happy to help, but please make an effort too.
Here is the data that gets collected and stored in the cloud:
https://github.com/signalapp/Signal-Android/blob/3553a28683dd1c6d5f432a61104cf85d39f0c600/libsignal/service/src/main/proto/StorageService.proto#L67-L168 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 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-security-pins-are-too-easy-to-brute-force-sgx-is-not-reliable-enough/15096 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-attack-signals-cloud-storage-and-contact-discovery-vulnerable/14892 https://community.signalusers.org/t/sgx-cacheout-sgaxe-attac... helpful as well.
- sneak 4y agoThe 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.
- autoexec 4y agoLook 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.
- dvzk 4y agoprotobuf 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: 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... 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
- godelski 4y agoI 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).
- autoexec 4y ago> 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-feature-worries-cybersecurity-experts 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 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.