5 ms·

The title is misleading on a technicality though - Android will continue to deploy applications via APKs. Developers will have to upload apps as AppBundles, whi

by izacus 5y ago

The title is misleading on a technicality though - Android will continue to deploy applications via APKs. Developers will have to upload apps as AppBundles, which the Play Store service will repackage, resign and deliver to the devices as a set of APKs. Which means: the devices will continue to be able to install APKs. The major massive difference is that the apps will now be signed by Google on servers and not by developers on their local machines. I'm wondering why Google doesn't allow developers to build the optimizes APKs still - the Android build system does have that capability. Noone really used it, but it's there - there should be a way to opt out of signing key sharing.

techrat 5y ago
Yep. The end format is still APK. What is being dumped is the unnecessary libraries/APIs that are not relevant to the device that is receiving the APK. This doesn't affect sideloading in the slightest.
diegoperini 5y ago
One important distinction is that now Google is able to inject code to apps without notice since they are the ones who sign the final APKs.
- Someone1234 5y ago
  Google has always been able to do that. Just alter and re-sign the APK with their own key(s), since Google's keys are trusted by Google Play Services (third party app stores also trust Google's signing keys for compatibility reasons). The way the Play Store is currently designed, end users don't even have the ability to view the key-path before installing a package. So detecting if it is Google Vs. app developer's signing key is extremely unlikely without copying that APK off-device and inspecting it. All users know is: Is this using a signing key trusted by Google? Yay/Nay.
  - psykus 5y ago
    That's true for new installs at least. But Android won't let you install an update to an existing app with a different signing key, it'll error out with something generic.
    - UncleMeat 5y ago
      A threat model that only concerns updates and not new installs is incoherent.
      - Avamander 5y ago
        Less incoherent than a total lack of all chances to stop tampering though.
        UncleMeat 5y ago
        People are concerned about Google editing code, which would be detectable through the signed code section or just basic decompilation and would be a nightmare for PR. But people are apparently not concerned with 1. Nothing has ever prevented tampering with the signature before first install. 2. Google owns and writes the OS. 3. Libraries like WebView are both security critical and updated via ordinary app updates, and are provided by Google. 4. The dex bytecode isn't actually run on modern devices. Instead it is compiled into an executable by code owned by... Google. 5. The large majority of developers are using compilers and other tooling provided by Google. This is why the concern over this change is ludicrous. When you installed Signal or whatever for the first time did you check the signature? Did it bother you that it was technically possible for Play to substitute code? No. Because you are using an Android phone and trusting the OS developer is a requirement for everything. And there isn't a "total lack of chances to stop tampering", since the code section can still be signed with a different key. So why is everybody suddenly claiming a conspiracy here?
        Dylan16807 5y ago
        The main threat model is that google is influenced into editing a specific app or few for certain users or locations, not that the company is going to turn the entire OS into a backdoor. So most of your bullet points aren't very relevant. This threat model isn't a "conspiracy" either.
- ehsankia 5y ago
  Is that true if you use code transparency signing key? https://developer.android.com/guide/app-bundle/code-transparency https://developer.android.com/guide/app-bundle/code-transpar...
  - Avamander 5y ago
    Yes. > Important: The Android OS does not verify code transparency files at install time, and continues to rely on the APK signing schemes for verification of any installed APKs. It's pretty much useless because no-fscking-body is going to build a service to gather signatures from a bunch of devices in hopes to catch Google in the act.
deleted 5y ago
[deleted]
shaftway 5y ago
> I'm wondering why Google doesn't allow developers to build the optimizes APKs still > Noone really used it I think you answered your own question
- tut-urut-utut 5y ago
  How forbidding something that is not used makes sense? They could still let the people who want to produce their own optimized APKs and sign them with their key just do it as before, while defaulting to whatever they plan to do now.
cyanydeez 5y ago
not just signed, but now googles app not your app. this breaks trust and if anyone was trying to market a play store alternative, this and amazons store gives great marketing gristle.

by izacus 5y ago

techrat 5y ago

Yep. The end format is still APK. What is being dumped is the unnecessary libraries/APIs that are not relevant to the device that is receiving the APK. This doesn't affect sideloading in the slightest.

diegoperini 5y ago

One important distinction is that now Google is able to inject code to apps without notice since they are the ones who sign the final APKs.

Someone1234 5y ago
Google has always been able to do that. Just alter and re-sign the APK with their own key(s), since Google's keys are trusted by Google Play Services (third party app stores also trust Google's signing keys for compatibility reasons). The way the Play Store is currently designed, end users don't even have the ability to view the key-path before installing a package. So detecting if it is Google Vs. app developer's signing key is extremely unlikely without copying that APK off-device and inspecting it. All users know is: Is this using a signing key trusted by Google? Yay/Nay.
- psykus 5y ago
  That's true for new installs at least. But Android won't let you install an update to an existing app with a different signing key, it'll error out with something generic.
  - UncleMeat 5y ago
    A threat model that only concerns updates and not new installs is incoherent.
    - Avamander 5y ago
      Less incoherent than a total lack of all chances to stop tampering though.
      - UncleMeat 5y ago
        People are concerned about Google editing code, which would be detectable through the signed code section or just basic decompilation and would be a nightmare for PR. But people are apparently not concerned with 1. Nothing has ever prevented tampering with the signature before first install. 2. Google owns and writes the OS. 3. Libraries like WebView are both security critical and updated via ordinary app updates, and are provided by Google. 4. The dex bytecode isn't actually run on modern devices. Instead it is compiled into an executable by code owned by... Google. 5. The large majority of developers are using compilers and other tooling provided by Google. This is why the concern over this change is ludicrous. When you installed Signal or whatever for the first time did you check the signature? Did it bother you that it was technically possible for Play to substitute code? No. Because you are using an Android phone and trusting the OS developer is a requirement for everything. And there isn't a "total lack of chances to stop tampering", since the code section can still be signed with a different key. So why is everybody suddenly claiming a conspiracy here?
        Dylan16807 5y ago
        The main threat model is that google is influenced into editing a specific app or few for certain users or locations, not that the company is going to turn the entire OS into a backdoor. So most of your bullet points aren't very relevant. This threat model isn't a "conspiracy" either.
ehsankia 5y ago
Is that true if you use code transparency signing key? https://developer.android.com/guide/app-bundle/code-transparency https://developer.android.com/guide/app-bundle/code-transpar...
- Avamander 5y ago
  Yes. > Important: The Android OS does not verify code transparency files at install time, and continues to rely on the APK signing schemes for verification of any installed APKs. It's pretty much useless because no-fscking-body is going to build a service to gather signatures from a bunch of devices in hopes to catch Google in the act.

deleted 5y ago

[deleted]

shaftway 5y ago

> I'm wondering why Google doesn't allow developers to build the optimizes APKs still > Noone really used it I think you answered your own question

tut-urut-utut 5y ago
How forbidding something that is not used makes sense? They could still let the people who want to produce their own optimized APKs and sign them with their key just do it as before, while defaulting to whatever they plan to do now.

cyanydeez 5y ago

not just signed, but now googles app not your app. this breaks trust and if anyone was trying to market a play store alternative, this and amazons store gives great marketing gristle.