[_hyn3]

tldr: Google's new app bundle signing might be a precursor (well, almost certainly is) to Google's being able to replace parts of and modify your app on the fly when installed by certain targeted users or within certain targeted countries at Google's whim, with users being none the wiser.

Google might do this for a lot of reasons, and none of them seem to be good. FWIW, Google promises not to change the functionality of your apps.

Finally, it appears to be the intention that this will justify setting a new norm and become mandatory for all apps.

[chickenbane]

> Google might do this for a lot of reasons, and none of them seem to be good.

As a Play Store developer, I give Google the benefit of the doubt. By the way, before you assume a nefarious purpose, consider all Android phones connecting to the Play Store (by definition) have an auto-updating root process. Why does Google need to impersonate an application developer? This is fundamentally why Commonsware scare tactics don't resonate with me, the application has less privileges than the system and the app store, the calls are coming from inside the house!

But, there are more common and mundane reasons. Honestly, a lot of people lose their private signing key. And if that happens, no more updates to your app. By using App Signing, Google can help regenerate a key for you. They want to make this ability consistent across their whole store, that's why they're making the change.

They can also optimize the app bundle the device downloads from the store, as the store will know the target screen size, localization, CPU architecture, etc. The current workflow forces the application engineer to upload separate apk configurations. So this is also an improvement.

[e3bc54b2]

> a lot of people lose their private signing key. And if that happens, no more updates to your app

That is a feature. If someone cannot do basic diligence of protecting the signing key, should I really trust them for executing code on my machine?

[pmoriarty]

Wouldn't a simple solution to this be a double signing of one and the same app by both Google and the app's author?

That way, if Google changes the app and signs it, while the author only signed the unchanged app, then the author's signature would no longer validate on the new, changed app.

Or am I missing something?

[teraflop]

The whole point of this feature is to allow Google to modify the APK by stripping out unneeded resources to reduce file size. If you require both a signature from Google and a signature from the developer, the modified versions would not pass validation.

The issue is that this inherently requires users and developers to trust Google to only make innocuous changes.

[detaro]

If it's just "sign a thing, but allow some parts to be crossed out later while still being able to verify the signature", that's not that difficult to implement.

[jayd16]

This would completely change the signing structure but its feasible. Doesn't work for splitting files but maybe that's ok. I think BlackBerry would have you sign every file in a build but man was that a pain in the ass. It took forever for some reason.

[teraflop]

Right, to be more accurate I should have said that the feature as designed requires trusting Google.

[UncleMeat]

Not without changing the nearly unchangeable internals of the operating system. And it takes so long to get people to update to new OS versions that it'd be years before this could be deployed.

[pmoriarty]

"The whole point of this feature is to allow Google to modify the APK by stripping out unneeded resources to reduce file size."

Why couldn't Google just ask the developer to sign the modified app after Google makes its changes (which the developer should only do if they approve the changes)?

[UncleMeat]

PITA, most likely. More round trips. More complexity. More work for the user. It also means that the bundling process cannot be improved and you can't extend it to support new configurations without the involvement of the user. There are a bazillion locales and device configurations out there, with more created every day.

[simfree]

Why not let the developer generate the tailored binaries in the first place?

[UncleMeat]

In some cases, there are 100+ artifacts. I'd wager that far more developers care about the extra effort correctly splitting and signing a mountain of artifacts than the hypothetical threat model described in TFA. And Google probably would prefer the less error-prone method of doing it internally rather than risking devs doing it wrong and shipping broken apps to some device configurations.

[toast0]

Presumably the number of different app bundles is large. Otherwise, they could just ask for a apk with each configuration.

[zaphirplane]

Cause either you blindly sign it blindly or ??

[Godel_unicode]

You're not, this is absolutely the correct solution. There's no reason it needs to be either/or.

[jayd16]

What would be the point if Google's signature would still validate. If an author wants to share an app with a different signature outside the appstore they can.

[blihp]

I suspect this is more about Google asserting greater long-term control over apps in the store than anything else. If Google holds the keys it makes it harder, if not impossible, for an author to say 'no' to some unspecified future change(s). As an app developer having watched Google play this game over the last decade, I'd bet money on it.

[jayd16]

They probably just want to be able to patch in OS api compatibility shims so they can make faster changes.

For app bundles they want to be able to remove unneeded assets and make device specific builds. Think high dpi only. I think ios has a similar feature called app thinning.

[UncleMeat]

It isn't really new. The feature has been an option for like three years. Google is just now making it so all apps are distributed in this manner.

[nodamage]

Since Google already controls the Play Store, the Android operating system, and the Android SDKs, they can already do this regardless of how your app is signed.

[colineartheta]

Very curious to why you’re being downvoted. None of the other replies seem to give a good reason.