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.
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.
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.
Google is not entitled to anything here, and for a competitor to expect as such is absurd.
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 like an attack surface thing, but the attacker is Murphy and his law.
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.
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.
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.
Not from me to others using Fedora, the chrome you get via
dnf install fedora-workstation-repositories
dnf config-manager --set-enabled google-chrome
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.
http://neugierig.org/software/chromium/notes/2011/08/zygote....
(Sorry to spam this thread multiple times with this, but it is very relevant.)
To be fair, not even Microsoft does that.
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.
Where are the industry veterans at Goole?
It's bizarre. Few vendors do this.
> 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?
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.
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.
I've used Sparkle before (as a dev) and it's great, but I'm not sure it does that.
Plus, thinking about it, how does Google deal with Carbon Freeze?
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.
>> 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
>> ...