Hacker News Reader

Comment by protomyth | Hacker News Reader

I still don't understand why Google needs to have something more than the basic update functionality that other Mac Apps have via libraries like Sparkle?

View on HN

I think they are very keen to have the ability to give updates very fast in case of a major exploit used in the wild. They want to be able to do all updates worldwide in a few hours, rather than the days or weeks that OS updaters take.

They also want the ability to do rolling updates incase an update is bad. For example, roll this update to up to 1% of users, wait 10 minutes, then roll it out to all users if those 1% don't have worse crash statistics.

It also does diff-based updates, so security patches can be delivered in just a few kilobytes, which is important for all the users on GPRS connections.

Other updaters also don't have the ability to downgrade, either based on the new version failing to start, or based on a message from Google, which might be necessary if an update is bad.

Other update platforms don't let them have fine-grained control and a fast feedback system like that.

The irony here is that by taking more intrusive permissions, they can accidentally do more damage and open up more exploit vectors, for which they'd want to ship an emergency patch, as we see here.

They could use feature flags for the majority of slow roll updates. This would also mitigate the absence of a downgrade mechanism because you can just disable the feature flags. To be fair, I would love to see the App Store feature these types of mechanisms, but Google should request from and/or work with Apple here, not hack around them.

> Google should request from and/or work with Apple here, not hack around them

Or Apple should implement all of those features and reach out to and work with Google so they don't have to hack around anything.

I agree that Apple should do those things, but they can set their own prerogative here. It's their ecosystem. Let the market sort it out, right?

Google is not entitled to anything here, and for a competitor to expect as such is absurd.

Everything you listed there looks very reasonable to me, but aren't these all details that should be supported through a standardised OS-level update mechanism? The reality that the big desktop OSes do not offer those facilities in 2019 says more about the regrettable state of application management on desktop OSes than it does about Google or Chrome.

I think they are very keen to have the ability to give updates very fast in case of a major exploit used in the wild.

What exactly is preventing Chrome from checking for updates / security patches itself (even taking notifications to update) without the use of a launchd agent? Why should any part of a browser be running when I an not using it?

It's so if you screw up and ship a version that crashes, you can still probably be updated. The updater is a tiny piece that only updates, and is itself not updated very often.

It's like an attack surface thing, but the attacker is Murphy and his law.

I don't know their reasoning but here would be mine:

1. Updating when the app isn't running avoids the case where someone opens a link, etc. before it updates. This is probably moot now that most people have it open constantly and are probably using Gmail rather than a standalone mail client.

2. On a multiuser system, the system updater can work when nobody is logged in or the active user doesn't have permissions to install the update.

I think it's a user-experience thing. If a user-level application (eg, browser) discovers an available update, it has to launch a privileged process to update itself - which means an authorisation prompt. And just popping up and asking people for their password without an obvious reason why is bad form, so you usually end up offering to update. It makes the whole process more invasive, less seamless, and more chance people will click no/cancel.

A background agent can do this invisibly; no prompts, no interaction. It's much more seamless, but it does require a bit of arrogance on the developers part - it seems quite silly that every application would have such an agent, so they're self-selected by self-importance.

I would say it goes the other way. Any program better ask me as the owner of the box to elevate to Admin. That is how it works on OS X. Any program that tries to get around this as a "user-experience thing" is a bigger danger than the threat it is protecting against.

They don't do this on Linux, right? Why?

Having to wait for a security update to make it through the various update pipelines of all the different linux distros isn't a great situation for users either.

Installing browsers by hand in your homedir specifically so they can update themselves and you don't rely on the system package manager seems like a fairly widespread recommendation, but maybe I'm talking to a biased set of people.

> you don't rely on the system package manager seems like a fairly widespread recommendation.

Not from me to others using Fedora, the chrome you get via

    dnf install fedora-workstation-repositories

    dnf config-manager --set-enabled google-chrome

Is rapidly updated.

As a general rule I use what is in the repo's unless I absolutely can't or the version in the repo is so old that I can't.

I wrote a post about how Chrome's Linux updates work:

http://neugierig.org/software/chromium/notes/2011/08/zygote....

(Sorry to spam this thread multiple times with this, but it is very relevant.)

I feel your post is answering a different question than what I asked? You're answering "why is our process spawning model so obscure on Linux" rather than "why does Chrome not shove its updates down Linux users' throats out-of-band like it does on every other platform". (Unless you're suggesting the answer is the bit where you say they just didn't want to appear lame?)

That is the answer, yes.

Wow, that is lame.

Thankfully they don't. It's the package manager's job to update packages and the vendor's job to repackage upstream.

There's no reason you can't do all of that with basic user level permissions. A browser shouldn't be screwing with OS files in any significant way (i.e. other than user level settings) to begin with.

To be honest, because they're arrogant. It's the same reason they don't adhere to each OS's UX/UI guidelines (including on Windows!) It's an absolute arrogance that they are "above" these platforms.

> It's the same reason they don't adhere to each OS's UX/UI guidelines (including on Windows!)

To be fair, not even Microsoft does that.

Microsoft does a much better job than Google does.

Well microsofts UI style changes every ~3 years, and they don't restyle old stuff, so at any point in time there are 10 or so possible correct stylings...

Also, it's the same arrogance that makes them push AMP so much. What AMP does is awesome just not how they do it. The wrapper, the URL hijacking, the janky scrolling, no reader view ...etc. It completely breaks my normal flow on my phone that I end up making DDG the primary search provider and Apple News (which is not good at all) as the news aggregator.

it's not just arrogant, it's fraud: https://legal-dictionary.thefreedictionary.com/fraud "A false representation of a matter of fact—whether by words or by conduct, by false or misleading allegations, or by concealment of what should have been disclosed—that deceives and is intended to deceive another so that the individual will act upon it to her or his legal injury."

Asking for admin rights on install - ostensibly for installation purposes only - and then by concealment retaining those rights for other undisclosed purposes without further gaining the consent of the user seems like fraud to me.

But it's also correct to say that this is how the median software vendor typically does business.

Brutally honest but very true.

I try... but living in the valley, and knowing the people at these companies and on these teams... it's just the truth.

I'm a long way from the valley and regard googles behaviour as arrogant in the extreme, they are 1990's era microsoft with better PR, I don't trust them at all and that they seem to have taken control of the web via soft means is worrying as hell.

This is what happens when they systematically hire fresh grads that more keen on solving interview quiz puzzles than actually building good software. This kind of a mess shows a clear lack of seniority leadership.

Where are the industry veterans at Goole?

tbh It's not like other browsers are particularly good at this either. Firefox is just as bad as chrome when it comes to platform UI guidelines.

Google runs a system-level update service on Windows too. The crash handler for it is also running all the time, at least on my machine (and is running with root-equivalent permissions). If you disable it, the next time you launch Chrome they just turn it back on.

It's bizarre. Few vendors do this.

> Google runs a system-level update service on Windows too. The crash handler for it is also running all the time, at least on my machine (and is running with root-equivalent permissions). If you disable it, the next time you launch Chrome they just turn it back on.

> It's bizarre. Few vendors do this.

Please correct me if I am wrong but Adobe Reader has something like this on Windows, right? And so does iTunes?

Even Apple and Adobe don't actively turn their update services back on when you run their applications if you have explicitly disabled them, though, at least not in any version of any of their software that I've come across.

In contrast, it appears that Google installs whatever updates it wants on your system and does turn the related services back on again if you turn them off. It really shouldn't be possible for software to leave that sort of access open without the user's/administrator's explicit consent, but unfortunately the worst offender on this issue is now Microsoft with Windows 10, so I don't hold out much hope that anything will be done about it on Windows platforms any time soon.

Sadly, this just seems to be the price of admission to the modern software world. You have what is effectively a permanent rootkit installed if you want to use the software at all, and even though that is self-evidently incompatible with a robust security and privacy model, when big enough players do it, people just accept it because they don't see that they have any choice.

> Even Apple and Adobe don't actively turn their update services back on when you run their applications if you have explicitly disabled them, though, at least not in any version of any of their software that I've come across.

You can explicitly disable their auto-update mechanisms in the UI, I'm not sure if that's the case for Chrome, but force-closing the GoogleCrashHandler process isn't really comparable to an explicit UI toggle.

Once you've got a culture where it's not your machine, it's just another sensor in Google's panopticon, the idea that Google should do this makes perfect sense.

Agreed, I do and don't want to know what on earth Google was doing with /var that led to this situation in the first place...

My best guess is some sort of botched mkdir -p implementation.

I think Chrome supports allowing an administrator to enable updates by all users, including those who are not administrators.

I've used Sparkle before (as a dev) and it's great, but I'm not sure it does that.

Sparkle works with sandboxed applications, and it doesn't muck around with /var.

But can you put an application in /Applications (requires administrator privileges), then have a non-administrator user run the app and complete an update?

Why is my non-Admin user doing an update? If they are locked down then they are locked down. Other means are probably being used.

Plus, thinking about it, how does Google deal with Carbon Freeze?

Nope, of course not. You will get an admin password prompt.

Right. But Chrome allows you to do that if the administrator has enabled it. To handle that securely, though, would likely require a specifically restricted daemon or setuid process that is well beyond most normal update use cases. And that might explain why they couldn't just use Sparkle.

The point is this shouldn't need to be done. If an administrator has installed an app, then it's the administrator's responsibility to update it. If I want to update an app myself, I'd install it in ~/Applications instead.

Does Chrome ask for your admin password on install? How does Chrome even get permission to modify that /var symlink?

Yes, installing Chrome requires an admin password.

Thanks for directly answering my question.

I think it is fraud to coerce a password out of a user under the pretense of installation and then retain and use admin privileges for other purposes without further user acknowledgement.

> How does Chrome even get permission to modify that /var symlink?

>> The specific conditions required for the Chrome update to make this change are:

>> SIP must be disabled (or not present, as is the case pre-OS X 10.11)

>> The root directory, /, must be writable by the logged-in user

>> ...

Reply on news.ycombinator.com