Their client is open source and is routinely audited. Their Android builds are fully reproducible. You can also build and run the app yourself if you want instead of downloading it from the app stores. It is virtually impossible for them to ship a backdoor, at least on Android, without the security community noticing.
What exactly prevents them from doing a Windows build with an non-published change, signing it with the keys they control, and pushing it to an individual client through the upgrade servers which they control?
Desktop clients communicate through mobile clients, so they don't have access to the key material.
I don't believe that is the case. You can turn your phone off and the Signal desktop client will continue to work just fine.
There is a window of vulnerability between a theoretically malicious update being pushed and the security community noticing that it doesn't correspond to a build of the published source. That might only be a few hours, or even minutes - but milliseconds would be enough to do most of its work.
Correct me if I'm wrong here -- let's say the Signal folks are breached or have been secretly waiting for just the right moment to push out some malicious code. How would they coordinate rolling it out to client devices to take advantage of that gap? I mean, depending on what the exploit was, they might be able to whack some percentage of users -- but it would be caught fairly quickly. I'm curious what sort of attack you're theorizing that would be worthwhile here.
> it would be caught fairly quickly
Noticing something and reacting to it are very different things. Signal could fairly trivially grab all historical data for all online users within a fairly limited window. However it would be a one off event so the value proposition of such an act is dubious.
> fairly trivially
Show your working otherwise this is utterly spurious.
What is complicated about having the local client upload its database to a remote endpoint? It's literally opening a network connection and proceeding to write out a database dump to it.
Anyway the difficulty of the task itself is traditionally taken to be irrelevant when performing cryptographic threat analysis. The question is about what is and is not mathematically impossible for an adversary to do.
What's especially frustrating about all of these "Signal could flip a switch and steal everybody texts!" histrionics is that if they were interested in doing that they... wouldn't work at Signal. They'd go join/start the hundreds of other companies we've heard of in the past few years that have stored/leaked incredibly sensitive data with an insignificant fraction of the effort Signal have put in to establishing their credibility (the TeleMessage scandal being just the latest). People should hold Signal accountable, constantly, forever. But the baseless FUD is frankly hysterical from a forum of ostensible technologists.
This comment does not follow the context of the discussion.
Circling back up. Article author: Twitter might be untrustworthy and could bruteforce your keys. Use Signal.
Me: That's unreasonable. You also have to trust Signal.
Your answer just now: Why are people picking on Signal?!?
In fact, what the world really needs, rather than 3rd-party controlled encrypted messaging solutions like Twitter and Signal, is public apis for public key cryptography on non-trusted infrastructure, not tied to single groups. Everybody knows this. The reason that we instead have bodies like Signal -- a company that just so happens to tie every encrypted message to a real phone number and real human identity for no easily explained reason -- and the reason we have people who surely know better defending bodies like Signal in public, is an exercise left for the reader.
They control the update servers. So it's possible to target a single user with a single build that no one else ever sees. What percentage of users verify every release?
In theory, Binary Transparency (https://binary.transparency.dev/) solves that among other things. To pass verification, an update has to prove that it's included in a public log of releases.
But I guess Signal doesn't implement it?
It's distributed in the Play Store, so Google controls the update servers, no?
Edit: or Apple, whathaveyou
Sure, but only if you are blindly auto installing every update as soon as it is pushed. All you have to do to protect yourself is download the bundle, run a checksum and then install it.
Then you audit and build it on your own? Or implement your own client?
No free lunch. If comms security is that critical for you, outsourcing its assurance via trust is never going to cut it.
How easy would it be for them to ship a backdoor on iOS? With Apple's DRM it should be difficult to decrypt the IPA and compare it to the source code.
If your HW/OS doesn't allow verification of binaries, but your threat model requires doing that, then you need to use proper HW/OS that allows the verification. Also, iOS is proprietary so who knows what the OS is doing anyway. Also, this https://thehackernews.com/2014/01/DROPOUTJEEP-NSA-Apple-iPho...
If you are in the EU you can build the app from source and sideload it on your phone. Everyone else is out of luck. So yeah, either Signal or Apple can insert a backdoor into the app.
> It is virtually impossible for them to ship a backdoor [..] without the security community noticing.
OpenSSH was trivially backdoor'd [1] and distributed in several major distributions and the security community _did not_ notice until after it was already wild.
[1] https://www.ssh.com/blog/a-recap-of-the-openssh-and-xz-liblz...
1) That was not "trivial", by any stretch of the definition. It was a 3-year long campaign by a (suspected to be) nation-state (or similarly resourced) actor! I don't think you can get any farther away from "trivial" if you tried.
2) From your link, it says: "Ubuntu 24.04LTS was a month away from being shipped with this backdoor, with other distros being on the same boat. Maybe the best way to describe it is this: had it gone undetected, Linux servers would have been running with a bomb waiting to be activated remotely." and "Luckily this backdoor was discovered in an early stage, and most of the Linux user community stays safe"
So, the security community _did_ notice.
That was an attack targeting an optional dependency that receives significantly less scrutiny than OpenSSH proper. Which to be fair, is probably also the most plausible path if you wanted to attack Signal.
I would quibble with calling it "trivial" though.