Hacker News Reader

Comment by londons_explore | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com