With a phone number, the contact graph can be on the phone. With usernames, the contact graph has to be stored on their servers.
They were forced to store (encrypted) information on servers anyway, since client-side contact matching didn't end up scaling, which is why stuff like this and usernames are now being developed.
Their new security strategy now relies on decryption being done by client-attested code on SGX enclaves, so that the server still doesn't have access to the plain-text contact graph.
All of this took a huge amount of time to come up with, and you can see the progress if you read their blogs or forums.
> With usernames, the contact graph has to be stored on their servers.
Are you suggesting that there isn't a contact graph on their servers? How exactly do they route from one user to another? It's certainly not P2P.
If you are suggesting that we should trust them just because it could work without them storing who I've contacted, you are mistaken. The whole point of private messaging is to obviate the need for trust. The code should be auditable/open source, and everything on the server should be either transparent, or assumed to be compromised. They certainly do send your contact graph to their servers, and whether they say they discard it or not is irrelevant. In the context of privacy, you must assume your data is persisted once it is behind a curtain you have no visibility into.
They only started sending your contact graph after adopting SGX. Before that the matching used to happen client side through a bloom filter.
They can theoretically rebuild a contact graph by finding everyone you’re talking to, but that’s a small subset of the contact graph created by contact matching.
The code is open source and SGX literally means that the client attests that the code on the server matches what it’s expecting.
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.
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.
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.
They were forced to store (encrypted) information on servers anyway, since client-side contact matching didn't end up scaling, which is why stuff like this and usernames are now being developed.
Their new security strategy now relies on decryption being done by client-attested code on SGX enclaves, so that the server still doesn't have access to the plain-text contact graph.
All of this took a huge amount of time to come up with, and you can see the progress if you read their blogs or forums.