You sign up to use Signal using your phone number which is a personally identifying piece of information. Signal clients send messages to the server that routes the messages to their destination. It is not a p2p system where clients talk directly to each other. Therefore, the server must know both the sending and receiving accounts for the messages it routes, and it has the phone numbers associated with this accounts. All these things together make it trivial for the server to know which phone numbers talk to each other.
but also perhaps more academically because signal (i believe) doesn’t do this, so it’s more a comment on the information that the server “must know”
signal uses the double ratchet protocol to derive shared keys between users already. if we extend this a little further to exchange a separate shared identifier for use in retrieving conversaiton data, and a place to store that data the the only information that the server gets is a couple of initialisation messages, and the rest is entirely opaque - there’s no way to know (other than tracing e2e messages based on IP address, and there are mitigations for that too) who is communicating with who, at what rate, etc
there are other ways to validate things like rate limits, etc that don’t involve identity directly, or at least don’t trust any single party with all data
Unless you compiled the app yourself from source code that you understand, you don’t really know what the app might be saying to Signal’s servers. Almost everyone just trusts that the pre-compiled app supplied by Apple or Google aren’t compromised. But we know from history that Big Tech and the military-intelligence-industrial complex are in bed with each other.
That’s nonsense, because many different people read the source and audit open source software. While it’s certainly possible to sneak malicious code in, the trust doesn’t depend on each single individual auditing it. It’s a collective effort.
You have provided literally nothing to back up your assertion.
Signal does not know who talks to whom. It’s kind of the main thing about the double ratchet.
You sign up to use Signal using your phone number which is a personally identifying piece of information. Signal clients send messages to the server that routes the messages to their destination. It is not a p2p system where clients talk directly to each other. Therefore, the server must know both the sending and receiving accounts for the messages it routes, and it has the phone numbers associated with this accounts. All these things together make it trivial for the server to know which phone numbers talk to each other.
that’s all not necessarily true
for starters: https://signal.org/blog/sealed-sender/
but also perhaps more academically because signal (i believe) doesn’t do this, so it’s more a comment on the information that the server “must know”
signal uses the double ratchet protocol to derive shared keys between users already. if we extend this a little further to exchange a separate shared identifier for use in retrieving conversaiton data, and a place to store that data the the only information that the server gets is a couple of initialisation messages, and the rest is entirely opaque - there’s no way to know (other than tracing e2e messages based on IP address, and there are mitigations for that too) who is communicating with who, at what rate, etc
there are other ways to validate things like rate limits, etc that don’t involve identity directly, or at least don’t trust any single party with all data
JFC are all you .ml folks this ignorant??
What an amazing counterpoint you’ve mustered.
Unless you compiled the app yourself from source code that you understand, you don’t really know what the app might be saying to Signal’s servers. Almost everyone just trusts that the pre-compiled app supplied by Apple or Google aren’t compromised. But we know from history that Big Tech and the military-intelligence-industrial complex are in bed with each other.
Okay. You tell me what the double ratchet is, since you’re so smart.
The double ratchet algo is irrelevant if the app is doing something else altogether.
Compiling the app is irrelevant if I don’t read the source.
That’s nonsense, because many different people read the source and audit open source software. While it’s certainly possible to sneak malicious code in, the trust doesn’t depend on each single individual auditing it. It’s a collective effort.
okay, but reproducible builds solve the rest of that problem
https://signal.org/blog/reproducible-android/
Yeah, now that they finally have reproducible builds, at least you can trust that the client is doing what it says it’s doing.