zlacker

> The security rests only upon the open source client code. The server is completely orthogonal to security.

For Android at least, builds are reproducible https://signal.org/blog/reproducible-android/ (would be neat if there was one or more third party CI's that also checked that the CI-built app reproduces the one on Google Play Store – or maybe there already are?)

>>unhamm+(OP)
That's pretty neat, I wasn't aware that was possible.

>>unhamm+(OP)
While I find laudable this effort and consider it a valid security improvement, the fact that Signal is opposed to alternate clients (and even builds from other sources like FDroid) opens another orthogonal risk.

I doubt that many people rebuild the app at each update to check that the new binaries match the ones provided by their store. If, for example, the PlayStore distributed at large a binary that doesn't match the published sources, some dedicated user would probably spot the issue.

However, the PlayStore (and Signal, but it's not even necessary for the following) being under US jurisdiction, any user not checking each update it receives is vulnerable to the NSL + gag order famous combo in case of a targeted attack. I recognize that this is probably something that most people do not include in their threat model but I'm still a bit dubious about the fact that convenience related to release management and not having to worry about interoperability is worth accepting the risks linked to a unique delivery channel, especially for what could (and is widely thought to) be a completely secure IM solution. "Almost secure" is frighteningly the worse obstacle to "secure"...

I'm admittedly biased since I'm convinced that federation, multiple client/server implementations and multiple distribution channels are a requirement for a secure IM infrastructure (which is why my heart goes to Matrix nowadays).