4 ms·
Out of curiosity, would this allow Google to perform the signing _at the moment of download_? By that I mean, would it be possible that 2 different people down
by massung 5y ago
Out of curiosity, would this allow Google to perform the signing _at the moment of download_?
By that I mean, would it be possible that 2 different people download the app from the Play store, one of them gets an unmodified version of the app and the other (perhaps based on the user's race, country of origin, etc.) gets an on-the-fly modified version of the app.
The developer - and likely 99+% of all users - would never know or even be able to tell because most copies of the app in existence are 100% what the developer created. But, for a few rare birds, backdoors are aplenty.
Regardless, I'm 100% against this. But, my thinking above is this is possibly far worse than I initially imagined.
- Skunkleton 5y agoYes. But they could conceivably already modify Apps at install time or run time, so this is only a new vector for an existing attack.
- izacus 5y agoThe is pretty much the main stated reason for this approach - you'll get a customized bundle for your device which only carries native libs, languages and resources for your current configuration. It's explicitly stated as the main goal for this resigning. Apple calls this approach "app thinning". Also remember that Google Play Store could serve whichever APK it liked right now - the signing keys aren't surfaced in UI on Android (or iOS for that matter).
- dbrgn 5y agoThe keys aren't surfaced, but a TOFU (trust on first use) model applies. If a new APK is signed by a different signing key, the OS will reject the update. To my knowledge, the only way to force-install an update signed with a new signing key would be to uninstall-and-reinstall the app. (This is what "adb install -r" does.) This will result in the loss of all app data.