Google Play Dumps APKs for the More Google-Controlled “Android App Bundle”
arstechnica.com
arstechnica.com
Which means: the devices will continue to be able to install APKs. The major massive difference is that the apps will now be signed by Google on servers and not by developers on their local machines.
I'm wondering why Google doesn't allow developers to build the optimizes APKs still - the Android build system does have that capability. Noone really used it, but it's there - there should be a way to opt out of signing key sharing.
This doesn't affect sideloading in the slightest.
The way the Play Store is currently designed, end users don't even have the ability to view the key-path before installing a package. So detecting if it is Google Vs. app developer's signing key is extremely unlikely without copying that APK off-device and inspecting it.
All users know is: Is this using a signing key trusted by Google? Yay/Nay.
1. Nothing has ever prevented tampering with the signature before first install.
2. Google owns and writes the OS.
3. Libraries like WebView are both security critical and updated via ordinary app updates, and are provided by Google.
4. The dex bytecode isn't actually run on modern devices. Instead it is compiled into an executable by code owned by... Google.
5. The large majority of developers are using compilers and other tooling provided by Google.
This is why the concern over this change is ludicrous. When you installed Signal or whatever for the first time did you check the signature? Did it bother you that it was technically possible for Play to substitute code? No. Because you are using an Android phone and trusting the OS developer is a requirement for everything.
And there isn't a "total lack of chances to stop tampering", since the code section can still be signed with a different key.
So why is everybody suddenly claiming a conspiracy here?
From a security perspective I don’t think it makes the slightest difference. Google controls the logic that prevents updating apps with a different signing key.
There are so many conceivable ways that Google could inject arbitrary code into each process (e.g. silently cause a different “shadow” app bundle to be launched, play with LD_LIBRARY_PATH, play with the Dalvik VM, modify Java/system libraries, etc) or read processes’ memory, that it’s safe to assume that if Google wants (or is forced to) to modify your app’s behaviour or exfiltrate sensitive data from your device then it’s absolutely within their power to do that.
https://developer.android.com/guide/app-bundle/code-transpar...
> Important: The Android OS does not verify code transparency files at install time, and continues to rely on the APK signing schemes for verification of any installed APKs.
It's pretty much useless because no-fscking-body is going to build a service to gather signatures from a bunch of devices in hopes to catch Google in the act.
> Noone really used it
I think you answered your own question
They could still let the people who want to produce their own optimized APKs and sign them with their key just do it as before, while defaulting to whatever they plan to do now.
And I'm waiting for the first supply-chain attack resulting from Google signing a rootkit, Microsoft-style...
Moxie is fine with this state of affairs on iOS - I'm not sure why this would change anything on that front?
https://github.com/signalapp/Signal-Android/tree/master/repr...
> Important: The Android OS does not verify code transparency files at install time, and continues to rely on the APK signing schemes for verification of any installed APKs.
This is like having checksums in a Readme. If nobody checks them (and that's the likely case, since the OS doesn't), it doesn't matter if they differ from the distributed files.
It's still the case that Google is taking over the code signing roles, so that the user's OS will no longer tell the difference between a developer signed update and a Google signed update. This is a negative for security and transparency, regardless of the size benefits and regardless of the fact that the Apple App Store has operated in this fashion since the beginning.
For example, https://www.theverge.com/2021/4/27/22406303/imessage-android...
> In the absence of a strategy to become the primary messaging service for [the] bulk of cell phone users, I am concerned [that] iMessage on Android would simply serve to remove an obstacle to iPhone families giving their kids Android phones.
Or, you know, maybe, just maybe, people actually, genuinely enjoy using these devices.
Android’s only competition has intentionally priced itself out of affordability for two-thirds of the world’s population.
I really don't understand why Google is trying to force me into this (even for existing apps, every time you open the console it's just bombarding you with warnings that you don't use AAB).
They could just add a sanity check, if less than 50kB are saved by switching to AAB, just don't recommend/force it.
But they don't want that. Apps created after august won't even let you download the signing key so you could sign non-play store apks yourself. The only way this makes sense is if they want to prevent off-playstore distribution and verification entirely.
A lot, I would bet. Can you even 9-slice a VectorDrawable?
If you've localized to lots of languages, it starts getting big. I may be misremembering, but I think it was about 8 MB of the 30ish MB apk at my last job (before some heroic work to move most of the strings outside the android framework)
1. Reduction in APK Size. Not just native libraries, this gives ability for Google to optimize downloads based on screen size, locale etc.
In countries where data still costs $$$, its a significant boost to both end user and developers (Reduce size = increased no of downloads).
3. Enables dynamic features. End users can download parts of app only when they need it.
I'm asking about a community/fourm that is discussing how Android can be separate from Google in the distopian future. Anyone know of a website where this is discussed?
Oh those were the years...
The end format is still APK.
The alternative to this was called Multi-APK and hardly anyone used it. It required generating and uploading a large number of different APKs and then uploading gigabytes of mostly-redundant APKs to the Play Store. That allowed you to manage the signing and minimize install size, but it was such a pain to orchestrate that it wasn't practical in most cases.
From the broader perspective of the Android ecosystem, it's debatably monopolistic behavior. Google's defense by showing alternative app stores on Android gets slightly weaker.
1. Android only allow you to update existing apps with APK signed by the same key. Google can't just push you update that gonna steal app data.
2. After you installed an app through Google Play you can safely update it from different APK source and know that it signed by correct developer. This is helpful when app you being using through Google Play blocked in your country or something.
AABs are hardly required for Google to inject their own code into apps. And honestly, why would you even be concerned about them injecting code into third party apps? If they really wanted to be malicious they could use system apps that they fully control anyway.
I do have concerns with Google removing the ability for developers to sign apps but Google themselves acting maliciously isn't why.
Sure they can't. Data is lost.
> AABs are hardly required for Google to inject their own code into apps.
Much harder for Google (or anyone legally mandating them) to get caught with AABs though.
> And honestly, why would you even be concerned about them injecting code into third party apps?
... in addition to a bunch of security issues. Also makes it possible to do forced monetization, like YouTube has done.
So? Presumably you are going to continue to interact with the app.
> .. in addition to a bunch of security issues.
What security issues?
> Also makes it possible to do forced monetization, like YouTube has done.
Forced monetization is an even stupider conspiracy than NSA spying since it would require wide use rather than targeted changes. This would be plainly obvious since there are loads of people who decompile apps and the signature on the code section would be broken.
It changes a lot. Apps losing their data is much more disruptive than the silent replacement incorrectly touted earlier.
> Forced monetization is an even stupider conspiracy than NSA spying since it would require wide use rather than targeted changes.
So? YouTube did it on content creators' content. Obvious yes, but directly enabled by the lack of dev-controlled signing keys.
I believe it's possible to keep an app's data on uninstall. It's not the default behavior, but that doesn't really matter in this case.
> Much harder for Google (or anyone legally mandating them) to get caught with AABs though.
Not really. And what does "legally mandating them" even mean? This is a policy change for the play store, it has nothing to do with legality.
> ... in addition to a bunch of security issues. Also makes it possible to do forced monetization, like YouTube has done.
The "security issues" exist regardless of this policy change - as I've already said, Google could easily do whatever they want with your phone anyway due to control over system apps and the OS. I have security concerns with Google being the sole owner of the signing keys, but that's not related to Google themselves acting maliciously.
As for "forced monetization", that's just reaching - if they were going to force monetization on apps that weren't their own then they just need to require it of developers on the play store. How does the ability to ship modified bundles make this any easier for them?
It's not and it does matter.
> And what does "legally mandating them" even mean?
Not sure how what's unclear about "legal mandate". If the law says, Google complies.
> The "security issues" exist regardless of this policy change - as I've already said.
They don't exist to the same extent, you repeating them doesn't make them more universal or true. Other vendors and forks exist, the simple existence of Google Play didn't mean every app is compromised by Google, now it will.
> Google could easily do whatever they want with your phone anyway due to control over system apps and the OS
Google doesn't control every vendor, controlling all signing keys is much easier than quite literally backdooring the OS for simply Google. There's a large difference in how visible any such malicious actions would be.
> As for "forced monetization", that's just reaching
Are YouTube's forced midroll ads "reaching" as well? There's no fundamental difference, they monetized someone else's content.
Controlling signing keys allows to simply patch the ads in. I'm not entirely sure why you don't see how it makes it easier for them.
I was mistaken - you're right that you can't keep app data. It still doesn't matter because they already have easier ways of running whatever code they want on phones with Google play.
> Not sure how what's unclear about "legal mandate". If the law says, Google complies.
I mean that I don't understand what your original statement was. Is it that governments can force google to hand over your signing keys? I agree that it is a concern, it just isn't the issue I was commenting on. I didn't mean to bring that into this - I just didn't understand your meaning.
> Google doesn't control every vendor
They don't need to. They already have system apps on every phone running Google play, which is the exact same list of devices that will be affected by this change. You're right that they don't control every (or even most) OS vendors for Android, but they don't need to.
> Are YouTube's forced midroll ads "reaching" as well? There's no fundamental difference, they monetized someone else's content.
I'm not debating whether midroll ads are right or wrong, I'm debating the technical merits of this incredibly roundabout method.
"Patching ads in" on an app-by-app basis is nonsense - why not just add it to some hooks in Google play services? Not to mention they'd have to make sure it doesn't break the apps themselves. Why waste the time and money? Hell, force app developers to insert code into their own apps by changing the policies on the store. I bet it's result in a lesser outcry than if they did it secretly. Signing keys as a conspiracy to show more ads is ridiculous when they have better vectors elsewhere.
Yes, super easy to check all the signatures on every app in your android phone with this: https://f-droid.org/en/packages/info.guardianproject.checkey...
They do allow you to make your own separate F-Droid binary repo which doesn't restrict your ability to use your own signing key, but then you have to get users to add your repo.
Uh... bruh. They do exactly what you're dumping the play store for.