Android 14 introduces a number of new features for app stores, including an “update ownership” API that lets an app store claim ownership over an app it installs. If any other app store tries to push an update to that app, Android will throw up a dialog asking you what they want to do. The dialog asks you if you want to “update this app from [X]” since “this app normally receives updates from [Y]” and warns that “by updating from a different source, you may receive future updates from any source on your phone.” You can choose to cancel or update anyway, which is good since it means one app store can’t lock you out of getting app updates from somewhere else.
When taken in isolation, I think this dialog is a good addition to Android – I personally see no issues with informing users of the very valid risk that come with installing applications from outside the Play Store, especially ones coming from random websites (and not from APKMirror or F-droid or similar, more well-known sources). There are real risks associated with doing so, and it’s a good idea to warn people of this in the highly unlikely event they both accidentally download a random APK and open it to install it.
However, the ‘when’ clause is doing a lot of heavy lifting here. Google has been slowly locking Android down for years now, and it’s not unreasonable to assume that this is simply yet another stop along the way in that process. I don’t think Google will ever fully remove sideloading from Android, but they sure will do whatever they can to make it as hard, cumbersome, annoying, and frustrating as possible.
The wording on this doesn’t sound like it’ll do anything about Facebook bribing Samsung to preinstall their garbage, and then get side updates outside of the play store (in the US market). It seems to be only about default Google apps as well.
I’m of two minds about this. On the one hand, this smells of Google testing the waters of disallowing third party app stores down the line, at least for “Google certified” devices that ship with a legitimate installation of Google’s own Play Service and related bits. That potential scenario shouldn’t affect device manufacturers who roll their own spin on AOSP, like Amazon and various Chinese firms, but who knows what Google will change in AOSP down the line?
On the other hand, more and more these days a person’s phone is their only real connection to the Internet, to their banking and shopping, their jobs and paychecks, and so on. The idea that Google is wanting to increase protection against malicious app updates is a good one, and if they truly only mean well with this API, then I’m cautiously for it. My wife uses an Android phone (a Google Pixel 5 to be exact) and it’s peace of mind knowing it will be that much harder for malware to sneak onto her device via a rogue update once she takes the upgrade to version 14.
Morgan.
It would be awful if google were to join apple in blocking app store competitors. However thankfully that doesn’t seem to be the case here. I don’t mind getting a notice that a different app store is about to update an app. I wonder if the same is true in reverse. Say I install an app from fdroid, will android warn me if google’s play store tries to update it? I think the same rules & notices should apply to everyone including google. What are the chances of that?
While I’m a major advocate for app sandboxing, I’m actually kind of disappointed in the security on most operating systems. Like you point out, there are sensitive applications that I don’t want running the same space as other applications like games, etc. The sandboxing on android and IOS are always balancing security and usability and the result is a compromise in the middle. Sometimes this is ok, but I would like the ability to create explicit sandboxes with stronger boundaries. And every time you install an app you’d have the option of placing it in it’s own isolated container that is secure and isolated from other containers. By separating the banking apps from other apps like games & social media it would make it safer to run both trusted and untrusted applications on your device and provide greater confidence that they remain isolated regardless of the permissions they’ve been granted within their respective containers.
I don’t know if this would be considered too complicated for normal users, but it would be nice to have for power users at least.
If it could be done completely behind the veil so to speak, it wouldn’t be an issue for the average user. Hell, I consider myself a well informed and experienced power user, and I have no idea about much of the inner workings of my iPhone. I know it’s based on macOS, which is based in part on BSD, and I get the concept of the secure enclave, but beyond that I’m as clueless as any other iPhone user. Android is a little more transparent since the bulk of it is open source, but the bits that make it secure enough for a banking app to trust the system are proprietary to Google.
One issue with containerized systems that I do have experience with, via Qubes OS, is performance. There will always be a performance hit with containers, as each one only gets a fraction of the already limited processing and memory space in a mobile device. While it’s true that today’s devices have more cores and RAM than your average PC from ten years ago, there is a limit to how much you can siphon off for containers/jails and still have a device that doesn’t show the effects of reducing the resources available to the core OS. Maybe when we hit the point of having 32 or more cores and 1GB/core of RAM in a phone, along with advances in the software stack, we can have a mobile device with a fully containerized user space without any worse performance than today’s flagship devices.
Thom, if you read the text carefully, it says the warning will pop up when you install an app from some store and then update it by sideloading an apk, which can be a low-hanging social engineering vulnerability. As long as they don’t completely block it and only show a warning (which means downgrades of Play Store apps using apkmirror apks can still be done by those who know what they are doing), it’s a good thing.
I’d like the feature if it were opened up and warned for all apps updated outside of the app store used to update it, and if it could continue the warning for future sideloads. I’m thinking things like Bank apps could really benefit from some protection against malicious sideloading. I’m not sure thats a real risk currently, but maybe for more targeted approaches.
Installing an APK from the developer’s website, or an alternative app store, is no riskier than installing one from Google Play. All being listed on the Play Store means is that the developer has given Google some money, there is no real checking done of the app quality, it is more of a tool for censorship and to make Google money than anything else. Android already has a robust permissions system so apps cannot do any user-hostile actions without permission so the whole thing is a total non-issue.
Spreading FUD that APKs that didn’t come from Google Play are somehow harmful is itself harmful.
It also implies that there’s no risk installing apps from the Google Play Store, which is stupid considering how many apps there were found to have malicious code.
friedchicken,
That’s true. People are lead to believe that software installed from the official app store must be safe, but being in an app store doesn’t automatically make it safe. Malicious software can and does make it way into both of apple’s and google’s app stores Security mostly comes down to the proper use of sandboxes. I consider it bad practice to treat all applications as having the same level of trust. For example, I might want to run games and I might want to run banking apps, but the fact that I want to run both of them does not mean they are equally trustworthy. Some applications warrant extra security and IMHO operating systems should have a facility to provide robust explicit isolation for them – kind of like a firewall, but for applications.
Most operating systems already technically support isolation, but the tooling for it is inadequate and not accessible for users.
The threat vector I’m worried about, that this new API seems to target, is where a rogue APK is downloaded from a malicious website (code injection, hidden redirect, misspelled URL, etc) and the clueless user is directed to install the “update” to continue to use whatever service they thought they were accessing. Since the downloaded APK doesn’t come from the same app source as the currently installed version (whether that source is Google Play, F-Droid, APKMirror, or another app source already trusted by the user), the API will prevent it from being installed.
At least, that’s my understanding of how this works. As I said in my previous post, I’m a bit worried Google might one day leverage this API to block third party app stores (or at least make it more difficult to use them), but for right now all evidence points to this being a good move by them to prevent a specific threat vector from infecting devices.
It already prevents. Signatures don’t match and update will not be installed
Supporting normal installation of applications must become mandatory for both main mobile platforms in the future. Currently only Android does support it. Don’t understand exactly on why it is taking regulators so long.