Chrome Updater May Cause Mac Slowness

Is it fixed quitting Chrome? I mean, does it happen when Chrome is opened only? Thanks!

The consensus on HN seems to be that this is a bunch of baloney. Nobody can even reproduce the issue. Is there anything to support this, besides the author's pedigree?

Whether or not Google's Keystone thingy slows down your Mac, you still might not like having what amounts to Google spyware running on your computer all the time, and silently updating software in the background. See the below link for a thorough guide to removing Keystone, and using the command line to ensure that it doesn't auto-reinstall itself.

You can still use Chrome if you remove Keystone; to ensure you still get the required security updates for Chrome you'll still have to remember to manually update it every so often...

https://www.imore.com/how-stop-googlesoftwareupdateapp-trying-run-your-mac

>you still might not like (...) silently updating software in the background

I think this is one of these ideas that we have to give up on. It's *good* for web browsers to silently auto-update. I get that it is annoying that this is required, and it feels like you're losing some amount of control over your computer, but this is one of these situations where it's just not a good idea to try to remember to manually install all security updates.

Is it fixed quitting Chrome? I mean, does it happen when Chrome is opened only?

No. Keystone, the background update agent from Google, runs regardless of whether Chrome is open. This is to minimize the window where you’re running a potentially outdated version of Chrome with, perhaps, critical security issues.

(Of course, they could achieve the same effect by always checking for updates before Chrome itself actually launches, but that would make launching Chrome slower. So, it’s a UX trade-off.)

Note that “runs regardless” doesn’t mean “is always running”. Instead, it launches about once an hour (and will almost always be done running after a moment).

The consensus on HN seems to be that this is a bunch of baloney. Nobody can even reproduce the issue. Is there anything to support this, besides the author’s pedigree?

Rambo’s deep dive seems fairly good.

you still might not like having what amounts to Google spyware running on your computer all the time

See, I take issue with the description of “spyware”, or Loren’s as “basically malware”.

If there is evidence that it collects data that it shouldn’t, sure, one might call it spyware. I haven’t really seen that here, though. As for malware? What Loren seems to be saying is that there’s a severe bug in it. He doesn’t actually substantiate the causal relationship between his WindowServer CPU usage and Keystone much. There could be such a bug, but there could be quite a few other explanations. And even if that bug does exist, it strikes me as a leap to go from that to Google maliciously using your CPU resources. Buggy software isn’t malware. Malicious software is malware.

I get that it is annoying that this is required, and it feels like you’re losing some amount of control over your computer

FWIW, Microsoft handles this better, IMO. They default to automatic updates, yes, but you can manually run AutoUpdate to configure that behavior. It’s a simple, friendly UI that also makes it clear what it’s for, whereas “Keystone” has basically no UI at all and is an obtuse name (you could argue that for Sparkle as well, but Sparkle’s UI makes it clear what it’s for). It’s not a huge difference, but it’s big enough to fend off the idea of spying or malice.

I just think that this is one instance where probably you shouldn't be able to turn off auto-updates at all. If you install a browser, you should be obligated to also install updates, up to the point where you uninstall that browser again.

"s it fixed quitting Chrome? I mean, does it happen when Chrome is opened only?"

"No. Keystone, the background update agent from Google, runs regardless of whether Chrome is open. This is to minimize the window where you’re running a potentially outdated version of Chrome with, perhaps, critical security issues.
(Of course, they could achieve the same effect by always checking for updates before Chrome itself actually launches, but that would make launching Chrome slower. So, it’s a UX trade-off.)"

Could such updates be prevented with firewalls like Little Snitch?

@MeX At one point it was hard to use Little Snitch for this because Keystone used a different randomized path at each launch. Perhaps that is fixed now because Gwynne Raskind says she was using Little Snitch, and wondered whether that might be causing the problem.

Lukas: "It's *good* for web browsers to silently auto-update."

Granted, but Chrome only replaces its own binary when it's restarted, right? It doesn't need a background process for this. The Mac has other update mechanisms that work just fine and don't require each app to run its own background process.

And Sparkle never had a bug that stopped Macs from booting.

No, I don't think it is "Good" for software to update itself without user intervention, unless, and only unless, it provides an interface to restore an older version. Your "upgrade" might be a real downgrade for some of your users.

Too many software developers assume that forcing others to update to the latest and greatest is best. But that breaks actual users' workflows. That new web browser often will require a new OS which breaks all sorts of existing tools. In the last 15 years the following types of apps all had to be rewritten: Carbon based, 32-bit based, CUDA based, PowerPC based, soon x86 based tools. Each time a new OS comes out, valgrind, haskell, and other useful tools need to be "fixed". I know it comes as a shock, but people actually use their computers for real work, and a lot of that software isn't "App Store Ready".

Loren on twitter.com, Dec 12: "Google Chrome was making everything on my computer slow"

Loren on bugs.chromium.org, Dec 14 (39 minutes after being asked to provide evidence): "I can no longer reproduce"

Twitter is great for spur-of-the-moment rants. Not so much for facts. We've seen a lot of that this year.

>Your "upgrade" might be a real downgrade for some of your users

Just to make this clear, I never intended to imply that auto-upgrading browsers had no downsides. My point was rather that the potential issues caused by not auto-upgrading browsers vastly outweigh the potential inconvenience of something breaking after an upgrade. Browsers *must* auto-upgrade, and they *must not* allow users to disable this, or easily revert to an earlier version.

Almost every time Google releases a Chrome update that fixes security vulnerabilities, these vulnerabilities are actively exploited within days. It's not safe to not immediately update browsers. Even with safe browsing habits (legitimate sites are sometimes exploited), even with JavaScript turned off (the attack vector is usually not in the JS sandbox, but often something like a font rendering engine bug).

I do agree that browsers should give users the option of only auto-upgrading when the browser is actually started, though, instead of running a background thread at all times.

Could such updates be prevented with firewalls like Little Snitch?

In addition to Michael’s answer: the (presumed) issue isn’t actually installing the updates, but rather having a process running that checks for them.

Preventing updates with firewalls might, as Michael said, even be counterproductive in that the process now keeps trying for a while, causing even more resource usage.

Granted, but Chrome only replaces its own binary when it’s restarted, right? It doesn’t need a background process for this.

Right. I presume Google doesn’t want the subpar UX of having to wait a while longer when launching Chrome after an update.

Too many software developers assume that forcing others to update to the latest and greatest is best.

While I agree with this sentiment in general (I make enterprise software, and I’m always both mildly amused and concerned about JS frameworks going in and out of style on an almost weekly basis, whereas I have software running with few patches from literally the late 2000s), I don’t think it applies to web browsers.

Even the option of “just install security patches; don’t change the features” isn’t very practical, as the web is such a fast-evolving problem. (Of course, that, in turn, is largely on Google themselves. They want it that way. For better or worse.)

Twitter is great for spur-of-the-moment rants. Not so much for facts. We’ve seen a lot of that this year.

I wouldn’t draw the conclusion that, because he cannot reproduce it, that there was no issue. Gwynne’s theory Michael pointed to seems like a plausible explanation, for example.

>FWIW, Microsoft handles this better

Funny, I could never figure out how to turn off Microsoft Autoupdate on my Mac, despite selecting every option to disable it / update manually only. Damn thing had a mind of its own.

I suspect the issue is with macOS. People are reporting high CPU usage on all kinds of apps, and I suspect that Windowserver, metal, or some other subsystem is to blame vs. one specific app.

Since updating to Big Sur, my 2014 15" MBP with dedicated GPU (fastest MBP you could buy that year) gets constant errors in Console saying drivers not found, for both the integrated Intel GPU as well as the NVIDIA. For example:

Jan 21 13:24:20 Jasons-MacBook-Pro com.apple.WebKit.WebContent[3991]: getattrlist failed for /Library/GPUBundles/GeForceVADriver.bundle/Contents/MacOS/GeForceVADriver: #2: No such file or directory

Feb 6 20:21:57 Jasons-MacBook-Pro MTLCompilerService[20064]: getattrlist failed for /Library/GPUBundles/AppleIntelGraphicsShared.bundle/Contents/Resources/runtime.igil64.split: #2: No such file or directory

Feb 6 06:32:34 Jasons-MacBook-Pro VLC[13995]: getattrlist failed for /System/Library/Extensions/AppleIntelHD5000GraphicsGLDriver.bundle/Contents/MacOS/AppleIntelHD5000GraphicsGLDriver: #2: No such file or directory

Could it be that my machine is having to revert to some lower-performing 'safe mode' style display mode?

Another thought, and this is kind of a stab in the dark, but perhaps firmware updates for some of the I/O components in the chipsets throttled things. Could be a security patch to blame, as most Intel CPU's had to have performance boosting features disabled due to security issues baked in the hardware. Could be CPU or chipset firmware updates to correct this have throttled performance? Who knows.

But basically it seems like everyone is complaining about performance issues with macOS right now, so something's definitely up, and it doesn't appear that Apple has figured things out yet. And neither have I.