[mcintyre1994]

The article linked from this one is worth a read: https://commonsware.com/blog/2020/09/23/uncomfortable-questi...

They claim that because Google strips the developer signature and signs it themselves, they can modify the app and re-sign it. They suggest that an authoritarian regime could coerce Google into serving modified versions of eg. E2E encrypted messaging apps to people of that regime’s choice as a condition of doing business there.

Does anyone know if the iOS App Store has the same vulnerability? I know that they do clever things like universal apps and App Clips, but I’m not sure if they achieve it by stripping developer signatures and re-signing. Alternatively, since all signing certificates must be issued by Apple could they technically re-sign any app anyway if they’re coerced into holding onto the private keys they issue? I’ve never written an app in their ecosystem so I’m not sure exactly how it works or if they have an opportunity to do that.

[chedabob]

Apple issue the certificate but you never supply them with the private key. There's nothing stopping them from issuing a certificate with their own key though. It's not like Android where the signing key has to match otherwise apps can't be updated (amongst other things).

They must be doing some re-signing on their side because the binary you upload is huge and it goes through optimisation on Apple's side so the user has a much smaller download.

[lrem]

Do I understand correctly that Apple is already doing what Google wants to start doing here?

[chedabob]

They do something but it's not really comparable to Google's signing system. In the case of Google, developers voluntarily give Google the keys (or have them generated), and it's explicitly clear that Google will take your uploaded APK file and sign it themselves.

With Apple it's a big more of an unknown. In terms of Bitcode, I can't see how Apple could take your binary, "recompile" the Bitcode into a device specific format, whilst still preserving the signature.

From a 2 minute test of an iOS app I work on, I can see that what's downloaded on an M1 Mac has changed quite a bit from what I uploaded. The most obvious thing is the code signature on the binary itself has been replaced with one issued by Apple and isn't the one my build server added.

[ianlevesque]

> I can see that what's downloaded on an M1 Mac has changed quite a bit from what I uploaded. The most obvious thing is the code signature on the binary itself has been replaced with one issued by Apple and isn't the one my build server added.

So yes, Apple is already doing what Google wants to.

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