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

121–130 of 152 posts

Re: Google I/O 2021 and Uncomfortable Questions

#121

Post by tehlike »

corty wrote: post #109
Krssst wrote: post #89

Earlier quoted context omitted.

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…

Just root your device. root is needed anyways e.g. for proper backups.

Prevents mass adoption, gives competitors really big hurdle to get over.

Re: Google I/O 2021 and Uncomfortable Questions

#122

Post by iudqnolq »

thu2111 wrote: post #119
iudqnolq wrote: post #99

Earlier quoted context omitted.

It's silly, because if you control the OS you control the app. They can push an OS or trusted app update that reads/writes the app's private data, or changes the shared libraries the app depends on, or with a little more work reads/writes the app's memory. Anyone claiming to provide protection from Google on a phone Google has remote root access to is selling a theatrical experience.

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.

Re: Google I/O 2021 and Uncomfortable Questions

#123

Post by jayd16 »

pas wrote: post #104
jayd16 wrote: post #60

Earlier quoted context omitted.

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

Why? They control the Play app itself anyway. Isn't verification done by the privileged "Google Play Services" special background service? Which is basically the userspace, which is where Google pushes security updates (because carriers and phone makers don't).

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

Re: Google I/O 2021 and Uncomfortable Questions

#124

Post by chedabob »

lrem wrote: post #113
chedabob wrote: post #108

Earlier quoted context omitted.

Apple issue the certificate but you never supply them with the private key. There's nothing stopping them from issuing a certificate with their own key though. It's not like Android where the signing key has to match otherwise apps can't be updated (amongst other things). They must be doing some re-signing on their side because the binary you upload is huge and it goes through optimisation on Apple's side so the user…

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 format, whilst still preserving the signature.

From a 2 minute test of an iOS app I work on, 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.

Re: Google I/O 2021 and Uncomfortable Questions

#125

Post by altfredd »

bellyfullofbac wrote: post #112
prepend wrote: post #47

Earlier quoted context omitted.

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

I don't want to defend Google here, but in theory, since Google controls the OS, it can also make it lie to you. So you tell the OS to "show me this app's signature", and the OS can just lie and show you the expected signature. You want to copy the app to an SD card so you can check it on your Linux PC? The OS can copy the "legal" app. Also yeah, it seems code signing won't affect anything if the OS wants to be malic…

> in theory, since Google controls the OS, it can also make it lie to you

Google controls Android, but it does not control every other OS and every piece of hardware.

If someone downloads an apk with their own custom Google Play client, running on their own computer, they can check whether it was tampered with. In the past a tampered apk from Google servers would have been signed by wrong key (because the proper key is controlled by developer), pointing to Google as culprit. Now it will be signed by "developer's" key (shared with Google), creating plausible deniability for Google and US intelligence services.

> "Super Secret Messaging App" asks the OS to load encrypt.so, its custom encryption library, and the OS can deliver a no-op library and say "Here it is!". The app wants to check the file's hash, the OS can intercept the hash method's return value

This sounds extremely labor-intensive. Who will write all those no-op libraries? Who will pay for it?

Re: Google I/O 2021 and Uncomfortable Questions

#126

Post by remram »

jayd16 wrote: post #123
pas wrote: post #104

Earlier quoted context omitted.

Why? They control the Play app itself anyway. Isn't verification done by the privileged "Google Play Services" special background service? Which is basically the userspace, which is where Google pushes security updates (because carriers and phone makers don't).

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.

Re: Google I/O 2021 and Uncomfortable Questions

#127

Post by altfredd »

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.

This isn't about Google's control over OS. Of course, Google fully controls Android it, so they can compromise it anytime. But if such compromise gets detected, Google will lose trust.

The move away from developer signing towards Google's signing will makes it harder to detect such event.

Re: Google I/O 2021 and Uncomfortable Questions

#128

Post by iudqnolq »

altfredd wrote: post #127
iudqnolq wrote: post #122

Earlier quoted context omitted.

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.

This isn't about Google's control over OS. Of course, Google fully controls Android it, so they can compromise it anytime. But if such compromise gets detected, Google will lose trust. The move away from developer signing towards Google's signing will makes it harder to detect such event.

My argument is that a hypothetical compromise of an app never gives google more power than they could hypothetically have now. I also don't see why it would be harder to detect. Why do you think that's the case?

Re: Google I/O 2021 and Uncomfortable Questions

#130

Post by SimeVidas »

EvilEy3 wrote: post #95
SimeVidas wrote: post #83

Web apps have become so powerful on Android lately. What good reasons are there to still go native today?

> What good reasons are there to still go native today? Providing native experience instead of wrapped website.

You’re an idiot.
Post reply on HN