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

131–140 of 152 posts

Re: Google I/O 2021 and Uncomfortable Questions

#131

Post by toast0 »

grishka wrote: post #100
toast0 wrote: post #32

Earlier quoted context omitted.

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.

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

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.

Re: Google I/O 2021 and Uncomfortable Questions

#132

Post by toast0 »

izacus wrote: post #86
toast0 wrote: post #32

Earlier quoted context omitted.

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.

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

Re: Google I/O 2021 and Uncomfortable Questions

#133

Post by jayd16 »

remram wrote: post #126
jayd16 wrote: post #123

Earlier quoted context omitted.

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

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

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

Re: Google I/O 2021 and Uncomfortable Questions

#134

Post by jayd16 »

codeflo wrote: post #115
jayd16 wrote: post #60

Earlier quoted context omitted.

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

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

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

Re: Google I/O 2021 and Uncomfortable Questions

#135

Post by ce4 »

izacus wrote: post #88
ce4 wrote: post #71

Earlier quoted context omitted.

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

One example would be basic apps and games like flashlights, editors, sudoku, minesweeper, note taking apps etc, of which 95% on the play store are ad/tracking infested. I just skip those and install f-droid's "reccomendation", problem solved. Also: Fennec is great (a rebuild of Mozilla Firefox mobile) and they also offer older versions in parallel (also via their archive). Their Firefox "fennec" build while not being a fork nevertheless has some tweaks, optimizations and brought back addons (via collections, you need to read the whole thread, it's long though), much appreciated:

https://forum.f-droid.org/t/welcome-a-new-fennec-f-droid/111...

    I have just submitted 882 a Fennec update to 81.1.1. Should be available soon™. This version brings a lot of changes, like a new UI and modular codebase. The bad news:

    Mozilla now tracks you even more actively using proprietary 3rd party services. I removed all tracking I found. (Firebase, Adjust and Leanplum libraries were replaced with stubs, so some analyzers can erroneously report their presence in the APK.)
    The new UI may break your habits and disappoint you. (IMHO it’s not that bad as one can conclude from reading r/Firefox.)
    Android 5.0 or later is now required. Mozilla decided so.
    x86 devices are not supported anymore. I stumbled upon linkage errors and gave up. Help is welcome.

    The good news is that Fennec F-Droid is alive and continues to be truly free software."

Re: Google I/O 2021 and Uncomfortable Questions

#136

Post by jayd16 »

est31 wrote: post #102
jayd16 wrote: post #62

Earlier quoted context omitted.

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?

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

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

Re: Google I/O 2021 and Uncomfortable Questions

#137

Post by remram »

jayd16 wrote: post #133
remram wrote: post #126

Earlier quoted context omitted.

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

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

I see, so the limitation is that app updates have to keep using the same key, and that's enforced by the OS? Couldn't the Play Store uninstall then reinstall in that situation, to update to the new key?

Re: Google I/O 2021 and Uncomfortable Questions

#138

Post by chenxiaolong »

iudqnolq wrote: post #122
thu2111 wrote: post #119

Earlier quoted context omitted.

Google do not control the signing keys for Android for any phones other than their own Pixel line. So whilst true in theory, in practice the open source nature of Android with OEMs in the middle distributes the power around.

My impression is to implement things like the Play Store, Google Play Services has effective root access. I can't find any great sources for that though.

With older versions of Android, what Google could do was pretty limited (in terms of messing with the core OS). While Google Play Services has a lot permissions, it all fits into Android's permission model and does not run as root. Package installation is done via communication with the Android framework's PackageManager class and the corresponding /system/bin/installd daemon. Silent installations and automatic updates are also handled via PackageManager using a permission that system apps can obtain.

Overwriting most core OS files (eg. shared libraries) in a persistent way, even with an exploit, would be difficult since the entire /system and /vendor volumes are signed using the device manufacturer's dm-verity keys.

However, with Android 10+ shipping with APEX modules [0], Google's ability to push core OS changes to existing devices might be changing. I'm not sure if any devices ship with the unflattened (ie. updatable) type of APEX modules yet, but I'd suspect these would be signed by Google instead of the device manufacturer and would be distributed through Google Play.

[0] https://source.android.com/devices/tech/ota/apex

Re: Google I/O 2021 and Uncomfortable Questions

#139

Post by grishka »

toast0 wrote: post #131
grishka wrote: post #100

Earlier quoted context omitted.

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

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.

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?

Re: Google I/O 2021 and Uncomfortable Questions

#140

Post by ianlevesque »

chedabob wrote: post #124
lrem wrote: post #113

Earlier quoted context omitted.

Do I understand correctly that Apple is already doing what Google wants to start doing here?

They do something but it's not really comparable to Google's signing system. In the case of Google, developers voluntarily give Google the keys (or have them generated), and it's explicitly clear that Google will take your uploaded APK file and sign it themselves. With Apple it's a big more of an unknown. In terms of Bitcode, I can't see how Apple could take your binary, "recompile" the Bitcode into a device specific…

> I can see that what's downloaded on an M1 Mac has changed quite a bit from what I uploaded. The most obvious thing is the code signature on the binary itself has been replaced with one issued by Apple and isn't the one my build server added.

So yes, Apple is already doing what Google wants to.

Post reply on HN