[stymaar]

> This is not true. I can build Signal from source from GitHub

Sure, but can you find an NSA-designed backdoor in the source code?

> you can get it once and disable autoupdates

Try doing that with Signal, and you'll be unable to connect to the main network in just a few days because you get out of sync. Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code?

What you describe may be possible for an intelligence agency, but completely out of reach for an individual.

> unless Apple is colluding with them

Given the most likely adversary is the US intelligence with a warrant, it's absolutely not far fetched to assume that in your threat model.

> you can at least be reasonably confident that it's not specifically backdooring only you

That's not really reassuring…

[tptacek]

Now the argument is shifting. It started out as "a cryptosystem can't be secured from the entity in control of its supply", and now it's "a cryptosystem can't be secured even given its source code because the NSA".

[stymaar]

It's not shifting. It doesn't need to be the NSA, intelligence agencies are just, by far, the most likely attackers against Signal.

[tptacek]

It's not the identity of the agency that makes the argument so slippery!

[stymaar]

Do you seriously think that the average Joe is able to find a backdoor, planted by anyone, in a piece of software they aren't familiar with?

Because that what quite literally the claim I was arguing with in the first place.

[tptacek]

I don't really agree with much of anything you've said in this thread, but the only thing I'm pointing out here is that your argument has shifted and is chugging heartily towards non-falsifiability.

[stymaar]

No the argument hasn't shifted. The core point is that any time you use a piece of software, you have to have some level of trust towards the entity that gave you the said piece of software.

The way I responded to one particular example “what if I download Signal and compile it myself” is just that a particular example, not a shift in argument.

If you think there's no trust assumption in the distribution of software, feel free to provide actual arguments to refute that argument of mine, because so far your comments have been disappointingly lacking in substance.

[subscribed]

>> This is not true. I can build Signal from source from GitHub

> Sure, but can you find an NSA-designed backdoor in the source code?

You're moving the goalpost. They were responding to the claim suggesting it's impossible to get non-Signal provided signal.

>> you can get it once and disable autoupdates

> Try doing that with Signal, and you'll be unable to connect to the main network in just a few days because you get out of sync.

That's demonstrably false. On one of my idle/backup phones I'm using Signal 8.8.2, released in April 2026, almost 3 full months ago. It can not only connect to the network but everything works, with every contact.

You might think of the official Signal client expiration, but that's client side (meaning that you can compile and use the version that doesn't have it) and..... 90 days, not "a few".

I don't have a concrete number for the server side of enforcement though (minimumVersions seems to be populated at start time, with the defaults not committed to the repo). It's not entirely unreasonable to assume that the lowest official supported version is the one that introduced the concept of usernames, and the only meaningful capability test is SPQR.

> Also, what do you do if there's a high severity CVE on the program? You still don't update or you re-audit all the new code?

I think disabling auto update was shown as a possible strategy against a silent, targeted auto update. Not a way to remain protected against the general CVEs.

Non sequitur.

[stymaar]

> You're moving the goalpost. They were responding to the claim suggesting it's impossible to get non-Signal provided signal.

That was never my claim. The claim is that you cannot protect youself from Signal being malicious if Signal is the maker of the software. Compiling the software yourself doesn't help against the kind of adversary in the threat model.

> That's demonstrably false. On one of my idle/backup phones I'm using Signal 8.8.2, released in April 2026, almost 3 full months ago. It can not only connect to the network but everything works, with every contact.

Lucky you, you only need to fully audit the codebase every 3 months.

I'm using the Signal apk directly so I'm painfully aware of the frequency of the breakages.

> I think disabling auto update was shown as a possible strategy against a silent, targeted auto update. Not a way to remain protected against the general CVEs.

I don't think you understand my point. I'm not talking about the CVE being exploited against you. The CVE will just push you to download the compromised update, breaking your “security through lack of update” policy.

[JacobKfromIRC]

Defense against Signal may not be total, but if you build from source (or use a reproducible build) you can check to be pretty sure you have the same software as everyone else, in which case a backdoor would have to be in a public version of Signal, which means any backdoor has a chance of getting discovered.

Backdoors can be well-hidden, but this is the kind of software that people look for vulnerabilities in [1]. This gives a lot less flexibility to any potential backdoor.

Additionally, someone could decide to write a new Signal client from scratch, designed to be compatible with the original server. Such a client would probably be less secure overall, at least at first, but it couldn't have a backdoor inserted by Signal developers, since it wouldn't contain any Signal code. Since the original client also supports end-to-end encryption, a new client can be compatible with old clients.

[1] https://community.signalusers.org/t/overview-of-third-party-...