@david_chisnall @guardianproject @signalapp @fdroidorg That's a perpetual myth that seems to have no basis in reality. The libraries in question have not been shown to be able to inject arbitrary code unless a malicious OS (which already has the capability to inject code into any program it hosts) has instructed them to do so.

(To be clear, this means on a Googled Android, you're just as vulnerable to Google's whims as you already were by running a Google OS, and on deGoogled Android you do not appear to be vulnerable.)

If this is incorrect, I'd like to see evidence.

Still I think on principle Signal should remove all Google code. There's no reason for it to be there and it hurts trust.

@dalias @guardianproject @signalapp @fdroidorg The libraries are arbitrary (binary) code provided by a third party. I'm not sure what you think is a myth.

@david_chisnall @guardianproject @signalapp @fdroidorg No, they're fixed code that contains exactly whatever code was there at the time Signal acquired and linked them in. Regardless of whether you have the source, this is analyzable, and if it doesn't have backdoor communication channels, the likelihood of harm is low even if you haven't done detailed analysis.

"Arbitrary code execution" would mean that they phone home to dynamically obtain code that Google could alter at any time to change the behavior after Signal shipped the app. That's the apparently false allegation folks are making about Signal.

@dalias @guardianproject @signalapp @fdroidorg

When you are making a claim of security as a result of being open source, the fact that that you allow someone else to provide a binary and then inject it into your final build is a problem.

I can only assume that you're arguing for the sake of arguing, rather than making a real point.

@david_chisnall @dalias @guardianproject @signalapp @fdroidorg

I see a real point challenging your overstatement. This doesn't strike me as arguing for the sake of arguing, but rather as correcting the myth of live code injection into signed builds.

This converts the original overstatement from "signal (and everything else?) will run arbitrary code downloaded at runtime" into "blobs are a risk".

This is a much less compelling and startling (headline-worthy) claim.

@tab2space @dalias @guardianproject @signalapp @fdroidorg

At no point did I say anything about arbitrary code downloaded at run time, I said that they could inject arbitrary code. That arbitrary code comes in the form of a blob that I strongly suspect Signal is not disassembling and auditing.

Now, possibly, they run Signal on some test environments with random Google accounts and monitor every network connection that it makes, MITM those connections via faked certs, and monitor the code that to see if it is detecting the MITM attack and see if any control flow diverges based on them.

But if they're doing all of that, then someone could do the same work with the Signal binary itself and being open source buys you very little in terms of security.

@david_chisnall @guardianproject @signalapp @fdroidorg No, I'm calling out bad faith criticism. Using closed source components from untrustworthy party X is a valid criticism. "Allows party X to inject arbitrary code" is a mischaracterization of that which serves an agenda (usually promoting scammy fake secure messengers).

@dalias @guardianproject @signalapp @fdroidorg

Okay, I am not going to argue any more. Allowing a third party to inject arbitrary code is literally what you do when you link a closed-source binary with no sandboxing.

If you think it's bad-faith criticism to state a fact, I am just going to mute you. Especially when you follow it up with 'usually promoting scammy fake secure messengers', which is something I was definitely not doing (and, if you pay attention to my previous posts, you'll see that I have encouraged people to use Signal rather than other things).

@david_chisnall @guardianproject @signalapp @fdroidorg I know it's not what you were doing, but I saw someone promoting threema in this same thread.

@geco_de @guardianproject @signalapp @threemaapp No.

@dalias It has nothing to do with the people behind Signal. But the Signal foundation is a US foundation. And it’s subject to the US law. And the Trump administration is converting the US system at least into an oligarchy if not worse.
Messengers under US law won’t be secure anymore. The only solution for the signal foundation is to leave the US and move at least to Canada as a safe harbour.
@guardianproject @signalapp @threemaapp

@geco_de @guardianproject @signalapp @threemaapp That's only the case if the promised security properties of the messenger that users are depending on admit subversion by the party who provided it. That's not the case with Signal. The only way they could subvert it is by denying availability (shutting the infrastructure down) or shipping malware in new versions of the application. They are not going to do the latter. Thinking they are is insulting to the people working on it and makes no sense. They have no reason to do that.

@geco_de @dalias @guardianproject @signalapp @threemaapp no jurisdiction is or will ever be 'a safe harbour'.

@AMDmi3 @geco_de @guardianproject @signalapp @threemaapp Indeed. This is not a problem solved by jurisdiction but by a combination of technical measures, trustworthy people, and transparency that make retroactive subversion impossible and forward subversion sufficiently difficult and obvious if done that there are no incentives for it.

@geco_de @guardianproject @signalapp @threemaapp the threema server is proprietary code. its a no-go for me. aaand we still have #matrix and or #xmpp for the rescue.

@growse @guardianproject @signalapp @fdroidorg That would be nice, but sadly, no. That APK contains proprietary libraries from Google and maybe others.

@ThePolishDispatch @guardianproject @signalapp @fdroidorg yes