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
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.