[est31]

App bundles allow smaller apk sizes [0]:

> 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.

[0]: https://developer.android.com/guide/app-bundle

[josephg]

Piling on here, thats super weird.

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.

[nodamage]

> 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.

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.

[mcny]

> IIRC this is how it works by default for new apps.

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?

[Iolaum]

The F-Droid ecosystem is also working towards reproducible builds[0] so you can have more verification options for what you, as a user, received.

Not sure how that would work with a proprietary app store like Play store.

[0]: https://f-droid.org/en/docs/Reproducible_Builds/

[m4rtink]

BTW, with F-Droid does is basically the same what major Linux distros do - build everything from source on trusted infrastructure.

[ce4]

The model also shields to a certain extent against conflict of interests (the product is the user, i.e. ads/tracking/hostile maintainership takeover)

[izacus]

> The model also shields to a certain extent against conflict of interests (the product is the user, i.e. ads/tracking/hostile maintainership takeover)

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.

[mcny]

> The model also shields to a certain extent against conflict of interests (the product is the user, i.e. ads/tracking/hostile maintainership takeover)

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.

[soarfourmore]

It’s even weirder that Google’s security engineers would sign off on such a design. I am astounded

[UncleMeat]

The signing keys are more important for the security model of the device than for people to confirm that an apk was actually created by a particular corporation. Every single android user makes use of the former feature. There are 1B+ android users. I'd wager that well under 10,000 have ever checked the signature on an apk file themselves.

Most developers will let Google just generate the keys for them.

[ChuckMcM]

It is one of those situations where the excuse is really out there and much more complicated than the simple, "we 'need' the ability to modify your app before it ships." Since the article gives a plausible scenario where that would occur (could be totalitarian regime, could be an NSL letter from the FBI[1])

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.

[rodgerd]

Yes, I think this will be the way that Google satisfy e.g. the Australian government's mandate to aid intelligence and law enforcement agencies to surveil in a targeted way. Not "everyone gets a subverted copy of Signal", but "these three people get a subverted copy of Signal."

[smartbit]

And also the European anti-encryption proposals [0]

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

[1] https://news.ycombinator.com/item?id=26468437#26483634

[heavyset_go]

> I’m baffled that Human Rights activists & Cilvil Liberty organisation are not standing up more fiercely against the new Play Store policy.

They might not be aware. Can't hurt to send some of those organizations emails about this.

[saurik]

It isn't just a "fear": Google has said that new apps submitted after August must use this feature.

[remram]

It's just a little bit weird that Google designed the Play Store and Android with key signing if they then have to ask for those keys. They control the OS and the store, couldn't they just make devices trust Google's app-repackaging-service's key? This would be easier for everyone, and more honest for the consumer user who gets packages signed by whoever actually built it.

[jayd16]

This solution is backwards compatible. Changing the installation verification process is not.

[pas]

Why? They control the Play app itself anyway. Isn't verification done by the privileged "Google Play Services" special background service? Which is basically the userspace, which is where Google pushes security updates (because carriers and phone makers don't).

[jayd16]

Signatures are verified at the OS level, outside the playstore. Even if you side load apps, signatures are checked for consistency.

[remram]

I'm not suggesting we remove signing, just that Google use their own signing key for apps they build.

[jayd16]

That won't work. For google to take over the signing of existing apps they need the existing keys.

[codeflo]

So Google’s inability to update Android causes them to compromise on its security?

[jayd16]

Google imposing their own root keys on every device seems like a much much bigger overreach than wanting to repackage apps in their store.

[remram]

Is it? They control the store, which can install apps remotely, and most developers are handing them their private keys for convenience. You also have to trust that Google gave you the right one every time you install a new app.

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.

[toast0]

Smaller apks are great, but throwing away the security model to get smaller apks really isn't. :(

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.

[izacus]

There's support for APK splits by locale, where you can upload a separate APK for each language which keeps the size down.

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.

[toast0]

> There's support for APK splits by locale, where you can upload a separate APK for each language which keeps the size down

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.

[grishka]

Apks are zip archives. So, naturally, everything they contain is already compressed.

[toast0]

Not resource.asrc

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.

[grishka]

Are you saying that the SDK tools that build apks (aapt? I'm not sure) only compress files selectively? And what kinds of consequences are there if you do compress resources.arsc? I suppose it never keeps a copy in memory but reads it a lot, and if it's compressed, you're taking a performance penalty from it having to decompress the whole thing on every access?

[toast0]

Yes. Take a random apk and look at it with a zip lister. If resource.asrc is compressed, someone didn't use the SDK tools to build it (and I'd be shocked).

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.

[willvarfar]

I know nothing about the real situation, but commenting off the cuff based on what I read here, it sounds like either:

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.

[jayd16]

>a service where Google presents you an apk, and you sign it.

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.

[tdeck]

To add some more context on this, when you provide an app bundle the Play server looks at your device's display size, density, OS version, and architecture. If your OS version is new enough (L+ I believe), it can send you a bunch of split APKs. That means one big APK with DEX code, one with just the armeabi-v8a native code, one with just English translations, one with just xxhdpi assets, etc... In theory a developer could build all these split APKs, sign them, and upload them to Play.

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.

[a-dub]

it doesn't matter, they could just push an android update that bypasses your signature if they really wanted to. granted that's a bigger deal, but they control the ecosystem in google play and hold the signing keys for android and google play itself, you already trust them.

[aesh2Xa1]

If the only person with the signing key is the author, then any user could verify the signature outside of Android, could they not?

Instead, even outside of Android, we simply cannot know.

[nodamage]

Except verifying outside of Android tells you nothing about whether the application as installed on an actual device has been tampered with, so you don't really gain any security from this.

[a-dub]

they could push an update that makes it appear like the author signed version is on the device, but in reality a different version is run.

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.

[jayd16]

If you're allowed to verify outside of Android, the author could simply post hashes.

[judge2020]

I seriously doubt 99% of Google Play developers worry enough that they would take the time and money to run a signing server, and that would introduce a lot of complexity for Google.

[heavyset_go]

> that would introduce a lot of complexity for Google

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.

[izacus]

Users, right now, are quite happy trusting Apple (paragon of privacy and security) and F-Droid (the main opensource store) with signing their apps for them, so there doesn't seem much reason for Google to waste extra effort not following them.

What's the business reason for Google to not follow Apple in this respect?

[Andrew_nenakhov]

Trust is matter based on reputation, and that is why users generally trust F-Droid. Can we trust Google, based on their reputation?

[542458]

The percent of developers is likely small, but that’s the wrong stat, as we don’t care very much about the ~90% of devs that have one or two apps with a handful of downloads. Rather, this is about attacking big targets - a small number of apps with massive numbers of downloads.

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.

[jayd16]

How is an automated signing server better security anyway? Google can still sign what they want but now every dev has a missive security hole in the form a server that can sign code reachable from the open web?

[est31]

As I've mentioned it allows you to audit the generated files. You can run scanners on the result if you want to.

[jayd16]

Couldn't Google obfuscate the changes if they really wanted to?

[tgsovlerkhgsel]

A good workaround could be that you sign a manifest containing all the files and a version number, and Google signs the APK.

(The version number prevents mix-and-match attacks where e.g. an old vulnerable file is reused in a new APK.)

[nodamage]

> Which would give them ability to alter basically any app on the play store as they deem fit.

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?

[prepend]

Isn’t it simply that any changes by Google would clearly not match the developer’s signature so are evident when they are different?

[bellyfullofbac]

I don't want to defend Google here, but in theory, since Google controls the OS, it can also make it lie to you.

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...

[altfredd]

> in theory, since Google controls the OS, it can also make it lie to you

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?

[bellyfullofbac]

Yes I'm aware of why giving Google our signing keys is a stupid policy...

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...

[nodamage]

If the signature does not match that tells you the app was tampered with, but the inverse is not true when your "adversary" controls the compiler, installer, and the operating system itself. Reflections on Trusting Trust (https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...) provides a good explanation as to why.

[grishka]

Also what is this "device configuration" thing exactly? Vector drawables help avoid the issue of having unneeded resources in an apk entirely. You definitely should be using them for icons if you aren't yet. Other resource types, like strings in languages you don't speak or layouts for tablets, are small enough that their impact on the apk size is usually negligible.

[DelightOne]

They could add DRM-features on the fly.