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