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