Hacker News new | past | comments | ask | show | jobs | submit login

"Also, there’s the issue of integrity. Google is still cooperating with the NSA and other intelligence agencies. PRISM is also still a thing. I’m pretty sure that Google could serve a specially modified update or version of Signal to specific targets for surveillance, and they would be none the wiser that they installed malware on their phones."

Isn't part of the reason that Moxie went with the Google Store is that he gets to sign the god damned binaries, making it impossible for Google to modify the app.




Hi, author here. Yes, my point with that sentence was that the average (non-technical) user (to which Signal is marketed btw), is not going to check signatures. Google has root on the phone, the user is using their app store to install the Signal app that comes up in the store, and basically Google has full control over this, and the user would be none the wiser.

Of course, us more technical inclined people could then check the signature, or compare the apk with one built from the official sources, to see the difference and complain about it.

But between those things is a time frame where this is possible.


Does it, actually?

I was under the impression that the Play Store doesn't run as root and the package manager API (controlled by the phone manufacturer) is what checks signatures. Can the Play Store override the signature checks on upgrade and if so, what codepaths is it using?


Just a quick look, but this is the PackageManager.java file:

https://android.googlesource.com/platform/frameworks/base/+/...

for the Android base framework. It has the checkSignatures() abstract definition and some other stuff that seems to be the API you talk about. Now this is all abstract, so some other party (maybe phone manufacturer, possibly others) must implement these methods to conform to the API. Could Google (or some other party) not just override the abstract implementation?

I find it hard to believe this is something only the phone manufacturer would have access to, not Google itself, given that Google has created the entire operating system basically, and is pulling more and more stuff from the AOSP into their proprietary apps (like Play services).


The subclass would have to be in the same process as the package manager (the system server) so it being abstract doesn't matter much.

Android doesn't rely so much on root vs non-root: it uses SELinux and lots of capability based security. Root is still there of course but out of the box, even the parts under remote OEM control don't run as root. If the OEM wants to change the basic rules of the system they must push a system update and get the user to agree to it. Of course a firmware update can change anything but outside of that I'm not convinced Google can just replace software at will.


Google has root on your phone. That is enough for them to replace any signatures, steal keys, replace apps without you knowing etc.


This. If Google controlling your phone via a remote backdoor is part of your threat model, you better start shopping for a different operating system anyway. That's not an issue with any particular Android app, it's an issue with Android.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: