VLC can't update on Android without giving Google private signing keys
social.treehouse.systems
social.treehouse.systems
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.
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.
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.
https://www.androidauthority.com/android-15-app-archiving-de...
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.
I do think a hybrid approach would be best here though.
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.
I would be more than happy to be wrong about this and corrected..
[1] - https://archive.is/pzanE
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.