4 ms·

It is not. Google signs the parts of the app because apps are no longer one single APK, they're a complex set of many parts that can be updated independently an

It is not. Google signs the parts of the app because apps are no longer one single APK, they're a complex set of many parts that can be updated independently and in complex ways. The mobile ecosystem has moved on a lot since monolithic APKs and user expectations are too high for them to be sufficient.

RHSeeger 3y ago
That being said, the signing key is supposed to be "we certify this". Handing your key over to a 3rd party defeats that. If both <software producer> and google need to be able to sign it in some way, then the signing process should be enhanced to represent that. Maybe the software producer signs their individual components, and google signs the bundle, or something like that.
- danpalmer 3y ago
  I believe this is captured already – it's possible to verify that the binary was created by Google, but that it originated from the original developer.
- rvnx 3y ago
  The key your describe, is the developer key, Google checks it. The key that VLC is talking about, is the distribution key. Google manages the distribution key for you, one of the many reasons is because they create optimized APKs for each platform.
- wongarsu 3y ago
  Similar to how on Windows you sign both the installer and each binary that will be installed. In that setup it's trivial to have the binaries signed by one party, and the installer by another party.
- Turing_Machine 3y ago
  > Handing your key over to a 3rd party defeats that. Hmm... if Google went rogue, wouldn't everyone's Android phone basically be pwnt whether they had some dev's signing key or not?
treyd 3y ago
That may be true but begs the questions: * Why should developers being forced to use more complex multi-part distribution methods if they don't want to? * Why can't developers handle signing the multi-part packages themselves if they're comfortable doing so? (instead of relying on Google)
- sanitycheck 3y ago
  I've wondered this. For the apps I deal with, switching to AABs offered no benefit to anybody and a number of drawbacks to us. My usual theory about stuff coming out of Google is that there's a big incentive for changing stuff just to change stuff. Android seems to have become about as bad as JS is when it comes to the old "OK, let's try to get this 3-year-old app building with today's tooling" nightmare.
Hizonner 3y ago
> The mobile ecosystem has moved on a lot since monolithic APKs and user expectations are too high for them to be sufficient. As a user, I expect that software I run is protected from tampering. ... and there's no reason, other than laziness and "we know better than you do", that you can't define a manifest/asset signing format that supports that and supports incremental distribution of apps and doesn't demand giving the authentication keys for every single app to the distribution point.

RHSeeger 3y ago

That being said, the signing key is supposed to be "we certify this". Handing your key over to a 3rd party defeats that. If both <software producer> and google need to be able to sign it in some way, then the signing process should be enhanced to represent that. Maybe the software producer signs their individual components, and google signs the bundle, or something like that.

danpalmer 3y ago
I believe this is captured already – it's possible to verify that the binary was created by Google, but that it originated from the original developer.
rvnx 3y ago
The key your describe, is the developer key, Google checks it. The key that VLC is talking about, is the distribution key. Google manages the distribution key for you, one of the many reasons is because they create optimized APKs for each platform.
wongarsu 3y ago
Similar to how on Windows you sign both the installer and each binary that will be installed. In that setup it's trivial to have the binaries signed by one party, and the installer by another party.
Turing_Machine 3y ago
> Handing your key over to a 3rd party defeats that. Hmm... if Google went rogue, wouldn't everyone's Android phone basically be pwnt whether they had some dev's signing key or not?

treyd 3y ago

That may be true but begs the questions: * Why should developers being forced to use more complex multi-part distribution methods if they don't want to? * Why can't developers handle signing the multi-part packages themselves if they're comfortable doing so? (instead of relying on Google)

sanitycheck 3y ago
I've wondered this. For the apps I deal with, switching to AABs offered no benefit to anybody and a number of drawbacks to us. My usual theory about stuff coming out of Google is that there's a big incentive for changing stuff just to change stuff. Android seems to have become about as bad as JS is when it comes to the old "OK, let's try to get this 3-year-old app building with today's tooling" nightmare.

Hizonner 3y ago

> The mobile ecosystem has moved on a lot since monolithic APKs and user expectations are too high for them to be sufficient. As a user, I expect that software I run is protected from tampering. ... and there's no reason, other than laziness and "we know better than you do", that you can't define a manifest/asset signing format that supports that and supports incremental distribution of apps and doesn't demand giving the authentication keys for every single app to the distribution point.