On its 10th anniversary, Signal’s president wants to remind you that the world’s most secure communications platform is a nonprofit. It’s free. It doesn’t track you or serve you ads. It pays its engineers very well. And it’s a go-to app for hundreds of millions of people.
I’m talking about the information the server has. The encrypted envelope has nothing to do with that. Your register with the server using your phone number, that’s a unique identifier for your account. When you send messages to other people via the server it knows what accounts you’re talking to and what their phone numbers are.
Whilst I absolutely agree it’s correct to be skeptical about it, the ‘sealed sender’ process means they don’t actually know which account sent the message, just which account it should be delivered to. Your client doesn’t even authenticate to send the message.
Now, I’m just going on what they’ve published on the system, so either I could be completely wrong, or they could be being misleading, but it does look like they’ve tried to address the very issue you’ve been pointing out. Obviously it’d be better if they didn’t have your phone number at all, but this does seem to decouple it in a way that means they can’t build a connection graph.
The problem is that there is no way to verify any of this. You’re just putting trust into people operating this service. That’s not how security is supposed to work.
Strictly you’re having to trust the build of the client rather than the people running the server. If the client doesn’t send/leak the information to the server, the people running the server can’t do anything with it. It’s definitely still a concern, and, if I’m going to use a hosted messaging app, I’d much rather see the client built and published by a different group, and ideally compile it myself. Apart from that I’m not sure there’s any way to satisfy your concerns without building and running the server and client yourself.
I’m talking about the information the server has. The encrypted envelope has nothing to do with that. Your register with the server using your phone number, that’s a unique identifier for your account. When you send messages to other people via the server it knows what accounts you’re talking to and what their phone numbers are.
Whilst I absolutely agree it’s correct to be skeptical about it, the ‘sealed sender’ process means they don’t actually know which account sent the message, just which account it should be delivered to. Your client doesn’t even authenticate to send the message.
Now, I’m just going on what they’ve published on the system, so either I could be completely wrong, or they could be being misleading, but it does look like they’ve tried to address the very issue you’ve been pointing out. Obviously it’d be better if they didn’t have your phone number at all, but this does seem to decouple it in a way that means they can’t build a connection graph.
The problem is that there is no way to verify any of this. You’re just putting trust into people operating this service. That’s not how security is supposed to work.
Strictly you’re having to trust the build of the client rather than the people running the server. If the client doesn’t send/leak the information to the server, the people running the server can’t do anything with it. It’s definitely still a concern, and, if I’m going to use a hosted messaging app, I’d much rather see the client built and published by a different group, and ideally compile it myself. Apart from that I’m not sure there’s any way to satisfy your concerns without building and running the server and client yourself.
The problem is that a phone number is required to make an account, and that’s a unique identifier for each person using Signal.