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