[iudqnolq]

It's silly, because if you control the OS you control the app. They can push an OS or trusted app update that reads/writes the app's private data, or changes the shared libraries the app depends on, or with a little more work reads/writes the app's memory. Anyone claiming to provide protection from Google on a phone Google has remote root access to is selling a theatrical experience.

[thu2111]

Google do not control the signing keys for Android for any phones other than their own Pixel line. So whilst true in theory, in practice the open source nature of Android with OEMs in the middle distributes the power around.

[iudqnolq]

My impression is to implement things like the Play Store, Google Play Services has effective root access. I can't find any great sources for that though.

[chenxiaolong]

With older versions of Android, what Google could do was pretty limited (in terms of messing with the core OS). While Google Play Services has a lot permissions, it all fits into Android's permission model and does not run as root. Package installation is done via communication with the Android framework's PackageManager class and the corresponding /system/bin/installd daemon. Silent installations and automatic updates are also handled via PackageManager using a permission that system apps can obtain.

Overwriting most core OS files (eg. shared libraries) in a persistent way, even with an exploit, would be difficult since the entire /system and /vendor volumes are signed using the device manufacturer's dm-verity keys.

However, with Android 10+ shipping with APEX modules [0], Google's ability to push core OS changes to existing devices might be changing. I'm not sure if any devices ship with the unflattened (ie. updatable) type of APEX modules yet, but I'd suspect these would be signed by Google instead of the device manufacturer and would be distributed through Google Play.

[0] https://source.android.com/devices/tech/ota/apex

[altfredd]

This isn't about Google's control over OS. Of course, Google fully controls Android it, so they can compromise it anytime. But if such compromise gets detected, Google will lose trust.

The move away from developer signing towards Google's signing will makes it harder to detect such event.

[iudqnolq]

My argument is that a hypothetical compromise of an app never gives google more power than they could hypothetically have now. I also don't see why it would be harder to detect. Why do you think that's the case?

[altfredd]

This is a slippery slope fallacy. Your government has enough power to detain and execute you. Does that mean, that you should give them even more power?

Even if one OS component (Google Services) is centrally controlled and can be used to attack you, this does not mean, that you should make other parts less secure. Real-world attacks are complex and backdoors are fragile and prone to being detected. Embedding a backdoor in proprietary code of Google Services is easier than embedding it into AOSP. Hijacking a specific application is easier yet.