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.
With ‘sealed sender’ your phone number, or any other identifying information, is not included in the metadata on the envelope, only the recipient’s id is visible, and it’s up to the recipient’s client to validate the sender information that is inside the encrypted envelope. It looks like a step in the right direction, though I don’t use signal enough to have looked into auditing it myself.
Again, this is a trust based system because you don’t know what the server is actually doing. The fact is that the server does collect enough information to trivially make the connection between phone numbers and the connections on the network. If trust me bro from Moxie is good enough for you, that’s of course your prerogative.
You’re correct that if you use the system the way it used to work they can trivially build that connection, but (and I know this is a big assumption) if it does now work the way they say it does, they do not have the information to do that any more as the client doesn’t actually authenticate to the server to send a message. Yes, with some network tracing they could probably still work out that you’re the same client that did login to read messages, and that’s a certainly a concern. I would prefer to see a messaging app that uses cryptographic keys as the only identifiers, and uses different keys for different contact pairs, but given their general architecture it seems they’ve tried to deal with the issue.
Assuming that you want to use a publicly accessible messaging app, do you have any ideas about how it should be architected? The biggest issue I see is that the client runs on your phone, and unless you’ve compiled it yourself, you can’t know what it’s actually doing.
Again, everything you say is based purely on faith. As you acknowledge, the design of the system is such that people operating the server can trivially build out graphs of user connections. All the same arguments people apply to no trusting server side encryption equally apply to metadata.
Meanwhile, there are plenty of examples of messaging apps that don’t require phone numbers. Matrix, Wire, SimpleX chat, are just a few examples. Being able to build your own client is also important, and there is a concept of reproducible builds which allows people to be reasonably sure that a binary being shipped is compiled from the source that’s published. These are solved problems, and there is no technical reason for Signal to do what it’s doing.
I agree that them having users’ phone numbers isn’t ideal. There are other identifiers they could use that would work just as well. However, both the client and server are open source, so you can build, at least the client, yourself. If you can content yourself that it does not leak your ID when sending messages, then you don’t need to trust the server as it does not have the information to build a graph of your contacts. Sealed sender seems to have been announced in 2018, so it’s had time to be tested.
Don’t get me wrong, the fact they require a phone number at all is a huge concern, and the reason I don’t really use it much, but the concern you initially stated was addressed years ago and you can build the client yourself to validate that.
Except that Signal won’t allow third party clients to talk to their server, and the server doesn’t federate. So, Signal being open source is completely meaningless in practice. If you want to use their network then you have to use the client they ship against the server they run, and only people operating this server actually know what it’s doing.
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 government can then know you use Signal. This may be problematic in heavily autocratic regimes, but besides those, what threat scenario are you arguing for here?
The Sealed Sender concept disallows building a social graph. However, you can utilize a VPN to mask your point of origin or, if necessary, even use a burner number.
Under the worst case scenario that the US gov takes over the whole AWS infrastructure and tries to correlate connections to users, there’s still very high information entropy. At that point, we’re talking about the US gov as a targeting threat actor. If that’s your opponent, you shouldn’t use everyday customer electronics or applications anyway. That’s some spy shit, even domestic activists won’t fall under that much scrutiny.
The government can know you use Signal, and know who your contacts are, and can correlate all the data they have on your and your contacts to see if any of it makes your whole group of contacts of interest. So, yeah it’s pretty concerning for people living in autocratic regimes like the US. Meanwhile, the sealed sender concept is just trust me bro because nobody aside from people who are actually operating the server know what it’s doing. The fact that people in this thread have so much trouble understanding that any data that gets leaked has to be assumed to be in the hands of a bad actor is phenomenal. Signal is proof that vast majority of people don’t understand the basics of privacy and security, and they don’t actually care. It’s just pure ideology for them.
I’d argue that this is part of the overall protocol design. The e2e encryption aspect of the protocol seems sound, but the system as implemented overall is problematic.
Looks like signal and email use both. but it still does not answer
AI said:
The server knows who initiated the communication (they handed over their lockbox first), but not the direction of individual messages within a conversation.
‘Sealed sender’ seems to avoid this by not actually requiring the client to authenticate to the server at all, and relying on the recipient to validate that it’s signed by the sender they expect from the encrypted data in the envelope. As I mentioned in another reply, 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 this issue.
With ‘sealed sender’ your phone number, or any other identifying information, is not included in the metadata on the envelope, only the recipient’s id is visible, and it’s up to the recipient’s client to validate the sender information that is inside the encrypted envelope. It looks like a step in the right direction, though I don’t use signal enough to have looked into auditing it myself.
Again, this is a trust based system because you don’t know what the server is actually doing. The fact is that the server does collect enough information to trivially make the connection between phone numbers and the connections on the network. If trust me bro from Moxie is good enough for you, that’s of course your prerogative.
You’re correct that if you use the system the way it used to work they can trivially build that connection, but (and I know this is a big assumption) if it does now work the way they say it does, they do not have the information to do that any more as the client doesn’t actually authenticate to the server to send a message. Yes, with some network tracing they could probably still work out that you’re the same client that did login to read messages, and that’s a certainly a concern. I would prefer to see a messaging app that uses cryptographic keys as the only identifiers, and uses different keys for different contact pairs, but given their general architecture it seems they’ve tried to deal with the issue.
Assuming that you want to use a publicly accessible messaging app, do you have any ideas about how it should be architected? The biggest issue I see is that the client runs on your phone, and unless you’ve compiled it yourself, you can’t know what it’s actually doing.
Again, everything you say is based purely on faith. As you acknowledge, the design of the system is such that people operating the server can trivially build out graphs of user connections. All the same arguments people apply to no trusting server side encryption equally apply to metadata.
Meanwhile, there are plenty of examples of messaging apps that don’t require phone numbers. Matrix, Wire, SimpleX chat, are just a few examples. Being able to build your own client is also important, and there is a concept of reproducible builds which allows people to be reasonably sure that a binary being shipped is compiled from the source that’s published. These are solved problems, and there is no technical reason for Signal to do what it’s doing.
I agree that them having users’ phone numbers isn’t ideal. There are other identifiers they could use that would work just as well. However, both the client and server are open source, so you can build, at least the client, yourself. If you can content yourself that it does not leak your ID when sending messages, then you don’t need to trust the server as it does not have the information to build a graph of your contacts. Sealed sender seems to have been announced in 2018, so it’s had time to be tested.
Don’t get me wrong, the fact they require a phone number at all is a huge concern, and the reason I don’t really use it much, but the concern you initially stated was addressed years ago and you can build the client yourself to validate that.
Except that Signal won’t allow third party clients to talk to their server, and the server doesn’t federate. So, Signal being open source is completely meaningless in practice. If you want to use their network then you have to use the client they ship against the server they run, and only people operating this server actually know what it’s doing.
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.
The government can then know you use Signal. This may be problematic in heavily autocratic regimes, but besides those, what threat scenario are you arguing for here? The Sealed Sender concept disallows building a social graph. However, you can utilize a VPN to mask your point of origin or, if necessary, even use a burner number. Under the worst case scenario that the US gov takes over the whole AWS infrastructure and tries to correlate connections to users, there’s still very high information entropy. At that point, we’re talking about the US gov as a targeting threat actor. If that’s your opponent, you shouldn’t use everyday customer electronics or applications anyway. That’s some spy shit, even domestic activists won’t fall under that much scrutiny.
The government can know you use Signal, and know who your contacts are, and can correlate all the data they have on your and your contacts to see if any of it makes your whole group of contacts of interest. So, yeah it’s pretty concerning for people living in autocratic regimes like the US. Meanwhile, the sealed sender concept is just trust me bro because nobody aside from people who are actually operating the server know what it’s doing. The fact that people in this thread have so much trouble understanding that any data that gets leaked has to be assumed to be in the hands of a bad actor is phenomenal. Signal is proof that vast majority of people don’t understand the basics of privacy and security, and they don’t actually care. It’s just pure ideology for them.
the protocol is secure, but privacy is this issue
I’d argue that this is part of the overall protocol design. The e2e encryption aspect of the protocol seems sound, but the system as implemented overall is problematic.
first comment to provide a decent counterpoint.
Looks like signal and email use both. but it still does not answer
AI said:
‘Sealed sender’ seems to avoid this by not actually requiring the client to authenticate to the server at all, and relying on the recipient to validate that it’s signed by the sender they expect from the encrypted data in the envelope. As I mentioned in another reply, 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 this issue.
same here overall. thank you for responding.