It’s also true that Matrix servers currently store metadata about who’s talking to who, and when, as a side-effect of storing and relaying messages on behalf of their users.
..isn’t that required with signal too? somehow the message needs to get routed from one user to another..
I think the point is more regarding trust of different home servers. In a federated system, you have to trust both your home server as well as the home server of all the other parties you’re communicating with. In Signal’s case you “just” have to trust The One True Server that Signal supports.
thats kind of a non-argument though, i don’t have trust that moxie isn#t not being rubberhosed. the phone number coupling of signal is a strange decision, too, regarding how easily phones are tracked. and the chat metadata together with the rough cell phone positioning is really interesting is guess.
There are different specifics to this. I assume the kind of metadata they talk about lets you uniquely identify senders and receivers in some way (say, by storing user’s public keys or any other unique identifier in a database somewhere).
In the case of Signal, since they introduced Sealed Sender, the only information they can learn is that some IP address is talking to some specific profile. That is, only the identity of the recipient of a message is known. On mobile, I’d assume IPs change quite frequently, so how hard is to correlate them to profile identities is dependent on that.
Now, I’m not well versed in the nitty-gritty details of the implementation, and it might have changed since they introduced it in 2018, but I think it goes like this:
Alice wants to send a message containing “Hello” to Bob
Alice retrieves a sender certificate from the Signal server, attesting that they have a profile.
Alice crafts a message with the ciphertext of “Hello” and Alice’s sender certificate. She then encrypts this message using Alice’s and Bob’s identity keys.
Alice hands the message to the Signal server.
The Signal server matches the identity key of Bob, and delivers it to their device.
Bob decrypts the message, and checks Alice’s identity key against the included sender certificate. If it is valid, he can read the message.
There are more details in the post about how to prevent abuse, and of course, this is all dependent on the fact that the server doesn’t keep any information about the issuing of certificates.
i’m not convinced much extra security is gained by this. it’s still visible that ip $foo send a message, and $user is logged in from $foo. if we believe that OWS do what they tell us :)
..isn’t that required with signal too? somehow the message needs to get routed from one user to another..
I think the point is more regarding trust of different home servers. In a federated system, you have to trust both your home server as well as the home server of all the other parties you’re communicating with. In Signal’s case you “just” have to trust The One True Server that Signal supports.
thats kind of a non-argument though, i don’t have trust that moxie isn#t not being rubberhosed. the phone number coupling of signal is a strange decision, too, regarding how easily phones are tracked. and the chat metadata together with the rough cell phone positioning is really interesting is guess.
I agree 100%, but this is Moxie’s argument, not mine :)
There are different specifics to this. I assume the kind of metadata they talk about lets you uniquely identify senders and receivers in some way (say, by storing user’s public keys or any other unique identifier in a database somewhere).
In the case of Signal, since they introduced Sealed Sender, the only information they can learn is that some IP address is talking to some specific profile. That is, only the identity of the recipient of a message is known. On mobile, I’d assume IPs change quite frequently, so how hard is to correlate them to profile identities is dependent on that.
Now, I’m not well versed in the nitty-gritty details of the implementation, and it might have changed since they introduced it in 2018, but I think it goes like this:
There are more details in the post about how to prevent abuse, and of course, this is all dependent on the fact that the server doesn’t keep any information about the issuing of certificates.
thanks for the explanation!
i’m not convinced much extra security is gained by this. it’s still visible that ip $foo send a message, and $user is logged in from $foo. if we believe that OWS do what they tell us :)