[HN Gopher] Google Play Dumps APKs for the More Google-Controlle...
___________________________________________________________________
Google Play Dumps APKs for the More Google-Controlled "Android App
Bundle"
Author : muxator
Score : 157 points
Date : 2021-07-02 11:41 UTC (11 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| deregulateMed wrote:
| Is there a community that's keeping the FOSS nature of Android?
| I'm not talking about fdroid, they are great.
|
| 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?
| fragileone wrote:
| The most popular FOSS ROM communities probably have the biggest
| interest in this e.g. GrapheneOS, CalyxOS, LineageOS.
| solarkraft wrote:
| The LineageOS folks are the main developers of a non-Google
| version of Android. For actually running it without Google
| services you'll need microG, which seems to be worked on by one
| lone German developer.
| fsflover wrote:
| Consider GNU/Linux phones, Librem 5 and Pinephone, instead.
| ppf wrote:
| www.googlehaswon.com/buyadumbphone
| DaiPlusPlus wrote:
| Remember when we thought an alliance of Samsung, HTC, and LG
| would keep Android alive no-matter what Google would do?
|
| Oh those were the years...
| bitwize wrote:
| Wellp, guess who's not distributing their game through the Play
| Store. It's open source but I thought I might put it on Play for
| a nominal price and invite those who want it free to compile it
| themselves. But now? It'll be F-Droid only for me.
| techrat wrote:
| > It'll be F-Droid only for me.
|
| Uh... bruh. They do exactly what you're dumping the play store
| for.
| Avamander wrote:
| Yeah, the choices now are shit and shittier.
| jkaplowitz wrote:
| For inclusion into their official repo F-Droid requires you to
| either make sure each build is verifiably reproducible, in
| which case they will let you sign that build yourself, or else
| they need to sign it just like Google will now be doing. They
| used to always require that they sign it, without offering the
| exception for reproducible builds. They also support publishing
| parallel versions with both their signing key and yours, to
| help with smoother upgrades for users with the app already
| installed.
|
| 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.
| izacus wrote:
| The title is misleading on a technicality though - Android will
| continue to deploy applications via APKs. Developers will have to
| upload apps as AppBundles, which the Play Store service will
| repackage, resign and deliver to the devices as a set of APKs.
|
| 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.
| shaftway wrote:
| > I'm wondering why Google doesn't allow developers to build
| the optimizes APKs still
|
| > Noone really used it
|
| I think you answered your own question
| tut-urut-utut wrote:
| How forbidding something that is not used makes sense?
|
| 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.
| [deleted]
| diegoperini wrote:
| One important distinction is that now Google is able to inject
| code to apps without notice since they are the ones who sign
| the final APKs.
| ehsankia wrote:
| Is that true if you use code transparency signing key?
|
| https://developer.android.com/guide/app-bundle/code-
| transpar...
| Avamander wrote:
| Yes.
|
| > 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.
| Someone1234 wrote:
| Google has _always_ been able to do that. Just alter and re-
| sign the APK with their own key(s), since Google 's keys are
| trusted by Google Play Services (third party app stores also
| trust Google's signing keys for compatibility reasons).
|
| 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.
| psykus wrote:
| That's true for new installs at least. But Android won't
| let you install an update to an existing app with a
| different signing key, it'll error out with something
| generic.
| UncleMeat wrote:
| A threat model that only concerns updates and not new
| installs is incoherent.
| Avamander wrote:
| Less incoherent than a total lack of all chances to stop
| tampering though.
| UncleMeat wrote:
| People are concerned about Google editing code, which
| would be detectable through the signed code section or
| just basic decompilation and would be a nightmare for PR.
| But people are apparently not concerned with
|
| 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?
| jeeeb wrote:
| As an explanation as to why Google has gone down this
| design path, I think this makes sense. Basically it's
| easier to maintain compatibility with existing devices
| this way.
|
| 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.
| techrat wrote:
| Yep. The end format is still APK. What is being dumped is the
| unnecessary libraries/APIs that are not relevant to the device
| that is receiving the APK.
|
| This doesn't affect sideloading in the slightest.
| kumarm wrote:
| App Bundle has significant advantages:
|
| 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).
|
| 2. The amount of developers who lose their private keys is mind
| boggling. This fixes the issue.
|
| 3. Enables dynamic features. End users can download parts of app
| only when they need it.
| grishka wrote:
| The argument about size savings is pretty weak too. Any developer
| who has an app with large native libraries has already been
| splitting it by CPU architecture since forever. The screen
| resolution isn't much relevant at all because who even uses
| bitmap graphics any more when there's VectorDrawable? The strings
| do take up space, and I was told that the resources.arsc file
| where they reside isn't compressed in an apk because that would
| result in Android having trouble reading it, but its size is
| still usually negligible compared to the rest of the apk.
| toast0 wrote:
| > The strings do take up space, and I was told that the
| resources.arsc file where they reside isn't compressed in an
| apk because that would result in Android having trouble reading
| it, but its size is still usually negligible compared to the
| rest of the apk.
|
| 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)
| readams wrote:
| The size savings though are real in actual apps and they are
| generally around 15%. People are really desperate here to find
| ways to make everything a bad thing. Apple does stuff like this
| regularly.
| kuschku wrote:
| Switching to AAB would mean 0.4% savings for my own app.
| Which already is only 3.4MB large.
|
| 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.
| Clewza313 wrote:
| iOS has been a fully controlled walled garden since day one
| though, while Android was supposed to be the "free" open
| source alternative.
| izacus wrote:
| And the market seems to signal Google that Apple is doing
| the right thing though? IIRC iOS has passed 60% in USA
| these days and is repeatedly pushed as a "secure and
| malware free" OS on HN.
| pas wrote:
| It's pushed because Apple is seen as less privacy
| intrusive.
| infinityplus1 wrote:
| No, its because Apple is seen as a status symbol, has
| good brand reputation and locks users in the walled
| garden. General users don't know what happens behind the
| scenes.
|
| 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.
| grishka wrote:
| I just want to add that this is a uniquely US problem.
| Over here in Russia no one sends SMS or MMS to another
| person. So, consequently, no one uses iMessage either.
| spideymans wrote:
| > No, its because Apple is seen as a status symbol, has
| good brand reputation and locks users in the walled
| garden.
|
| Or, you know, maybe, just maybe, people actually,
| genuinely enjoy using these devices.
| saurik wrote:
| Android's worldwide marketshare is like 75%, though.
| These marketshare numbers haven't changed all that much
| for many years; and, to the extent to which they have,
| the more important battles were destroying all the non-
| duopoly competition. Even then, claiming that one's pet
| issue is clearly justified by marketshare is kind of
| nonsensical considering how complex these device
| ecosystems are... like, if I were to guess why iOS has
| better marketshare in the United States I would point to
| stuff like iTunes and Apple Stores, which might easily be
| so good in comparison to Play Music and [crickets] that
| even if they did everything else 100% wrong it might
| cause people to buy Apple over Samsung (which of course
| is the real competitor at this level, not Android
| really).
| spideymans wrote:
| > Android's worldwide marketshare is like 75%, though.
|
| Android's only competition has intentionally priced
| itself out of affordability for two-thirds of the world's
| population.
| jayd16 wrote:
| >who even uses bitmap graphics any more when there's
| VectorDrawable
|
| A lot, I would bet. Can you even 9-slice a VectorDrawable?
| grishka wrote:
| You can't, but in my experience, for things like stretchable
| control backgrounds, a <layer-list> with a bunch of <shape>s
| does everything you could possibly want.
| roody15 wrote:
| " A government could compel the app store owner to change your
| app, too."
| josefx wrote:
| I am not sure it is any way better right now. Is there even a
| way a user can check who signed the apk unless he has his
| unlocked android device hooked up to a PC with android dev.
| tools installed and a black belt in android development?
| roody15 wrote:
| APK model has worked well... does it need changed?
| techrat wrote:
| It's not being changed.
|
| The end format is still APK.
| roody15 wrote:
| Except google gets the source code first and then creates
| custom specific APK's. Not sure this step is really
| "needed".
| Avamander wrote:
| That's a very narrow technical view of the thing. It's
| pretty much only a .zip after AAB. You're losing
| universality, signature checks, tamper-resistance which
| made apks apks.
| Andrex wrote:
| From Google's perspective, it increases flexibility and the
| overall installation process for Google Play, and probably
| (speculating) cuts down on costs over the long-term.
|
| 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.
| sigmar wrote:
| >Is there even a way a user can check who signed the apk
|
| 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...
| SXX wrote:
| AFAIK you can't easily check keys, but current behavior is
| still much better:
|
| 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.
| redxdev wrote:
| Re: 1 - Sure they can. The play store has the ability to
| both uninstall and install apps without direct user input.
| Even if the OS itself blocks updating an app with a
| different key, it doesn't block uninstalling and then
| reinstalling with a different key to my knowledge.
|
| 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.
| Avamander wrote:
| > Re: 1 - Sure they can.
|
| 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.
| gjsman-1000 wrote:
| According to rumors, a big "extra benefit" Google receives is
| that Windows 11 will be able to directly run APKs. So, retire the
| universal APK so people on Windows get odd and incorrect
| experiences with incorrect feature mixes.
| [deleted]
| readams wrote:
| APKs don't magically stop existing. This doesn't have any
| effect on other app stores.
| patmorgan23 wrote:
| Yes but if android changes it's format then people will stop
| publishing APKs for new versions.
| pas wrote:
| No. Devices will still get APKs, but they'll be optimized
| and signed by Google. (
| https://news.ycombinator.com/item?id=27711002 )
| Avamander wrote:
| Good luck finding the correct version that matches your
| DPI and arch. Bunch of really "fun" malware campaigns are
| probably going to happen.
| ehsankia wrote:
| I don't understand how this change has anything to do with
| Windows 11 APK support? Hell, Microsoft didn't even work with
| Google, considering they're using the Amazon App Store, and
| this change is specific to Play Store. AFAIK Windows 11 runs
| APKs directly, app bundles play no role there.
| touristtam wrote:
| related discussion: https://news.ycombinator.com/item?id=27695486
| corty wrote:
| There goes Moxies justification for using only the Playstore for
| Signal...
|
| And I'm waiting for the first supply-chain attack resulting from
| Google signing a rootkit, Microsoft-style...
| izacus wrote:
| > There goes Moxies justification for using only the Playstore
| for Signal...
|
| Moxie is fine with this state of affairs on iOS - I'm not sure
| why this would change anything on that front?
| corty wrote:
| Moxie complained about F-Droid recompiling and resigning his
| stuff. And cited this as his reason to use only the
| Playstore. But I guess things were more about analytics and
| control after all.
| tssva wrote:
| You are trying to place events which happened in the past
| under a completely different set of circumstances into the
| circumstances of today and then are drawing a conclusion
| from that.
| corty wrote:
| Yes. It is a nice natural experiment as to Moxies
| motivations and principles, because only a very select
| set of circumstances has changed: Software authors can no
| longer control their signatures on Android. That time has
| passed is not relevant, or at best relevant to explain
| some change of heart over time.
| m-p-3 wrote:
| Moxie can use F-Droid with his own signature if he supplies
| a reproducible build.
|
| https://f-droid.org/en/docs/Reproducible_Builds/
| Aissen wrote:
| Which in theory Signal supports; anyone tried it lately ?
|
| https://github.com/signalapp/Signal-
| Android/tree/master/repr...
| tapoxi wrote:
| AAB supports a code transparency feature:
| https://developer.android.com/guide/app-bundle/code-transpar...
| toast0 wrote:
| > The code transparency file does not verify resources,
| assets, the Android Manifest, or any other files that are not
| DEX files or native libraries contained in the lib/ folder.
|
| > 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.
| for1nner wrote:
| Democracy dying with a silent whimper before our very eyes.
| [deleted]
___________________________________________________________________
(page generated 2021-07-02 23:02 UTC)