Noise without Google Cloud Messenger (GCM)

[hpr]

it would be nice to publish an optional version of Noise / Signal without the Google Cloud Messenger proprietary blobs included.

i think these blobs are used to enable push notifications, so i can understand not making this a part of the default Noise install, because some people may want that. but for users which do not want to use these blobs and don't mind not having push notifications, it would be ideal to publish a version of the apk without these included.

[thestinger]

The code included in Signal is the client-side library for using Play Services. It doesn't do anything when Google Play Services isn't present.

Push notifications work perfectly well without Google Play Services installed and don't in any way depend on this library that's unused beyond checking for Play Services to discover that it isn't present.

I don't see any reason to expend effort removing this library. It would be extra maintenance for us and wouldn't have any real benefits. If it's not clear, we don't care one bit about software licensing, we care about privacy and security. This library doesn't add any significant real attack surface and is also included in Chromium.

Why should we bother with removing it from Chromium and Noise? You can audit it essentially just as easily as any open source code since it's Java, not native code.

[thestinger]

This tracker is only used for CopperheadOS and since we don't include Noise in CopperheadOS only asking about this for our Chromium builds is really in-scope here. I don't really see the point. The library isn't included in AOSP apps but you can see that it's used in a couple of the vendor apps if you look at their code since just because they aren't published as permissively licensed source code doesn't mean they can't be inspected and we've had to do that to debug various issues so we're quite familiar with some of their code already.

[hpr]

thanks for your response @thestinger. I think there would be no security issue if the library was never called, but it's the initial call to check for GPS that i think is the issue.

also, with fairness i think it's a little dishonest to say that auditing Java bytecode (not source files) is just as easy as any open source code, because i think bytecode is notoriously hard to audit -- that's why it's compiled from auditable source files to begin with.

i also don't think the problem with its inclusion in Copperhead is the license, it's the fact that it's bytecode from a third party (google) that is mandatory to be called in every app it's in, and it has not been audited by an independent party to my knowledge.

maybe auditing the called code could be another solution to this issue, but it seems like it would be easier to just remove it in the case where there are no google play services to begin with.

[thestinger]

also, with fairness i think it's a little dishonest to say that auditing Java bytecode (not source files) is just as easy as any open source code, because i think bytecode is notoriously hard to audit -- that's why it's compiled from auditable source files to begin with.

You don't audit it as bytecode, you can disassemble it to smali's bytecode representation or back to Java. You lose variable names and there are some trivial code simplifications like constant folding. No one is going to read Java bytecode as bytecode or machine code as machine code. It's disassembled or in the case of Java bytecode fairly easily converted back to Java unless it was obfuscated.

If it's minified with proguard, you lose variable names and many class / method names, but that doesn't change much in terms of auditing. Seeing the comments and naming of the developers lets you understand some of their reasoning, but that can lead to not seeing problems because you fall into the trap of making the same bad assumptions as the developers.

Proguard optimization isn't used by default because it takes a long time and isn't without risk of causing problems. As far as we can tell, it's not used for these apps. That would do more code transformations, etc. and would make the bytecode less representative of the source code but it's still very high level and closely tied to it anyway. It would just mean various things are inlined, etc. and it isn't actually used in practice anyway.

I don't see what's dishonest about understanding that there's a clear difference between compiled bytecode vs. native code in terms of difficulty of reversing it to something high-level.

[thestinger]

thanks for your response @thestinger. I think there would be no security issue if the library was never called, but it's the initial call to check for GPS that i think is the issue.

I don't understand why it's an issue. You can look at the code. This is a tiny amount of code in terms of the overall picture. If you're going to audit Chromium as a whole this stuff barely registers as significant. It doesn't matter that you need to run it through smali or a fancier disassembly tool first because it's such a tiny subset of the work that you'll need to do if you actually want to audit the entire thing. Sure, it might make it take 5% longer to do a comparable audit. I don't see a major issue.

[thestinger]

It's a client library, i.e. it's a tiny amount of code for proxying requests to services. It isn't a lot to audit, especially if you only care about the code that runs. You're asking us to do the work of maintaining a patch set against Chromium and Signal for zero benefit.

To be clear about something, Noise is not a fork of Signal and it no longer makes any changes to the Signal sources. It's not for usage outside CopperheadOS. It's not an app that we promote anywhere. It's simply a way to distribute Signal to CopperheadOS users via F-Droid. It isn't even part of CopperheadOS.

i also don't think the problem with its inclusion in Copperhead is the license, it's the fact that it's bytecode from a third party (google) that is mandatory to be called in every app it's in, and it has not been audited by an independent party.

You'll need to explain why there's any difference between Java bytecode vs. Java source code in terms of it being a problem, and I don't know how you can claim it hasn't been audited by an independent party. You don't know that, and you also don't know that the open source code has been audited by an independent third party.

[hpr]

i understand that bytecode disassemblers to smali / java exist and have used them to make changes to android apps myself, but i think it's dishonest to say that is auditable 'as easily as any other open source code' -- the argument to me is like saying minified and obfuscated javascript (which, despite having code available, is not open source) is as auditable as open source files (presumably the ones that the developers used).

source code audits of projects as large as chromium can and do happen with the right team, but the audits just don't happen with compiled code (whether native or bytecode or minified / obfuscated), because it's just too difficult to be practical.

i think the issue applies to chromium as well as noise, but my original issue was created for noise, and i figured it should go here because the issues link in metadata pointed to https://github.com/copperhead/noise/issues , which is disabled or doesn't exist.

[thestinger]

i understand that bytecode disassemblers to smali / java exist and have used them to make changes to android apps myself, but i think it's dishonest to say that is auditable 'as easily as any other open source code' -- the argument to me is like saying minified and obfuscated javascript (which, despite having code available, is not open source) is as auditable as open source files (presumably the ones that the developers used).

To be 100% clear, there's no obfuscation and they probably aren't even using proguard optimization. It's a small client library for checking if Play Services is usable and proxying the APIs to the services it provides. The client library doesn't really implement anything itself. Look at it.

The only one being dishonest here is you. I stated my informed, nuanced opinion on the subject. You can claim that I'm being dishonest by holding that opinion and misrepresent it. I'm not sure how you think claiming that I'm being dishonest is going to convince me to do what you want.

source code audits of projects as large as chromium can and do happen with the right team, but the audits just don't happen with compiled code (whether native or bytecode or minified / obfuscated), because it's just too difficult to be practical.

That's not at all true. Claiming that it's difficult to audit Java bytecode has no basis in reality. It's barely any harder than source code. If it was run through proguard, you're missing a lot of naming, but that isn't necessarily a bad thing for your audit. It's not native code where it's substantially harder to audit, but it's still quite doable and is regularly done. Sure, it's harder to just skim through the code and derive meaning based on assuming all the naming, comments, etc. are correct or to search around for some common pitfalls. I don't consider a light perusal of the code to be an audit.

i think the issue applies to chromium as well as noise, but my original issue was created for noise, and i figured it should go here because the issues link in metadata pointed to https://github.com/copperhead/noise/issues , which is disabled or doesn't exist.

Well, it doesn't, this is for CopperheadOS and Noise isn't part of CopperheadOS. Noise doesn't have an issue tracker because we don't make changes to the Signal code. Why would we need to handle issue reports? Feature requests would instantly be closed and the only kind of bug it could have would be a mistake in rebranding the strings like missing an instance of 'Signal' which isn't particularly important and I know there are some of those cases already and just don't care enough to fix them since I'm not going to rebrand the strings by hand.

[thestinger]

source code audits of projects as large as chromium can and do happen with the right team, but the audits just don't happen with compiled code (whether native or bytecode or minified / obfuscated), because it's just too difficult to be practical.

I look through the code of the proprietary apps all the time because I need to figure out how certain things are implemented or called. It's literally just reading the Java code without comments. If it's run through proguard, you're missing variable names and lots of class / method naming but I don't find that particularly important. Other programmers suck at naming things and I often get misled by those names when I'm reading sources. I can figure out what they're doing from the APIs they're calling and the strings just like source code.

If we were talking about an apk optimized to odex/oat files with the dex files stripped away, then sure, now you're in the territory of not having great tools to cope with it and yet... we somehow manage despite needing to reverse those.

I don't need to have someone telling me that I what I do on a regular basis is not possible / feasible. It makes no sense.