Google I/O 2021 and Uncomfortable Questions
commonsware.com
commonsware.com
> Google Play uses your app bundle to generate and serve optimized APKs for each device configuration, so only the code and resources that are needed for a specific device are downloaded to run your app. You no longer have to build, sign, and manage multiple APKs to optimize support for different devices, and users get smaller, more-optimized downloads.
But as all this logic sits on Google servers and might involve lots of signing of apks for a single app and version, Google has decided it needs your signing keys for that feature. Which is weird already because you could also think of a model where you provide Google not with the keys but a service where Google presents you an apk, and you sign it. Then you can inspect it retroactively and run scanners on it, if you want to. The keys stay yours and you would know what Google is up to with your application.
If you have problems with giving Google your signing keys, you can just avoid this feature. But apparently there is the fear that Google wants to make the feature required. Which would give them ability to alter basically any app on the play store as they deem fit. Or they might in fact be forced by governments. Already now many providers like facebook take down public posts because a local government disliked a post. What if a govt told Google "please install this altered Signal app on this person's device"? And yes, Google apps already run as system app so they could already do something like that, but an implementation of that is way harder to make consistent among different vendors.
The reason for digital signatures is that they make a claim. "As a representative of organisation A, the binary with shasum XXXX is our work. We stand behind it." Why would I generate a private key, then share my private key with google? If google wants to claim that a binary they're shipping to users is same the one they received, they don't need my private key to do that. They can make their own signature, with their own key. Using a key I generated then handed to them is just dangerous security theatre. Google is asking me to vouch for binaries they sign and serve. But I can't vouch for those binaries - I didn't produce them and can't make any claim about their provenance.
IIRC this is how it works by default for new apps. Uploading your existing signing key is only necessary for backwards compatibility to allow you to update existing apps that have already been published using that key.
Personally, I'd like to see Apple, Google, and possibly Microsoft take this to what I think is the obvious conclusion: developers and independent software vendors submit source code, artwork and other such "assets", sufficient meta data, and build instructions to the store, the store builds and publishes the applications and makes them available to users. F-Droid builds and publishes using its own keys and while there are problems with delay for some time-sensitive apps (most notably Newpipe, an application to watch YouTube videos), it works out quite well for the most part. I can't imagine why Apple and Google couldn't have what are essentially multiple build runners running at the same time to cut this time shorter to something like an hour at the most?
In return at least for Android (Apple is a bit of a special case), I would like to see it made possible at least for F-Droid or something similar to be able to update apps without requiring user intervention. Not sure how the technology will work exactly but my understanding (please correct me if I am wrong) is Google Play Store has super cow powers and I think it should be able to "bless" other applications to have the same super powers?
Not sure how that would work with a proprietary app store like Play store.
Can you explain how? Since I've published things to F-Droid and since they also control signing and building (just like Apple and Google in this article), they can freely modify and change what's published on their store.
Just like with Google and Apple, you need to inherently trust them that they don't let people with access tamper with your app.
F-droid is funded by contributions and donations, and they need both. They also have everything out in the open, which brings extra scrutiny.
And the last part is just culture. F-droid is a community project with clear set goals. Google also has clear set goals, they just don't happen to align with their users for the most part.
https://forum.f-droid.org/t/welcome-a-new-fennec-f-droid/111...
I have just submitted 882 a Fennec update to 81.1.1. Should be available soon™. This version brings a lot of changes, like a new UI and modular codebase. The bad news:
Mozilla now tracks you even more actively using proprietary 3rd party services. I removed all tracking I found. (Firebase, Adjust and Leanplum libraries were replaced with stubs, so some analyzers can erroneously report their presence in the APK.)
The new UI may break your habits and disappoint you. (IMHO it’s not that bad as one can conclude from reading r/Firefox.)
Android 5.0 or later is now required. Mozilla decided so.
x86 devices are not supported anymore. I stumbled upon linkage errors and gave up. Help is welcome.
The good news is that Fennec F-Droid is alive and continues to be truly free software."I think the perspective is that the distribution shields its users from possible upstream shenanigans (think stories that we used to hear about how popular free and open source Chrome extensions get bought and sold and ended up showing ads on Chrome opening page)
What I find difficult to wrap my head around is that the Debian model (I know other distributions do this as well but just have to give it some name) is very difficult to scale. We basically need maintainers at every single Linux distributions who will (I imagine) go through all the changesets/diffs and painstakingly build the deployable artifacts for their distributions. I can't imagine a single maintainer being able to maintain more than a dozen or so packages and there is a lot of duplicated effort. The Play Store has about three million apps. I know we want to be able to escalate to a human when necessary but I imagine some automation is necessary.
As I write this, I can see the contradiction in what I am asking for... if the store builds, signs, and distributes binaries using the store's credentials but cannot vouch for the quality of the application. ...
I was just thinking that if the app stores had access to the source code and the build instructions maybe that would help somehow but I didn't think it through.
For example they can simply refuse to release/publish anything if the code looks shit/obfuscated. They can explicitly ask questions about sections of code.
But since probably 99.9+% of "app review" is already automated ... likely there's no point in spending resources on creating a "GitHub clone" for submitting code to the various app stores.
Most developers will let Google just generate the keys for them.
Here is a time where having a history of doing the "good and correct" thing would help reassure people that you aren't being nefarious, sadly with the lack of such a history, I don't very many believe anything Google says any more.
It is sad really but there isn't anything App developers can do except leave their platform.
[1] I know, some consider them equivalent.
Lawfull intercept was done on IronChat, PGP-SAFE and Ennetcom that gave direct access to the communication of criminals which are now successfully used in court. In the most recent case, the tacktic of subverting all copies was successfully used by the police to decrypt Sky ECC and get access to .5 billion messages used primarily by criminals.
In this comment [1] regarding Sky ECC the question was raised
> How could I get a court order to get blanket access to Signal?
To which we now know the answer: On Android you don’t, you ask a court order for a list of specific phones you want to listen onto.
I’m baffled that Human Rights & Cilvil Liberty organisations are not standing up more fiercely against the new Play Store policy.
[0] https://news.ycombinator.com/item?id=25940566 https://news.ycombinator.com/item?id=25940670
They might not be aware. Can't hurt to send some of those organizations emails about this.
What is the practical advantage of having apps signed by long-lived keys that were handed to Google without your knowledge over a Google key bundled with the store?
Either way, you keep the same option of installing an alternate store like F-Droid or downloading APKs if you don't trust Google.
Has Google come out with a way to compress string localization information yet? That would make a big difference for apps that support lots of languages, and last I checked (which was a few years ago, so happy to be wrong), Google didn't have a good solution there.
The AAB system criticized in this article will fix your issue too - Play Store delivery will automatically split APKs into per-locale slices and only download languages you need on your device.
How does this work if the user changes the locale on their phone? I guess you need to redownload the APK? I would still prefer compressed localization for all languages, and uncompress the needed one at install/start/sometime if it needs to be mmaped. If the phone locale is changed, uncompress the new one at some point.
> The AAB system criticized in this article will fix your issue too - Play Store delivery will automatically split APKs into per-locale slices and only download languages you need on your device.
Sure. The system fixes a problem Google (or its predecessor, not sure about timing) created, and let linger for over a decade, by handing control of signing keys to Google. Not a great fix. Sure, de facto, Google could patch any app via Play Services which has lots of permissions, but if they control the signing keys, they can more easily meddle.
Files in zip archives can be compressed, but don't have to be. If you compress resource.asrc, there are bad runtime consequences; much worse than the package bloat that results from not compressing it.
What you described is about my understanding of what happens. I would hope it doesn't uncompress the whole thing on every access, but only far enough to read the value; but I'm not sure. Note that it's not just the app itself that uses the app's resources; other elements of the OS use them too.
1) google just sign these apks with their own certs.
2) google should present the developer with a google public key that the developer signs, allowing google to sign an apk with a google key that had a chain of trust to the developer.
This doesn't work if the idea is to dynamically generate APKs for the vast Android ecosystem. In theory they could dynamically upgrade apps to be compatible with future OS versions etc.
However, on older devices that don't support split APKs, Play must compose and sign one custom "fat APK" with all of the stuff specific to your configuration, on the fly. There are a lot of different options for this (you can generate them using bundletool if you're curious). The upload size of all these redundant APKs alone would be a huge burden on developers.
This isn't to say that there couldn't be a way to do APK splitting while maintaining the integrity of the app signing system. My guess is that it wasn't a high priority to do so.
Instead, even outside of Android, we simply cannot know.
they control the keys to the software delivery channel and the operating system. large parts of this are closed source. users and developers trust them and that's just how it is.
that said, it's not pretty and i hope it's just a backwards compatibility stopgap as discussed upthread.
Oh well, they're imposing it upon everyone else.
Google controls what apps are distributed and run on over 40% phones and tablets in the US.
Users deserve the right to know if what they're downloading and installing is what they're supposed to be getting. Developers deserve the right to know that what's shipping to their customers is what they intended. Billions of people are vulnerable if the Play Store's infrastructure gets, or is, compromised, or if its owners or governments decide to do something nefarious.
What's the business reason for Google to not follow Apple in this respect?
Put another way, the percent of total app installs coming from devs who have the resources to run a signing server is likely much higher.
(The version number prevents mix-and-match attacks where e.g. an old vulnerable file is reused in a new APK.)
Google already controls the operating system, the Play Store, and the SDKs you used to develop your app in the first place. If they wanted to alter your app there is already ample opportunity to do so, what additional trust do you gain by managing your own signing key here?
So you tell the OS to "show me this app's signature", and the OS can just lie and show you the expected signature. You want to copy the app to an SD card so you can check it on your Linux PC? The OS can copy the "legal" app.
Also yeah, it seems code signing won't affect anything if the OS wants to be malicious. "Super Secret Messaging App" asks the OS to load encrypt.so, its custom encryption library, and the OS can deliver a no-op library and say "Here it is!". The app wants to check the file's hash, the OS can intercept the hash method's return value and change it to the expected one...
Google controls Android, but it does not control every other OS and every piece of hardware.
If someone downloads an apk with their own custom Google Play client, running on their own computer, they can check whether it was tampered with. In the past a tampered apk from Google servers would have been signed by wrong key (because the proper key is controlled by developer), pointing to Google as culprit. Now it will be signed by "developer's" key (shared with Google), creating plausible deniability for Google and US intelligence services.
> "Super Secret Messaging App" asks the OS to load encrypt.so, its custom encryption library, and the OS can deliver a no-op library and say "Here it is!". The app wants to check the file's hash, the OS can intercept the hash method's return value
This sounds extremely labor-intensive. Who will write all those no-op libraries? Who will pay for it?
As to the labor and cost-intensive issue, the examples mentioned were, what if Google gives up the fight about end to end encryption under regimes that demand it (e.g. China, Australia). There's your answer of who's writing, or at least paying...
Think of the opportunities. Next time Google releases a new social media system they can automatically add it into every existing Android app as a login option!
Google dropping their payment system again? Not a problem, they can just change everyone's billing code.
Or when they do the monthly random feature deprecation on Google cloud they can just modify any code that accessed it, across all apps!
Why bother testing when your app code could be changed at any time by Google. The time and cost savings will be massive.
For those not in the loop about this: https://archive.is/ODWrQ
I think they must have recently changed playback sync to be cloud-first, as jumping back 10s in a video has recently been badly glitching for me both in Chrome and on the iPad app. Often jumps back 20 mins to the start of a video, or where a prior session’s playback had been saved, thereby losing progress you’d made. Not the end of the world but frustrating when you’re watching a lecture and want to catch a detail you just missed. Really breaks continuity.
I’m sure maybe it consolidates implementation making each client simpler and probably satisfies a couple buzzword checkboxes from the business side but why would I possibly trust picking up playback across devices when I can’t trust it on one?
They claim that because Google strips the developer signature and signs it themselves, they can modify the app and re-sign it. They suggest that an authoritarian regime could coerce Google into serving modified versions of eg. E2E encrypted messaging apps to people of that regime’s choice as a condition of doing business there.
Does anyone know if the iOS App Store has the same vulnerability? I know that they do clever things like universal apps and App Clips, but I’m not sure if they achieve it by stripping developer signatures and re-signing. Alternatively, since all signing certificates must be issued by Apple could they technically re-sign any app anyway if they’re coerced into holding onto the private keys they issue? I’ve never written an app in their ecosystem so I’m not sure exactly how it works or if they have an opportunity to do that.
They must be doing some re-signing on their side because the binary you upload is huge and it goes through optimisation on Apple's side so the user has a much smaller download.
With Apple it's a big more of an unknown. In terms of Bitcode, I can't see how Apple could take your binary, "recompile" the Bitcode into a device specific format, whilst still preserving the signature.
From a 2 minute test of an iOS app I work on, I can see that what's downloaded on an M1 Mac has changed quite a bit from what I uploaded. The most obvious thing is the code signature on the binary itself has been replaced with one issued by Apple and isn't the one my build server added.
So yes, Apple is already doing what Google wants to.
Overwriting most core OS files (eg. shared libraries) in a persistent way, even with an exploit, would be difficult since the entire /system and /vendor volumes are signed using the device manufacturer's dm-verity keys.
However, with Android 10+ shipping with APEX modules [0], Google's ability to push core OS changes to existing devices might be changing. I'm not sure if any devices ship with the unflattened (ie. updatable) type of APEX modules yet, but I'd suspect these would be signed by Google instead of the device manufacturer and would be distributed through Google Play.
The move away from developer signing towards Google's signing will makes it harder to detect such event.
Even if one OS component (Google Services) is centrally controlled and can be used to attack you, this does not mean, that you should make other parts less secure. Real-world attacks are complex and backdoors are fragile and prone to being detected. Embedding a backdoor in proprietary code of Google Services is easier than embedding it into AOSP. Hijacking a specific application is easier yet.
You may like it as a power user, but it's essentially a killer for mass adoption.
I.e. once you pass a certain market share and have a larger dev team, wasting your competitor's time by maintaining a high feature addition pace
I'm not saying they aren't good and useful features... to someone. But the net result is that if Google adds more features, quickly, and they're adopted on the web, competitors have to spend more money keeping up, and Chrome becomes more dominant.
So when adding features is a strategic advantage, why would you limit the features you add?
Google appears to be built on the idea of creating a feature or a service, sharing it, making some excitement, and then moving on to the next thing. I think a lot of these concepts are just engineers making things because they can get sign off on it.
I'm not sure. Their official policy is that almost everything should be an add-on. Even things like "don't let random sites install search engines into my browser" should not be a setting, but should be a plugin that works around the browser to make it happen.
Sadly, history has shown that this is completely sustainable. Content creators that burn out will be replaced from among the legion of up-and-comers who are eager for their own shot at the spotlight, and are happy to sacrifice their well-being to do so. If ruthlessly exploiting youthful naivete weren't sustainable, then the games industry would have folded decades ago.
YouTube creators are irreplaceable and wildly unequal in their reach and impact. The issue here isn’t that content creators need a minimum wage, the issue here is that the algorithm needs tweaking. This is possible with regulation, but minimum wage and holiday pay won’t do it, especially since they’re not paid by the hour anyways.
YouTubers would be much better served looking at what NFL players and similar organizations do to protect players rather than what factory workers did to protect themselves, since their labor looks more like sports players rather than service workers.
User installable 3rd party mobile app stores cannot implement automatic upgrades, background installation of apps, or batch installs of apps like the Play Store can. These limitations are designed by Google and are implemented in Android.
If the user tries to install an app on their own, they're shown scary warnings and must adjust arcane settings, but if they use Google's Play Store, no scary warnings are shown and no settings need to be adjusted. They're told they're "protected" by Play Protect, but aren't shown scary warnings about the fact that the Play Store is the main distribution method for malware on Android[1] when they go to install apps with it.
[1] https://www.zdnet.com/article/play-store-identified-as-main-...
Whilst not preventative, even one attack would likely get enough media coverage it'd destroy Android by Google trust irreversibly.
Providing native experience instead of wrapped website.
Google might do this for a lot of reasons, and none of them seem to be good. FWIW, Google promises not to change the functionality of your apps.
Finally, it appears to be the intention that this will justify setting a new norm and become mandatory for all apps.
As a Play Store developer, I give Google the benefit of the doubt. By the way, before you assume a nefarious purpose, consider all Android phones connecting to the Play Store (by definition) have an auto-updating root process. Why does Google need to impersonate an application developer? This is fundamentally why Commonsware scare tactics don't resonate with me, the application has less privileges than the system and the app store, the calls are coming from inside the house!
But, there are more common and mundane reasons. Honestly, a lot of people lose their private signing key. And if that happens, no more updates to your app. By using App Signing, Google can help regenerate a key for you. They want to make this ability consistent across their whole store, that's why they're making the change.
They can also optimize the app bundle the device downloads from the store, as the store will know the target screen size, localization, CPU architecture, etc. The current workflow forces the application engineer to upload separate apk configurations. So this is also an improvement.
That is a feature. If someone cannot do basic diligence of protecting the signing key, should I really trust them for executing code on my machine?
That way, if Google changes the app and signs it, while the author only signed the unchanged app, then the author's signature would no longer validate on the new, changed app.
Or am I missing something?
The issue is that this inherently requires users and developers to trust Google to only make innocuous changes.
Why couldn't Google just ask the developer to sign the modified app after Google makes its changes (which the developer should only do if they approve the changes)?
For app bundles they want to be able to remove unneeded assets and make device specific builds. Think high dpi only. I think ios has a similar feature called app thinning.
really really hoping we are not entering some new capitalist platform control hell, like this article seems to be indicating.
https://www.wnycstudios.org/podcasts/otm/segments/living-und...
Hm, I'm sympathetic to where people are coming from. Treating Apple Apps as a distinct market from Android Apps doesn't feel technically true, but I think it's more then true enough.
More generally I think people have a sense of what fair play is and how large companies shouldn't be as free to throw their weight around, laws be dammed. And that whole feeling gets lumped under monopoly.