upvote
> 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…

reply
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".
reply
It's not shifting. It doesn't need to be the NSA, intelligence agencies are just, by far, the most likely attackers against Signal.
reply
It's not the identity of the agency that makes the argument so slippery!
reply
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.

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

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

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

reply
If you get an open source app from the App Store, is there any assurance it actually reflects the code in the repo? I’d think the signing step happening in isolation opens the door to tomfoolery.
reply