There are two legitimate concerns about Signal: they use real phone numbers as identifiers, and you have to trust Signal as the server operator as they don’t allow their client to be used with other servers. While the server software is also open source, you have to trust that they’re running the same version in production.
I agree; however, the second point I don’t see as Signal specific. In any service, how do you verify that a server is running unmodified open source code? For the vast majority of people, they are also depending upon the client being unmodified.
If you could run your own Signal instance, then that could help alleviate concerns of bad faith operators. That’s what Session is essentially (started as a fork of Signal): https://getsession.org
What security issues does Signal have?
There are two legitimate concerns about Signal: they use real phone numbers as identifiers, and you have to trust Signal as the server operator as they don’t allow their client to be used with other servers. While the server software is also open source, you have to trust that they’re running the same version in production.
I agree; however, the second point I don’t see as Signal specific. In any service, how do you verify that a server is running unmodified open source code? For the vast majority of people, they are also depending upon the client being unmodified.
If you could run your own Signal instance, then that could help alleviate concerns of bad faith operators. That’s what Session is essentially (started as a fork of Signal): https://getsession.org
With e2e encryption, you don’t need to trust the server, you only need to trust the clients.
@RandomBit I’m not aware of exactly what issues #Signal has, but I know it’s centralized so I’m not a big fan of that
Yes, it’s not ideal. Decentralized key distribution seems to be a intractable problem for mass adoption.