3 ms·

> My understanding is that Google really wants to manage your keys so that you can't really mess up. It's not just this, apps are now delivered as many separat

> My understanding is that Google really wants to manage your keys so that you can't really mess up. It's not just this, apps are now delivered as many separate parts so that a device only gets what it needs. In the age of ARM/ARM64/x86, varying DPIs, different graphics abilities, etc, it can be easy for most users to not need most of an app. Google generates all these pieces from the "bundle", and picks optimal sets for each user/device. This could be potentially managed by users (it's all based on bundletool, an open source project), but there's a lot more on top of this, dynamic pieces that Google can generate on-demand for apps for various app health/security/product features. This only works if Google can sign the pieces.

ndriscoll 3y ago
If the distributor (Google) has the signing keys, why not just... not sign it? What does signing give you that TLS doesn't? Why can't Google sign the app with its own keys without the author having a say? The entire point of signatures is that users can trust their download is what the author published because they're the only one who could produce that signature.
- Hizonner 3y ago
  > What does signing give you that TLS doesn't? A huge number of replicated servers have to have access to TLS keys, and a huge number of people have to be involved in the administration of those servers. And, to rely on TLS, you have to assure the integrity of the data within the whole store infrastructure, not just at the point that a file gets injected into it. The practical exposure is vastly worse than with end to end signing.
  - ndriscoll 3y ago
    I suppose that's fair. Still, can't the play store app just always accept a Google signed package (possibly from a root CA that doesn't get used for other purposes)?
- denysvitali 3y ago
  If you don't have a way to validate the key ownership, you're at the same starting point: you have to trust Google
Izkata 3y ago
They also strongly recommend compatibility packages to handle different versions of Android (it's basically required to handle notifications), but those add a crazy amount of crap that doesn't get removed during the build, even if whole features are unused. It wouldn't surprise me if Google does remove those during their optimizations when they build it for you.

ndriscoll 3y ago

If the distributor (Google) has the signing keys, why not just... not sign it? What does signing give you that TLS doesn't? Why can't Google sign the app with its own keys without the author having a say? The entire point of signatures is that users can trust their download is what the author published because they're the only one who could produce that signature.

Hizonner 3y ago
> What does signing give you that TLS doesn't? A huge number of replicated servers have to have access to TLS keys, and a huge number of people have to be involved in the administration of those servers. And, to rely on TLS, you have to assure the integrity of the data within the whole store infrastructure, not just at the point that a file gets injected into it. The practical exposure is vastly worse than with end to end signing.
- ndriscoll 3y ago
  I suppose that's fair. Still, can't the play store app just always accept a Google signed package (possibly from a root CA that doesn't get used for other purposes)?
denysvitali 3y ago
If you don't have a way to validate the key ownership, you're at the same starting point: you have to trust Google

Izkata 3y ago

They also strongly recommend compatibility packages to handle different versions of Android (it's basically required to handle notifications), but those add a crazy amount of crap that doesn't get removed during the build, even if whole features are unused. It wouldn't surprise me if Google does remove those during their optimizations when they build it for you.