Live data from Hacker News

Google I/O 2021 and Uncomfortable Questions

commonsware.com

81–90 of 152 posts

Re: Google I/O 2021 and Uncomfortable Questions

#81
post #6

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 s…

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.

Re: Google I/O 2021 and Uncomfortable Questions

#82
post #3

tldr: Google's new app bundle signing might be a precursor (well, almost certainly is) to Google's being able to replace parts of and modify your app on the fly when installed by certain targeted users or within certain targeted countries at Google's whim, with users being none the wiser. 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…

> Google might do this for a lot of reasons, and none of them seem to be good.

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.

Re: Google I/O 2021 and Uncomfortable Questions

#84
post #79

Earlier quoted context omitted.

They are very different. Google provides open source alternatives. On Linux I can use Chromium. On my Android I can install F-Droid, or just install APKs manually.

But you cannot do unattended updates through fdroid.

sounds like a good feature to me

Re: Google I/O 2021 and Uncomfortable Questions

#86
post #32
post #6

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 s…

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.

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.

Re: Google I/O 2021 and Uncomfortable Questions

#87

Earlier quoted context omitted.

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.

> 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 o…

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?

Re: Google I/O 2021 and Uncomfortable Questions

#88
post #71
post #48

Earlier quoted context omitted.

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

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

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

Re: Google I/O 2021 and Uncomfortable Questions

#89
post #79

Earlier quoted context omitted.

But you cannot do unattended updates through fdroid.

sounds like a good feature to me

If you want to update all your F-Droid apps at once on a non-rooted Android, you need to go through all of them one by one. Basically: click upgrade, click "Install", wait for Android to do its stuff, do the same for the next app. It is extremely impractical and most of the apps I installed from F-Droid are severely out of date because of this Android restriction. Fortunately F-Droid has an "Upgrade all" button which will download all the APKs in the background, but the click&wait loop sequence cannot be avoided.

Re: Google I/O 2021 and Uncomfortable Questions

#90
The article linked from this one is worth a read: https://commonsware.com/blog/2020/09/23/uncomfortable-questi...

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.

Post reply on HN