> You can sign those with your own key, but then you need to share your private upload key to keep compatibility. Or you don't share it and Google signs it with a new key, leaving old devices behind.
I don’t get it: app can’t be updated if signed with a new key? Given that apps are sold all the time, and developers sometimes lose private keys themselves, this makes no sense.
> I don’t get it: app can’t be updated if signed with a new key?
That's correct.
> Given that apps are sold all the time,
I'm pretty confident that in 90%+ of those cases, developers just sell the signing keys with it.
FWIW, Android does have a mechanism to upgrade keys (app signed with the old key contains in its metadata the new key saying that this key is okay) since like 4-5 years ago. But I expect very few people use that. (I don't even know whether Google Play Store allows using this)
> and developers sometimes lose private keys themselves, this makes no sense.
I guess they don't when their revenue relies on it?
In fact most of the developers do not manage the key themselves but instead use the default option: let Google generate and store one signed distribution key for you.
This is the key that is used by the devices to verify that the APK can be installed on top of another.
If an APK was signed by "Key A", only "Key A" can do updates.
One advantage of that, is that malicious users cannot be served a malicious update of an app that didn't go through Play Store.
Let's imagine it's the opposite, that France for example wants to spy on some users ?
Other advantage, is that if you lose your developer private key, then you do not lose the capacity of doing updates.
The minus of that, is that you have to count on Google to sign every single of your APKs.
If they do not trust Google, VLC can add a checksum or integrity checks to the binaries loaded by the app during runtime.
> This is the key that is used by the devices to verify that the APK can be installed on top of another.
Given that one option here is to let Google sign with a new key and keep things updated (dropping support for old devices in the process), this seems like a policy limitation, not an Android technical limitation?
> One advantage of that, is that malicious users cannot be served a malicious update of an app that didn't go through Play Store.
And the disadvantage of that is that it is almost impossible to patch APKs on your own without running into serious issues, even as root - particularly when the app you're trying to patch has shared permissions with other apps of the same developer.
Is the Android and iPhone VLC app similar? The MacOS and Windows versions are completely different, I didn't know that and wanted to export my settings to match and MacOS has way fewer features.
Yes I have. The apps are completely different. They don't even look remotely the same, the tool bars and media library etc are all different. I have to look for a ton of stuff that I know exactly where it is in Windows.
There is specifically no zoom with the rectangle box that Windows has and many other things. There IS a "Zoom" but it's not the same at all and just modified window sizes. And I can't import my Windows VLC settings like I thought I would.
I have tons of shortcuts, etc already assigned on my Windows end. This pissed me off because I spent a lot of time getting my VLC settings how I want them thinking I would just import them into my macbook.
There's not even a way to import or export MacOS VLC's own settings.
The only scenario that comes to mind would be Google repackaging a build after some subtle changes, signing it and sending to a lawful intercept target. Are there other cases where the developer does not sign the package aside from selling the package to Google?
Interesting. Do Apple then submit their optimized diffs to the developer and have them uptake the changes so the source is optimized? Or would the developer have to de-compile the artifacts and reverse engineer the optimizations to see what was changed, added or removed? It seems like this would make attestation and audits challenging for apps used by b2b financial customers.
I would imagine that this is similar to the same shared security model that you would use within AWS and other Cloud Providers. At some point you have to point to their documentation and how they do things as being out of your control but possibly audited on its own. But if you are really worried for iOS it is optional.
I don't see any capabilities regarding your first question outside of testing specific devices through TestFlight, but I would think it is fairly safe to assume that Apple has put a lot of work into making sure this works consistently between devices.
It is also entirely possible that, like working with Cloud Providers, that there is a difference between what normal users can do and what can be done with NDA's and other contracts signed.
Google takes the bundle, and builds a bunch of binaries for different architectures & device OS versions. The changes aren't subtle, they delete things the user's device doesn't need and sign the result. E.g. if the user has a 32-bit ARM device they'll delete 64-bit ARM code from the bundle when building the binary, and likewise for the reverse. That saves users both mobile data and storage space.
I faced a similar issue: it seems like it has now become close to impossible to use your own signing / release key.
My understanding is that Google really wants to manage your keys so that you can't really mess up. If your app has a lot of users and you lose the signing key, IIRC you'll cause an outage due to the fact that existing users will not be able to update the app without uninstalling it and re-installing it, causing data loss.
I'd love to be corrected, as there might be some key rotation procedure in place that I'm unaware of. In any case, even if you owned the signing key, no one could theoretically stop Google from providing an APK signed with another key to the PlayStore users, since at first install the apps trust whatever key you provide (and the only cross-check I'm aware of is, well, Play Protect, also owned by Google)
> 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.
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.
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.
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)?
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.
Also means any user can be selectively targeted with a compromised app signed by the correct key.
If you use pretty much anything other than Linux (and even that with care) there is a rather long list of people who effectively have root on all your stuff.
Maybe this can’t be avoided. Economies and civilizations run on division of labor and interdependency. I just think it’s important that people understand this. Most people don’t and think they have far more digital security and privacy than they do.
Disabling auto-updates is a controversial but nice way to prevent backdoors from getting added, or for software to turn becoming malicious.
For example, Chrome extensions, it's crazy that a random guy, can automatically update its piece of JS, just to steal all credentials, and there is no mechanism to disable that (or very well hidden) (like what happened with "The Great Suspender", though it was a great extension)
It's not clear that the vendors will respect that when the going gets tough, or that they don't have "no just force the update" channels. I think Apple has done that, for instance.
> My understanding is that Google really wants to manage your keys so that you can't really mess up.
Instead, Google can really mess up. Which they will do somewhat less often than your average app developer, but when they do do it, it will break everything.
> I'd love to be corrected, as there might be some key rotation procedure in place that I'm unaware of. In any case, even if you owned the signing key, no one could theoretically stop Google from providing an APK signed with another key to the PlayStore users, [...]
Only on new installs, which is a much smaller window than being able to change the app on every update.
"Google" in the large, of course, also has a lot of paths to modify the OS and everything that's validating the signatures... but that's a different part of Google, and that risk does not justify this one.
> If your app has a lot of users and you lose the signing key, IIRC you'll cause an outage due to the fact that existing users will not be able to update the app without uninstalling it and re-installing it, causing data loss.
Half right: it means you can't publish updates under the same package name. They can continue using the old version, so it doesn't force any sort of data loss, but if they want to upgrade they have to find the new app, it won't be a reinstall-the-same-one situation.
Not to be the devil's advocate but how is just a signing key for an Android app/developer that is used for signing APKs and bundles comparable to "keys to your bank account"?
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.
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.
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.
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.
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.
> 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.
It's an over-simplification of course, and probably won't be true once proper attestations are in place. Problem: unless you're using GrapheneOS-style hardware attestations, the main attestation solution (Play Integrity) is signed by the same entity (Google) that signs the app bundles…
No one explained it in any other comment (yet), so here is the idea:
Google owns your bank's app signing key, which means that they can craft any update for your banking app in a way that it makes it leak the content of your application data. In the case of a bank, this might contain sensitive information: but not necessarily the password / token that is used to access your account as this might be stored in a more secure place like the HW-backed keystore.
Nevertheless, if they have a way to modify your banking app binary without you noticing - they technically have access to your bank account (to the same level the app has).
Would Google ever do this? Probably not, but the risk of a key compromise by a rogue employee is still there.
Is this risk higher than your bank leaking the key? It depends, hopefully the person who has access to Google HSMs is not the same that has the rights to create a new release on the Google Play Store.
The biggest issue I personally see is that we're putting so much trust in Google to basically control all of your apps - but that's sort of already happening on Android because people are generally running Google-flavored Android builds which have privileged Google Play Services.
You don't have to use the Google Play store, other app stores and side-loading are available, so there is still freedom in Android, but not so much in Google Play.
In other words, Android gives access to multiple curated app stores, and side-loading. Whilst I understand that Apple only allowed use of apps from their own store until the EU stepped in, and now they have an EU-available update that allows side-loading.
Android is not the same thing as the Play Store. As far as I can tell, every Android user has the option to enable the installation of 3rd party software (though I could be wrong here, since my experience is with phones/tablets and not other Android based devices). When you deal with the Play Store, you are dealing with the store's policies rather than a limitation of the Android platform.
The freedom, such as it is, comes from alternative app stores. I trust F-Droid (https://f-droid.org/) somewhat more than I trust apps on the Play Store so that's my first stop when I'm looking for something.
Google Play has started to hijack apps installed from Fdroid. As the keys don't match the upade fails and is stuck in the updates available notification. In essence breaking manual check for updates, because the button to check for update is the same as show updates.
"not really, it would just leave users behind, which is what they are trying to prevent. And the f-droid versions are built (from source) and signed by f-droid, not VLC."
What's the point of Google asking for other people's private keys? That's not how asymetric encryption scheme are supposed to be used! Google could sign packages with their own keys, I don't see what they gain from having videolans' keys, except to impersonate them (which is fishy).
It's also tangentially related to the app archiving feature of Android 15, which in order to retain backward-compatibility, replaces the full APK by a shim that you can simply open to initiate the app redownload. This allows to keep the existing local app storage in place. You cannot replace the original APK by another one unless the signatures of both matches.
62 comments
[ 0.23 ms ] story [ 122 ms ] threadI don’t get it: app can’t be updated if signed with a new key? Given that apps are sold all the time, and developers sometimes lose private keys themselves, this makes no sense.
That's correct.
> Given that apps are sold all the time,
I'm pretty confident that in 90%+ of those cases, developers just sell the signing keys with it.
FWIW, Android does have a mechanism to upgrade keys (app signed with the old key contains in its metadata the new key saying that this key is okay) since like 4-5 years ago. But I expect very few people use that. (I don't even know whether Google Play Store allows using this)
> and developers sometimes lose private keys themselves, this makes no sense.
I guess they don't when their revenue relies on it?
This is the key that is used by the devices to verify that the APK can be installed on top of another.
If an APK was signed by "Key A", only "Key A" can do updates.
One advantage of that, is that malicious users cannot be served a malicious update of an app that didn't go through Play Store.
Let's imagine it's the opposite, that France for example wants to spy on some users ?
Other advantage, is that if you lose your developer private key, then you do not lose the capacity of doing updates.
The minus of that, is that you have to count on Google to sign every single of your APKs.
If they do not trust Google, VLC can add a checksum or integrity checks to the binaries loaded by the app during runtime.
Given that one option here is to let Google sign with a new key and keep things updated (dropping support for old devices in the process), this seems like a policy limitation, not an Android technical limitation?
And the disadvantage of that is that it is almost impossible to patch APKs on your own without running into serious issues, even as root - particularly when the app you're trying to patch has shared permissions with other apps of the same developer.
[1] - https://archive.is/pzanE
There is specifically no zoom with the rectangle box that Windows has and many other things. There IS a "Zoom" but it's not the same at all and just modified window sizes. And I can't import my Windows VLC settings like I thought I would.
I have tons of shortcuts, etc already assigned on my Windows end. This pissed me off because I spent a lot of time getting my VLC settings how I want them thinking I would just import them into my macbook.
There's not even a way to import or export MacOS VLC's own settings.
https://imgur.com/a/7G7REfv
I would be more than happy to be wrong about this and corrected..
I don't see any capabilities regarding your first question outside of testing specific devices through TestFlight, but I would think it is fairly safe to assume that Apple has put a lot of work into making sure this works consistently between devices.
It is also entirely possible that, like working with Cloud Providers, that there is a difference between what normal users can do and what can be done with NDA's and other contracts signed.
My understanding is that Google really wants to manage your keys so that you can't really mess up. If your app has a lot of users and you lose the signing key, IIRC you'll cause an outage due to the fact that existing users will not be able to update the app without uninstalling it and re-installing it, causing data loss.
I'd love to be corrected, as there might be some key rotation procedure in place that I'm unaware of. In any case, even if you owned the signing key, no one could theoretically stop Google from providing an APK signed with another key to the PlayStore users, since at first install the apps trust whatever key you provide (and the only cross-check I'm aware of is, well, Play Protect, also owned by Google)
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.
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.
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.
If you use pretty much anything other than Linux (and even that with care) there is a rather long list of people who effectively have root on all your stuff.
Maybe this can’t be avoided. Economies and civilizations run on division of labor and interdependency. I just think it’s important that people understand this. Most people don’t and think they have far more digital security and privacy than they do.
For example, Chrome extensions, it's crazy that a random guy, can automatically update its piece of JS, just to steal all credentials, and there is no mechanism to disable that (or very well hidden) (like what happened with "The Great Suspender", though it was a great extension)
Instead, Google can really mess up. Which they will do somewhat less often than your average app developer, but when they do do it, it will break everything.
> I'd love to be corrected, as there might be some key rotation procedure in place that I'm unaware of. In any case, even if you owned the signing key, no one could theoretically stop Google from providing an APK signed with another key to the PlayStore users, [...]
Only on new installs, which is a much smaller window than being able to change the app on every update.
"Google" in the large, of course, also has a lot of paths to modify the OS and everything that's validating the signatures... but that's a different part of Google, and that risk does not justify this one.
Half right: it means you can't publish updates under the same package name. They can continue using the old version, so it doesn't force any sort of data loss, but if they want to upgrade they have to find the new app, it won't be a reinstall-the-same-one situation.
This is of course not a huge deal for apps that are just wrappers of cloud services - but apps with local data will suffer the most.
Google manages the distribution key for you, one of the many reasons is because they create optimized APKs for each platform.
Hmm... if Google went rogue, wouldn't everyone's Android phone basically be pwnt whether they had some dev's signing key or not?
* 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)
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.
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.
Google owns your bank's app signing key, which means that they can craft any update for your banking app in a way that it makes it leak the content of your application data. In the case of a bank, this might contain sensitive information: but not necessarily the password / token that is used to access your account as this might be stored in a more secure place like the HW-backed keystore.
Nevertheless, if they have a way to modify your banking app binary without you noticing - they technically have access to your bank account (to the same level the app has).
Would Google ever do this? Probably not, but the risk of a key compromise by a rogue employee is still there.
Is this risk higher than your bank leaking the key? It depends, hopefully the person who has access to Google HSMs is not the same that has the rights to create a new release on the Google Play Store.
The biggest issue I personally see is that we're putting so much trust in Google to basically control all of your apps - but that's sort of already happening on Android because people are generally running Google-flavored Android builds which have privileged Google Play Services.
And Google already provides the default web browser for Android, the OS web view, and the most popular desktop browser in the world.
More discussion over here last week: https://news.ycombinator.com/item?id=39789300
In other words, Android gives access to multiple curated app stores, and side-loading. Whilst I understand that Apple only allowed use of apps from their own store until the EU stepped in, and now they have an EU-available update that allows side-loading.
"not really, it would just leave users behind, which is what they are trying to prevent. And the f-droid versions are built (from source) and signed by f-droid, not VLC."
I'm not aware of any iPhone that has documentation for unlocking the bootloader.
However, I agree that for the average person, they're both almost as free.
I do think a hybrid approach would be best here though.
https://www.androidauthority.com/android-15-app-archiving-de...