4 ms·

> Point being: the app is unmodified. Even with Google doing the signing. The difference is that you used to be able to verify that Google didn’t modify the ap

by Aaargh20318 5y ago

> Point being: the app is unmodified. Even with Google doing the signing. The difference is that you used to be able to verify that Google didn’t modify the app. They simply couldn’t make a change while keeping the signature intact. Now they can, they just say they won’t and expect you to trust their word.

eganist 5y ago
> Now they can, they just say they won’t and expect you to trust their word. In theory this can be verified by the developer though? Signing an app shouldn't (I haven't checked this in Google's case) change any integrity values for the app code itself, so the developer (though no one else) is still able to ensure Google wouldn't have tampered anything. But your point makes sense.
- lazide 5y ago
  The reason they are doing this (keeps getting buried) is because they want to change distributed APKs, shims, etc. so they have the right packages and deps per device, and can ensure that what they build is what is accepted on the device and not some other random thing. So it is working as intended if what is installed on some device is not what the Dev built.
  - GauntletWizard 5y ago
    This still represents a foundational change to the android model, and there are better ways of doing so. The simplest (which requires no changes) of Google to asking you to sign a few dozen different versions of your app for different models. That idea is easy to reject because it would be "too cumbersome" and require re-uploading the same app package repeatedly, but it would work. There are other models that Google could adopt to allow this functionality. Google could come up with a new app format whereupon there were a signed manifest of files, and Google could selectively leave some out (Git does something very similar: The commit includes a map of filenames to cryptographically-secure object IDs, which may be in one of many different packfiles). This would allow Google to strip the assets that are unnecessary for your device, while still giving the Developer control over what's shipped. But more importantly: This is about control. Currently there's a nice check-and-balance system. The developer signs the package, and Google inspects and can choose not to distribute it. The new system gives all the control to Google; They sign, they distribute. This may have been effectively where the system was before, because only a sparse minority of users checked the developer keys directly, but there's a big leap between the trust being defacto with Google (because people trust them and don't check), and that trust being completely with Google (because there's no way to check, Google holds all the keys). I do trust Google to distribute my app. I trust them where I can check their work. I trust them because I can check their work. I know there would be outrage if they started distributing things that were not what I signed. This is that outrage.
    - kion 5y ago
      > "too cumbersome" and require re-uploading the same app package repeatedly, but it would work. This is true and "too cumbersome" is worth expanding on. Without specific targeting what is delivered to the device, 100s of MB of storage can be wasted after the APK is uncompressed. The data that is unused can't be deleted but is unusable or unneeded on that device. When specifically targeting a single device you have multiple axes to target: * 4 native CPU architectures: [x86, x86_64, armeabi-v7a, arm64-v8a] * resource DPIs: [ldpi, mdpi, hdpi, xhdpi, xxhdpi] * 6+ SDK targetSdks with meaningful feature variances (basically potential features enabled/disable every year for the last 7-8 years). * 80+ individual languages If the goal is to exactly match the device/user in question, you'd need to generate and apply appropriate versionCodes for: 4 * 7 * 6 * 80 = 13440 individually, versioned, signed and uploaded APKs. Of additional note, the versionCodes must be precisely ordered to ensure the right version is selected. A device will get the highest version which is compatible with the device. So if an x86 version is higher than x86_64 a 64 bit device that can handle both will still get the x86 instead of the x86_64 version. Same goes for DPI ordering and SDK ordering.
    - Aaargh20318 5y ago
      > The simplest (which requires no changes) of Google to asking you to sign a few dozen different versions of your app for different models. That idea is easy to reject because it would be "too cumbersome" and require re-uploading the same app package repeatedly, but it would work. I used to do J2ME app development back in the day. It wasn’t unusual for our apps to have 200+ builds. These weren’t just different assets, they also included workarounds for device specific bugs (j2me phones were buggy as hell, especially Samsung phones). In some cases we even had multiple builds for one phone, because carriers liked messing with the firmware. Vodafone was notorious for this. When Android and iOS took over we finally could leave that behind, at least for a while, then Android started fragmenting like crazy and now we’re almost back to square one.
    - UncleMeat 5y ago
      > a few dozen different versions I think you are underestimating the number of versions. And why would developers want to do this? This adds a huge pain in the ass to all deployments. > Google could come up with a new app format whereupon there were a signed manifest of files They could. But this wouldn't be backwards compatible. So you are stuck waiting like eight years for the ecosystem to all adopt the new OS versions.

eganist 5y ago

> Now they can, they just say they won’t and expect you to trust their word. In theory this can be verified by the developer though? Signing an app shouldn't (I haven't checked this in Google's case) change any integrity values for the app code itself, so the developer (though no one else) is still able to ensure Google wouldn't have tampered anything. But your point makes sense.

lazide 5y ago
The reason they are doing this (keeps getting buried) is because they want to change distributed APKs, shims, etc. so they have the right packages and deps per device, and can ensure that what they build is what is accepted on the device and not some other random thing. So it is working as intended if what is installed on some device is not what the Dev built.
- GauntletWizard 5y ago
  This still represents a foundational change to the android model, and there are better ways of doing so. The simplest (which requires no changes) of Google to asking you to sign a few dozen different versions of your app for different models. That idea is easy to reject because it would be "too cumbersome" and require re-uploading the same app package repeatedly, but it would work. There are other models that Google could adopt to allow this functionality. Google could come up with a new app format whereupon there were a signed manifest of files, and Google could selectively leave some out (Git does something very similar: The commit includes a map of filenames to cryptographically-secure object IDs, which may be in one of many different packfiles). This would allow Google to strip the assets that are unnecessary for your device, while still giving the Developer control over what's shipped. But more importantly: This is about control. Currently there's a nice check-and-balance system. The developer signs the package, and Google inspects and can choose not to distribute it. The new system gives all the control to Google; They sign, they distribute. This may have been effectively where the system was before, because only a sparse minority of users checked the developer keys directly, but there's a big leap between the trust being defacto with Google (because people trust them and don't check), and that trust being completely with Google (because there's no way to check, Google holds all the keys). I do trust Google to distribute my app. I trust them where I can check their work. I trust them because I can check their work. I know there would be outrage if they started distributing things that were not what I signed. This is that outrage.
  - kion 5y ago
    > "too cumbersome" and require re-uploading the same app package repeatedly, but it would work. This is true and "too cumbersome" is worth expanding on. Without specific targeting what is delivered to the device, 100s of MB of storage can be wasted after the APK is uncompressed. The data that is unused can't be deleted but is unusable or unneeded on that device. When specifically targeting a single device you have multiple axes to target: * 4 native CPU architectures: [x86, x86_64, armeabi-v7a, arm64-v8a] * resource DPIs: [ldpi, mdpi, hdpi, xhdpi, xxhdpi] * 6+ SDK targetSdks with meaningful feature variances (basically potential features enabled/disable every year for the last 7-8 years). * 80+ individual languages If the goal is to exactly match the device/user in question, you'd need to generate and apply appropriate versionCodes for: 4 * 7 * 6 * 80 = 13440 individually, versioned, signed and uploaded APKs. Of additional note, the versionCodes must be precisely ordered to ensure the right version is selected. A device will get the highest version which is compatible with the device. So if an x86 version is higher than x86_64 a 64 bit device that can handle both will still get the x86 instead of the x86_64 version. Same goes for DPI ordering and SDK ordering.
  - Aaargh20318 5y ago
    > The simplest (which requires no changes) of Google to asking you to sign a few dozen different versions of your app for different models. That idea is easy to reject because it would be "too cumbersome" and require re-uploading the same app package repeatedly, but it would work. I used to do J2ME app development back in the day. It wasn’t unusual for our apps to have 200+ builds. These weren’t just different assets, they also included workarounds for device specific bugs (j2me phones were buggy as hell, especially Samsung phones). In some cases we even had multiple builds for one phone, because carriers liked messing with the firmware. Vodafone was notorious for this. When Android and iOS took over we finally could leave that behind, at least for a while, then Android started fragmenting like crazy and now we’re almost back to square one.
  - UncleMeat 5y ago
    > a few dozen different versions I think you are underestimating the number of versions. And why would developers want to do this? This adds a huge pain in the ass to all deployments. > Google could come up with a new app format whereupon there were a signed manifest of files They could. But this wouldn't be backwards compatible. So you are stuck waiting like eight years for the ecosystem to all adopt the new OS versions.