Live data from Hacker News

Google I/O 2021 and Uncomfortable Questions

commonsware.com

11–20 of 152 posts

Re: Google I/O 2021 and Uncomfortable Questions

#11
post #8
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.

Google has done the same with YouTube to create lock-in for content creators, just like the Play Store. My pet conspiracy theory, they're also doing the same with Chrome browser, by creating as many useless features as possible.

Again, the walled garden has an exit. But why would you leave it when you have to fend for yourself outside of the walls, and everything is given to you on a silver platter within them?

Re: Google I/O 2021 and Uncomfortable Questions

#12
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?

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.

Re: Google I/O 2021 and Uncomfortable Questions

#13
post #8
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.

Google has done the same with YouTube to create lock-in for content creators, just like the Play Store. My pet conspiracy theory, they're also doing the same with Chrome browser, by creating as many useless features as possible.

Chrome adding features is spray and pray monopoly.

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?

Re: Google I/O 2021 and Uncomfortable Questions

#14

Earlier quoted context omitted.

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?

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.

"The whole point of this feature is to allow Google to modify the APK by stripping out unneeded resources to reduce file size."

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)?

Re: Google I/O 2021 and Uncomfortable Questions

#17

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.

"The whole point of this feature is to allow Google to modify the APK by stripping out unneeded resources to reduce file size." 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)?

Presumably the number of different app bundles is large. Otherwise, they could just ask for a apk with each configuration.

Re: Google I/O 2021 and Uncomfortable Questions

#19

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.

"The whole point of this feature is to allow Google to modify the APK by stripping out unneeded resources to reduce file size." 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)?

PITA, most likely. More round trips. More complexity. More work for the user. It also means that the bundling process cannot be improved and you can't extend it to support new configurations without the involvement of the user. There are a bazillion locales and device configurations out there, with more created every day.

Re: Google I/O 2021 and Uncomfortable Questions

#20
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…

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.

Post reply on HN