Google I/O 2021 and Uncomfortable Questions • Hacker News Board

Re: Google I/O 2021 and Uncomfortable Questions

#141

Post by toast0 » Mon, May 03, 2021, 12:06 AM UTC

grishka wrote: post #139

toast0 wrote: post #131

Earlier quoted context omitted.

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?

Yes. Take a random apk and look at it with a zip lister. If resource.asrc is compressed, someone didn't use the SDK tools to build it (and I'd be shocked).

What you described is about my understanding of what happens. I would hope it doesn't uncompress the whole thing on every access, but only far enough to read the value; but I'm not sure. Note that it's not just the app itself that uses the app's resources; other elements of the OS use them too.

Re: Google I/O 2021 and Uncomfortable Questions

#142

Post by jayd16 » Mon, May 03, 2021, 12:12 AM UTC

remram wrote: post #137

jayd16 wrote: post #133

Earlier quoted context omitted.

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?

That would delete any local files the app might have written, save files, that sort of thing.

Re: Google I/O 2021 and Uncomfortable Questions

#143

Post by bellyfullofbac » Mon, May 03, 2021, 12:15 AM UTC

altfredd wrote: post #125

bellyfullofbac wrote: post #112

Earlier quoted context omitted.

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…

Yes I'm aware of why giving Google our signing keys is a stupid policy...

As to the labor and cost-intensive issue, the examples mentioned were, what if Google gives up the fight about end to end encryption under regimes that demand it (e.g. China, Australia). There's your answer of who's writing, or at least paying...

Re: Google I/O 2021 and Uncomfortable Questions

#144

Post by altfredd » Mon, May 03, 2021, 2:40 AM UTC

iudqnolq wrote: post #128

altfredd wrote: post #127

Earlier quoted context omitted.

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?

This is a slippery slope fallacy. Your government has enough power to detain and execute you. Does that mean, that you should give them even more power?

Even if one OS component (Google Services) is centrally controlled and can be used to attack you, this does not mean, that you should make other parts less secure. Real-world attacks are complex and backdoors are fragile and prone to being detected. Embedding a backdoor in proprietary code of Google Services is easier than embedding it into AOSP. Hijacking a specific application is easier yet.

Re: Google I/O 2021 and Uncomfortable Questions

#145

Post by ashtonkem » Mon, May 03, 2021, 5:12 AM UTC

intricatedetail wrote: post #118

kibwen wrote: post #49

Earlier quoted context omitted.

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

It should be regulated. Creators for all intents and purposes are employees of YouTube and should at least be paid minimum wage, get holidays and sick pay. It's time YT gets Ubered.

Such systems will always work much better for undifferentiated labor than specialized labor. Uber’s workers need protection because they’re so replaceable; anyone with the same class of car in the same city can replace them.

YouTube creators are irreplaceable and wildly unequal in their reach and impact. The issue here isn’t that content creators need a minimum wage, the issue here is that the algorithm needs tweaking. This is possible with regulation, but minimum wage and holiday pay won’t do it, especially since they’re not paid by the hour anyways.

YouTubers would be much better served looking at what NFL players and similar organizations do to protect players rather than what factory workers did to protect themselves, since their labor looks more like sports players rather than service workers.

Re: Google I/O 2021 and Uncomfortable Questions

#146

Post by UncleMeat » Mon, May 03, 2021, 12:23 PM UTC

remram wrote: post #137

jayd16 wrote: post #133

Earlier quoted context omitted.

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?

Yes, but that destroys cached and local data and isn’t compatible with built in apps using the same package name.

Re: Google I/O 2021 and Uncomfortable Questions

#147

Post by remram » Mon, May 03, 2021, 7:38 PM UTC

jayd16 wrote: post #134

codeflo wrote: post #115

Earlier quoted context omitted.

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.

Is it? They control the store, which can install apps remotely, and most developers are handing them their private keys for convenience. You also have to trust that Google gave you the right one every time you install a new app.

What is the practical advantage of having apps signed by long-lived keys that were handed to Google without your knowledge over a Google key bundled with the store?

Either way, you keep the same option of installing an alternate store like F-Droid or downloading APKs if you don't trust Google.

Re: Google I/O 2021 and Uncomfortable Questions

#148

Post by dang » Wed, May 05, 2021, 4:47 AM UTC

SimeVidas wrote: post #130

EvilEy3 wrote: post #95

Earlier quoted context omitted.

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

You’re an idiot.

Whoa, you can't do this here and we ban accounts that do. No more of this, please.

https://news.ycombinator.com/newsguidelines.html

Re: Google I/O 2021 and Uncomfortable Questions

#149

Post by SimeVidas » Wed, May 05, 2021, 6:48 AM UTC

dang wrote: post #148

SimeVidas wrote: post #130

Earlier quoted context omitted.

You’re an idiot.

Whoa, you can't do this here and we ban accounts that do. No more of this, please. https://news.ycombinator.com/newsguidelines.html

> Don't be snarky.

> Eschew flamebait.

> don't post shallow dismissals

Will you also ban the other person for being snarky and all the other things I quoted? If yes, then I’m fine with a dual ban.

Re: Google I/O 2021 and Uncomfortable Questions

#150

Post by dang » Wed, May 05, 2021, 7:22 AM UTC

SimeVidas wrote: post #149

dang wrote: post #148

Earlier quoted context omitted.

Whoa, you can't do this here and we ban accounts that do. No more of this, please. https://news.ycombinator.com/newsguidelines.html

> Don't be snarky. > Eschew flamebait. > don't post shallow dismissals Will you also ban the other person for being snarky and all the other things I quoted? If yes, then I’m fine with a dual ban.

First, I'm not banning anyone, I'm saying that we ban accounts that do this kind of thing repeatedly, so please don't.

Second, I don't see that https://news.ycombinator.com/item?id=27013656 was snarky or did those other things.

Third, it's distasteful to point the finger at the other person instead of simply taking responsibility for your actions.

Why not just use HN as intended? If another commenter is wrong or you feel they are, the way to respond is with correct information, neutrally and respectfully. If you don't want to do that, not responding at all is the other good option.

To a first approximation, the internet is wrong about everything anyhow, so for sanity's sake we all need to learn how to let go. Believe me, I know that's not easy, but it's what we all have to do if we want a forum that doesn't suck.