5 ms·
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 sig
by pmoriarty 6y ago
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?
- jayd16 6y agoWhat 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.
- Godel_unicode 6y agoYou're not, this is absolutely the correct solution. There's no reason it needs to be either/or.
- teraflop 6y agoThe 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.
- pmoriarty 6y ago"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)?
- zaphirplane 6y agoCause either you blindly sign it blindly or ??
- toast0 6y agoPresumably the number of different app bundles is large. Otherwise, they could just ask for a apk with each configuration.
- UncleMeat 6y agoPITA, 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 6y agoWhy not let the developer generate the tailored binaries in the first place?
- UncleMeat 6y agoIn 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.
- detaro 6y agoIf 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.
- teraflop 6y agoRight, to be more accurate I should have said that the feature as designed requires trusting Google.
- jayd16 6y agoThis 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.
- UncleMeat 6y agoNot 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.
- blihp 6y agoI 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.