If I put an extra bit of tinfoil on my hat, I might speculate this is actually encouraged by the CIA/NSA/FBI or similar parties.<p>Certainly, they now have the option of trying to force google into delivering modified apps to certain people. This situation changes the trust model for e.g. signal from "do you trust the app developer" to "do you trust google" against the pressures of hacking and legal requirement of cooperation. The fact that reproducible builds become _that much_ more difficult with this is extra bad. It takes away a rather effective "after the fact" detection mechanism for these kinds of abuses.<p>It seems obvious to me there are plenty of important app developers (like signal) that are less likely to bow before the long arm of the US than the google play store. Also because for a principled developer, their app is likely 100% of their business. Whereas for google, any app is only a small part of their business. Google simply has much less incentive to defend the users of a single app that the developer.<p>Hence, it seems to me that this situation is realistically going to lead to more ways for law enforcement to access secret data on your devices. Whether this is part of the motivation for this change or not, the effect seems unavoidable.
At this point I am convinced this entire line of thought is just FUD.<p>> <i>This means that Google can (or can be forced to) distribute backdoored versions of popular apps to targeted people. The app you are downloading may be different from the app your neighbour is downloading. And the app signature will be perfectly valid for both of them.</i><p>Google already controls the operating system, the installer, and the SDKs you used to develop your Android app in the first place. If they wanted to backdoor your app there are already plenty of opportunities to do so at multiple levels throughout this chain. Retaining your own signing keys does not eliminate this potential threat, so you still have to trust them. If you don't, then you should avoid using Android entirely.
Out of curiosity, would this allow Google to perform the signing _at the moment of download_?<p>By that I mean, would it be possible that 2 different people download the app from the Play store, one of them gets an unmodified version of the app and the other (perhaps based on the user's race, country of origin, etc.) gets an on-the-fly modified version of the app.<p>The developer - and likely 99+% of all users - would never know or even be able to tell because most copies of the app in existence are 100% what the developer created. But, for a few rare birds, backdoors are aplenty.<p>Regardless, I'm 100% against this. But, my thinking above is this is possibly far worse than I initially imagined.
Excellent, more evidence for the EU anti trust case against Google's and Apple's monopoly on app stores.<p>Remember, Microsoft got in trouble for just pre installing internet explorer. There was no blockage or anything preventing you from installing any other browser and use it without any limitations.
Everyone seems kind of mad about this. Doesn't Debian do the same thing? The original developer doesn't build and sign Debian packages, the Debian project does that. Now Google does the exact same thing, and the conspiracy theories abound about how the NSA is making them do it or something. Is the NSA also making linux distributions sign packages?
One thing that's super annoying about this is Google's own build tool Bazel can't create app bundles: <a href="https://github.com/bazelbuild/bazel/issues/11497" rel="nofollow">https://github.com/bazelbuild/bazel/issues/11497</a><p>I wonder if internally they either have this ability or this constraint is only required for non Google app developers?
Signing in a distributed environment with a (sometimes required) hardware based key is really annoying. You basically have to build your own system for it. I've actually wanted inexpensive signing as a service (for Windows) for some time. Haven't been actively watching for it though.
It makes absolutely no sense to do it this way. So either let me sign the app and check it in Play store app, or recompile and modify my app as you wish and tell Play store app to not check the signature.
<a href="https://developer.android.com/studio/publish/app-signing" rel="nofollow">https://developer.android.com/studio/publish/app-signing</a><p>It seems this is only required for "Android App Bundles", whatever the hell that is, and not apps.<p>"Android requires that all APKs be digitally signed with a certificate before they are installed on a device or updated. If you use Android App Bundles, you need to sign only your app bundle before you upload it to the Play Console, and Play App Signing takes care of the rest. However, you can also manually sign your app for upload to Google Play and other app stores."<p>"And, because app bundles defer building and signing APKs to the Google Play Store, you need to opt in to Play App Signing before you upload your app bundle."
I'm sorry if this is a noob question, but will package repos like FDroid still work? Or will operating system reject non-Google / self-built packages?
What if instead, Google makes it optional?<p>Maybe they can release a tool to create APKs from App Bundles locally (maybe call it, idk, 'bundletool' or something like that). They could also make it so the Google Play Console allows developers to choose between uploading APKs or an App Bundle, and communicating the pros/cons of both methods. That way, a developer (not Google) can choose which option is best for their business and their customers!<p>Sound good to me at least (although to be fair, I don't have an ulterior motives or bad intentions)
Symbian used have something like this called Symbian Signed. It was a complete pain in the arse and probably one reason why hobbyists barely ever wrote programs for it.
Google, I demand you immediately roll this back and fire all parties that argued for the current decision. This change in policy and change in security model is an unacceptable break in your promises. It changes from "We guarantee we will distribute your app unmodified" to ... well, I don't know what you are promising, but it's not that.<p>There are two possibilities here: Malice or Incompetence. We'll take Hanlon's razor and assume Incompetence, but it is gross incompetence. It is unacceptable.