Live data from Hacker News

Google I/O 2021 and Uncomfortable Questions

commonsware.com

41–50 of 152 posts

Re: Google I/O 2021 and Uncomfortable Questions

#41
post #8

Earlier quoted context omitted.

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?

Well, with Android's walled garden, competitors outside of it are not allowed to compete on a level playing field with the Play Store.

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

Re: Google I/O 2021 and Uncomfortable Questions

#43
post #20

Earlier quoted context omitted.

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

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

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

Re: Google I/O 2021 and Uncomfortable Questions

#44
post #22

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.

Right, to be more accurate I should have said that the feature as designed requires trusting Google.

Re: Google I/O 2021 and Uncomfortable Questions

#45
post #13
post #8

Earlier quoted context omitted.

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…

I don’t think it’s so malicious. I think they just see a feature they’d like in the browser, and add it.

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.

Re: Google I/O 2021 and Uncomfortable Questions

#46

Earlier quoted context omitted.

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?

Well, with Android's walled garden, competitors outside of it are not allowed to compete on a level playing field with the Play Store. 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 o…

Continuing with the actual garden analogy, that's like trying to compete with the garden itself by planting your own flowers and the garden making it ugly with weeds. The point Apple and Google are making is that Google's walled garden is Android, as Apple's walled garden is iOS, and the app stores are simply features of those products, and thus to compete with them you need to compete with the entire product. And whether or not that's actually the case is currently being decided in Epic v Apple.

Re: Google I/O 2021 and Uncomfortable Questions

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

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

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

Re: Google I/O 2021 and Uncomfortable Questions

#48
post #43

Earlier quoted context omitted.

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

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

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

Re: Google I/O 2021 and Uncomfortable Questions

#49
post #8

Earlier quoted context omitted.

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.

Every content creator I follow seems pretty desperate to get away from YouTube. Creating a system where critical content creators are rewarded by an algorithm that requires burnout behavior continually does not seem like a long term stable business design.

> Creating a system where critical content creators are rewarded by an algorithm that requires burnout behavior continually does not seem like a long term stable business design.

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.

Re: Google I/O 2021 and Uncomfortable Questions

#50

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

Cause either you blindly sign it blindly or ??
Post reply on HN