Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google I/O 2021 and Uncomfortable Questions

commonsware.com

Post reply on HN
Print view View original

51–60 of 152 posts

Re: Google I/O 2021 and Uncomfortable Questions

#51

Post by jayd16 »

aesh2Xa1 wrote: post #36
a-dub wrote: post #25

Earlier quoted context omitted.

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.

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.

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

Re: Google I/O 2021 and Uncomfortable Questions

#52

Post by encryptluks2 »

corty wrote: post #2

Google Playstore is a walled garden, like Apple's. The walls are only growing higher and higher. Once Apple adds a layer of bricks, Google follows and vice versa.

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.

Re: Google I/O 2021 and Uncomfortable Questions

#53

Post by ChuckMcM »

est31 wrote: 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…

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.

Re: Google I/O 2021 and Uncomfortable Questions

#54

Post by kwyjobojoe »

Given that Google has a history of accidentally breaking things in YouTube that only impacts Firefox, I'm 100% certain they can be trusted to muck around in apps written by others.

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.

Re: Google I/O 2021 and Uncomfortable Questions

#55

Post by rodgerd »

ChuckMcM wrote: post #53
est31 wrote: 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…

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…

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

Re: Google I/O 2021 and Uncomfortable Questions

#56

Post by benburton »

vnchr wrote: post #34
HDMI_Cable wrote: post #15

Earlier quoted context omitted.

I don’t want to be pedantic, but it would be more apt to say: “Apple and Google, the US Steel and Standard Oil of our era” since Apple doesn’t own Google.

That is quintessentially pedantic. Aside from that, thank you for the trivia.

This is my favorite thing I've read today.

Re: Google I/O 2021 and Uncomfortable Questions

#57

Post by jayd16 »

pmoriarty wrote: post #5
_hyn3 wrote: 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…

Wouldn't a simple solution to this be a double signing of one and the same app by both Google and the app's author? 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?

What would be the point if Google's signature would still validate. If an author wants to share an app with a different signature outside the appstore they can.

Re: Google I/O 2021 and Uncomfortable Questions

#58

Post by tdeck »

jayd16 wrote: post #37
est31 wrote: 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…

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

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.

Re: Google I/O 2021 and Uncomfortable Questions

#59

Post by jayd16 »

detaro wrote: post #22
teraflop wrote: post #12

Earlier quoted context omitted.

The whole point of this feature is to allow Google to modify the APK by stripping out unneeded resources to reduce file size. If you require both a signature from Google and a signature from the developer, the modified versions would not pass validation. The issue is that this inherently requires users and developers to trust Google to only make innocuous changes.

If it's just "sign a thing, but allow some parts to be crossed out later while still being able to verify the signature", that's not that difficult to implement.

This would completely change the signing structure but its feasible. Doesn't work for splitting files but maybe that's ok. I think BlackBerry would have you sign every file in a build but man was that a pain in the ass. It took forever for some reason.

Re: Google I/O 2021 and Uncomfortable Questions

#60

Post by jayd16 »

remram wrote: post #24
est31 wrote: 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…

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.

This solution is backwards compatible. Changing the installation verification process is not.
Post reply on HN