4 ms·

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 enc

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.

godelski 4y ago
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 https://support.signal.org/hc/en-us/articles/360007459591-Signal-Profiles-and-Message-Requests https://support.signal.org/hc/en-us/articles/360007459591-Si...
- autoexec 4y ago
  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: https://community.signalusers.org/t/dont-want-pin-dont-want-anything-stored-in-cloud/14057/231 https://community.signalusers.org/t/dont-want-pin-dont-want-... 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... 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-its-privacy-policy/15323 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/ https://signal.org/blog/secure-value-recovery/ The code is here: https://github.com/signalapp/SecureValueRecovery 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-recovery-really-work/ https://palant.info/2020/06/16/does-signals-secure-value-rec... Lots of discussion here: 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... and also 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... Even more details here: https://community.signalusers.org/t/wiki-faq-signal-pin-svr-kbs-storage-service-cloud/15690?u=u32i64 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.
  - sneak 4y ago
    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.
    - 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.

godelski 4y ago

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 https://support.signal.org/hc/en-us/articles/360007459591-Signal-Profiles-and-Message-Requests https://support.signal.org/hc/en-us/articles/360007459591-Si...

autoexec 4y ago
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: https://community.signalusers.org/t/dont-want-pin-dont-want-anything-stored-in-cloud/14057/231 https://community.signalusers.org/t/dont-want-pin-dont-want-... 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... 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-its-privacy-policy/15323 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/ https://signal.org/blog/secure-value-recovery/ The code is here: https://github.com/signalapp/SecureValueRecovery 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-recovery-really-work/ https://palant.info/2020/06/16/does-signals-secure-value-rec... Lots of discussion here: 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... and also 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... Even more details here: https://community.signalusers.org/t/wiki-faq-signal-pin-svr-kbs-storage-service-cloud/15690?u=u32i64 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.
- sneak 4y ago
  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.
  - 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.