3 ms·

Here you go: https://signal.org/blog/private-contact-discovery/ https://signal.org/blog/private-contact-discovery/

by sa1 5y ago

colordrops 5y ago
Thanks for being patient and providing links. How do we know the closed source version of signal on the app stores is using the same MRENCLAVE as the one from the open source server? Also, my understanding as to why a contact graph is needed at all is because signal wants to increase their virality. Couldn't we forgo this unnecessary feature? Signal could generate a long enough key locally, and if you want to add another signal user, the client could send it automatically to a contact through SMS. The client on the other side could automatically read the key through SMS and add the contact. Or the user could manually send the key through any mechanism they wanted. A third note, trusting SGX assumes that 1. it has no bugs, and 2. it has no backdoors, 3. Signal server code has no bugs, 4. Signal server code has no backdoors. The first two of these are not strong guarantees, especially considering that it's not open source, intel doesn't have a great track record, and nation state actors have been involved in weakening these sorts of features in the past. At least with the Signal server code you can audit it.
- sa1 5y ago
  You've hit upon the limits of Signal and other messengers. The version on app stores is not a closed source version. However it is a binary, and there might be questions on build reproducibility. I do not know the answer to this nor the answer to your MRENCLAVE question. Virality is because of their philosophy - their first goal is to end mass surveillance, not provide custom software for preventing individual surveillance. The quicker everyone in the world is using E2E, not only is there less mass surveillance, contact discovery leaks zero additional information at that point. Concerns with SGX are real - but it remains the state-of-the-art - your criticism assumes that the competitors do any better, at this point they do not. They have traditional backends or are as flawed. Signal is doing the hard work on researching solutions at this point, the others are not as close. > Signal could generate a long enough key locally, and if you want to add another signal user, the client could send it automatically to a contact through SMS. The client on the other side could automatically read the key through SMS and add the contact. Or the user could manually send the key through any mechanism they wanted. This is what happens when contacts verify each other through QR codes on Signal. But this mechanism does not solve your problem nor are you solving the problem Signal wanted to solve - minimizing data on servers. Even with keys, servers still has to route messages, and with your solution they'll have to maintain a user database.
  - colordrops 5y ago
    I have heard that one of Signal's goals are mass adoption, so it's presumed that some compromise is required to make this happen. I hope they continue to push the envelope toward more transparency. This was an enlightening and educational discussion. thank you.

Here you go: https://signal.org/blog/private-contact-discovery/ https://signal.org/blog/private-contact-discovery/

by sa1 5y ago

Here you go: https://signal.org/blog/private-contact-discovery/ https://signal.org/blog/private-contact-discovery/

Thanks for being patient and providing links. How do we know the closed source version of signal on the app stores is using the same MRENCLAVE as the one from the open source server? Also, my understanding as to why a contact graph is needed at all is because signal wants to increase their virality. Couldn't we forgo this unnecessary feature? Signal could generate a long enough key locally, and if you want to add another signal user, the client could send it automatically to a contact through SMS. The client on the other side could automatically read the key through SMS and add the contact. Or the user could manually send the key through any mechanism they wanted. A third note, trusting SGX assumes that 1. it has no bugs, and 2. it has no backdoors, 3. Signal server code has no bugs, 4. Signal server code has no backdoors. The first two of these are not strong guarantees, especially considering that it's not open source, intel doesn't have a great track record, and nation state actors have been involved in weakening these sorts of features in the past. At least with the Signal server code you can audit it.

sa1 5y ago
You've hit upon the limits of Signal and other messengers. The version on app stores is not a closed source version. However it is a binary, and there might be questions on build reproducibility. I do not know the answer to this nor the answer to your MRENCLAVE question. Virality is because of their philosophy - their first goal is to end mass surveillance, not provide custom software for preventing individual surveillance. The quicker everyone in the world is using E2E, not only is there less mass surveillance, contact discovery leaks zero additional information at that point. Concerns with SGX are real - but it remains the state-of-the-art - your criticism assumes that the competitors do any better, at this point they do not. They have traditional backends or are as flawed. Signal is doing the hard work on researching solutions at this point, the others are not as close. > Signal could generate a long enough key locally, and if you want to add another signal user, the client could send it automatically to a contact through SMS. The client on the other side could automatically read the key through SMS and add the contact. Or the user could manually send the key through any mechanism they wanted. This is what happens when contacts verify each other through QR codes on Signal. But this mechanism does not solve your problem nor are you solving the problem Signal wanted to solve - minimizing data on servers. Even with keys, servers still has to route messages, and with your solution they'll have to maintain a user database.
- colordrops 5y ago
  I have heard that one of Signal's goals are mass adoption, so it's presumed that some compromise is required to make this happen. I hope they continue to push the envelope toward more transparency. This was an enlightening and educational discussion. thank you.