Sounds like the UEFI shim loader that's signed by Microsoft but can load an arbitrary EFI executable (with some signing checks). The difference is that the UEFI shim loader is endorsed/condoned by Microsoft. What about Google? This seems easily patchable, ostensibly for "security purposes" (eg. disabling loading dynamic code).
While it is technically feasible, it is not a good idea to try and find a technical solution to a people/organisation problem.
Do not accept the premise of assholes.
I hope we can get the EU to fund a truly open Android Fork. Maybe under some organisation similar to NL Labs.
--- edit ---
Furthermore, the need for a trustworthy binary to be auditable to a certain hash or something would make banning this a simple task if Google would want to go that route.
It would be hard to find manufacturers to use it. None of the existing Android phone manufacturers would be able to release phones with this fork without also abandoning the official Android platform on all markets. Google are very strict with this in their tos. You cannot release devices using non official Android builds without losing your right to use GMS and Android Brandice on your other Android devices.
> verified loader apk, which in turn dynamically loads any apk the user wants
Wasn't this kind of solution considered and sort of dismissed (because of too much centralization iirc) by F-Droid (can't find the reference now)? It seems like something that's worth trying, but in the end it's just a band-aid. If it gets any traction Google will shut it down. The real disease is dependence on a duopoly of (quasi)-proprietary OS for the dominant computing platform of our time.
This will not work because the goal of android developer verification is to prevent running Google-sanctioned code. If you actually tried to publish this, Google will revoke the signature on the loader APK.
Well, I'd rather verify myself with the government identity than accept a stock OS that literally woke me up with a fake message promoting Gemini despite me spending almost 2 hours turning every possible privacy-invasive setting off.
To me, the attention to these verification changes seems misplaced. We need to defend the ability to unlock the bootloader, pressure Google to revive AOSP and then encourage people to switch to a more user-friendly OS.
You're already unable to install what you want on a stock OS due to Android permission model treating you as a third-class citizen, after Google and OEMs.
The issue with government IDs is that they are, for all we know, not trustworthy, but everyone treats them like they are. And you know, I am not going to "verify" myself with Google with this kind of toilet paperwork.
If Google decides to pull this off, then I guess reflashing to a custom ROM with this crap patched out will be a very first step I'll be recommending to anyone who cares.
This "attack" is not even theoretical. Android apps can just download arbitrary binary code, mprotect(PROT_MAYEXEC) some area in RAM, link the code there, and run it.
Google will simply revoke the keys for the "loader" APK. But that's fine for malware, its authors will just use the next stolen credit card to register a new account.
That's also why this has nothing to do with security.
> My vision of the hack is to distribute a verified loader apk, which in turn dynamically loads any apk the user wants. A user obtains the loader apk once and loads apps without installing as much as they want.
And a day after you release, Google will say "Oh no you don't" and unverify your app, preventing it from being installed or run. Which is you know, kind of the point of this maneuver.
I'm already banned from publishing Android apps through Google, but apart from that, what would stop me making a server you can upload any app to and sign it with my certificate?
Or you could just tell everyone out there that there are already tons of older Android devices which will never get any of these hostile updates, and if you're a developer, make sure your app runs on those older versions. Spread the word about how hostile the newer devices are, and let the lazy masses do what they're best at doing. Of course there will always be rabid bootlickers who will gladly pay to put Google's noose around their necks, but if they become the minority, and the majority just stops upgrading, it could very effectively pull control of Android away from Google. Giving everyone yet another reason to not upgrade, especially given the huge Android marketshare in poorer countries, could become a powerful force.
I think this means we need to rely on web technologies more. PWAs are looking pretty good on mobile devices these days and you can publish any web app you want with no reviewing authority. The web has a bunch of crazy APIs now that let you build crazy things and for everything else you're a hosted server away somewhere that can run more complex jobs.
I believe devices I own should let me do whatever I want with them and I agree that the verification is BS, but I'll work around it in the ways I can which means building more for the web.
If that ever drops the open pretense (since both traffic and trust authority are largely centralized and thus easily controllable) then I'll only write for self hosted linux boxes.
We as individuals can only do so much. We'd need actual organization and some measure of political power to do anything more since normal people do not care about this.
PWAs are at the mercy of Gapple have always been handicapped in just the right places to not be viable vs installed apps. Most people don't even know how to install one.
This is harmful speculation. Many PWA features are broken in small ways which add up. The caniuse database does not test that a PWA feature meets the spec and there is no better database. Nobody can say that PWAs are "looking good" without such testing.
While neat, it glosses over the actual problem, while maybe not even solving it (depending on what you deem the problem to be in the first place). It solved the immediate problem today, but not in a way that's going to remain solved.
I'd imagine Google would plug any major holes in their soon to be closed garden, assuming that is their intention. So this and any other fix to the problem of 'install app through not-Google Play' that goes via technical means that Google can just cover up after a month or two doesn't actually move the needle any meaningful amount.
In the same vein, using adb isn't a real solution to that same problem for most people, since having to use adb is a massive jump in required effort that's going to leave all the normies behind, with only the super-dedicated willing to go through the hassle, and an equivalent amount of developer effort is going to be left behind as well, since their audience just got decimated, and they themselves might not even bother to develop something that even their dad or sister is going to bother/be able to install. Anything that's much more complicated than 'go to website, download thing, run thing, click your way through' doesn't solve for this.
The actual problem is to have Google not be knobheads about it, and the only way that's realistically going to happen is through the law, but that's not looking all that likely in my view.
>My vision of the hack is to distribute a verified loader apk, which in turn dynamically loads any apk the user wants. A user obtains the loader apk once and loads apps without installing as much as they want.
Google's not going to let you keep your signing key if you do this with it.
>Google assures that it would be possible to install applications locally using ADB, but there are no details on this
It's going to be the same as Play Protect using the PackageVerifier API. Even if won't trust that Play Protect will continue to allow adb installs, if you go to the developer options you can disable package verifiers for adb installs.
>the concept
This would not really work considering you can't do a lot of things at runtime. You can't create activities, you can't create services, you can't declare permissions, you can't use permissions, etc. Pretty much everything in your manifest can't be done properly. You can't really do a job faking it. You would have to declare a ton of dummy activities with all different permutations of things like launch mode, document launch mode, intent filters, etc.
What you can do are things like game engines like how the android godot editor works where you aren't loading full android apps, but projects into the editor.
The OP addressed this: `adb` works ... *for now*. Other than google's pinky promise, what assurance do we have that adb will continue to work in a year or five?
I am not a app developer however from what I read on the android developer site you just need to provide some form of id, the singing key and the app id.
You don't have to distribute via the app store, you dont have to get Googles permission to publish the app or have them sign it.
This looks like purely app validation, we only run apps we can prove originate from the author.
Under that logic, even if the app is "malicious" it would still be possible to install it. And thats not true, if somthing is deemed malicious, its blocked. Is app that hurts Google's dominance "malicious"? Who is it that decides what is malicious?
So if Google doesn't like the app in question (such as ReVanced, NewPipe, etc), they can simply target that signing key to completely disable the app on all devices, even if it's not distributed by them.
Having the file signed by a relatively centralized authority makes it much easier for Google to gain control outside of their realm.
What about this idea? Make a movement among the devs who are willing to distribute "legitimately" (via Google Play or "authorized" sideload), to sign their apps with intentionally insecure private key. Then some community will just mine up these certificates in already published apps and publish them somewhere on GitHub.
38 comments
[ 2.5 ms ] story [ 69.3 ms ] threadDo not accept the premise of assholes.
I hope we can get the EU to fund a truly open Android Fork. Maybe under some organisation similar to NL Labs.
--- edit ---
Furthermore, the need for a trustworthy binary to be auditable to a certain hash or something would make banning this a simple task if Google would want to go that route.
Wasn't this kind of solution considered and sort of dismissed (because of too much centralization iirc) by F-Droid (can't find the reference now)? It seems like something that's worth trying, but in the end it's just a band-aid. If it gets any traction Google will shut it down. The real disease is dependence on a duopoly of (quasi)-proprietary OS for the dominant computing platform of our time.
To me, the attention to these verification changes seems misplaced. We need to defend the ability to unlock the bootloader, pressure Google to revive AOSP and then encourage people to switch to a more user-friendly OS.
You're already unable to install what you want on a stock OS due to Android permission model treating you as a third-class citizen, after Google and OEMs.
If Google decides to pull this off, then I guess reflashing to a custom ROM with this crap patched out will be a very first step I'll be recommending to anyone who cares.
Android may ultimately win the arms race, but if they want to be evil, we should make their task as tedious as possible.
[1] https://github.com/LiveContainer/LiveContainer
Google will simply revoke the keys for the "loader" APK. But that's fine for malware, its authors will just use the next stolen credit card to register a new account.
That's also why this has nothing to do with security.
And a day after you release, Google will say "Oh no you don't" and unverify your app, preventing it from being installed or run. Which is you know, kind of the point of this maneuver.
I believe devices I own should let me do whatever I want with them and I agree that the verification is BS, but I'll work around it in the ways I can which means building more for the web.
If that ever drops the open pretense (since both traffic and trust authority are largely centralized and thus easily controllable) then I'll only write for self hosted linux boxes.
We as individuals can only do so much. We'd need actual organization and some measure of political power to do anything more since normal people do not care about this.
I'd imagine Google would plug any major holes in their soon to be closed garden, assuming that is their intention. So this and any other fix to the problem of 'install app through not-Google Play' that goes via technical means that Google can just cover up after a month or two doesn't actually move the needle any meaningful amount.
In the same vein, using adb isn't a real solution to that same problem for most people, since having to use adb is a massive jump in required effort that's going to leave all the normies behind, with only the super-dedicated willing to go through the hassle, and an equivalent amount of developer effort is going to be left behind as well, since their audience just got decimated, and they themselves might not even bother to develop something that even their dad or sister is going to bother/be able to install. Anything that's much more complicated than 'go to website, download thing, run thing, click your way through' doesn't solve for this.
The actual problem is to have Google not be knobheads about it, and the only way that's realistically going to happen is through the law, but that's not looking all that likely in my view.
Right back to Symbian signed AppTRK and rolling back hardware clocks. Great.
Google's not going to let you keep your signing key if you do this with it.
It's going to be the same as Play Protect using the PackageVerifier API. Even if won't trust that Play Protect will continue to allow adb installs, if you go to the developer options you can disable package verifiers for adb installs.
>the concept
This would not really work considering you can't do a lot of things at runtime. You can't create activities, you can't create services, you can't declare permissions, you can't use permissions, etc. Pretty much everything in your manifest can't be done properly. You can't really do a job faking it. You would have to declare a ton of dummy activities with all different permutations of things like launch mode, document launch mode, intent filters, etc.
What you can do are things like game engines like how the android godot editor works where you aren't loading full android apps, but projects into the editor.
You don't have to distribute via the app store, you dont have to get Googles permission to publish the app or have them sign it.
This looks like purely app validation, we only run apps we can prove originate from the author.
Having the file signed by a relatively centralized authority makes it much easier for Google to gain control outside of their realm.