For those of you who are unaware, Comex is one of the most respected security researchers of all time and has done extensive research into Chrome and won Pwn2Own multiple times. He is completely correct, keystone is just Chrome's auto updater. The technical content of this article is super thin. This shouldn't be on the top of hacker news.

The blog post quality is lacking but the comments are interesting.

Oh the good old argument by authority.

The parent did not rely on authority; they posted actual substantive content. Read their comment history.

You can choose to flip off people's qualifications if you want.... but it doesn't make what they say wrong, no matter hooooooowwwww much you don't like it. :)

I remember quite well the Google update process being notorious for evading Little Snitch firewall rules. It popped up every intervall as if it were a new (unseen) process. There's definitely something going on with the app signature. (Haven't used Chrome for some time by now.)

I am curious why that happens. From some Googling it seems like the updater copies itself to a random directory each time it runs [1], and I guess Little Snitch classifies programs by their full path, so it sees it as a new program each time.

Copying itself is odd and probably suboptimal behavior, but it is explainable without assuming malice: my guess is that it’s related to some kind of “before we update let’s update the updater” bootstrapping logic. I could be wrong, but IIRC the updater code is open source, so it should be easy to find out.

[Edit: Oops, it's actually not open source. Their Windows updater (Omaha) is open source, but their Mac one (Keystone) is not. Of course, one can still open the binaries in a decompiler.]

Regardless, moving a program around on disk, or even deleting the program while it’s running (which is possible on macOS), would not prevent it from showing up in Activity Monitor.

[1] http://www.reecefowell.com/2012/11/16/ksfetch-annoyance-on-m...

> my guess is that it’s related to some kind of “before we update let’s update the updater” bootstrapping logic.

However, it happens (happened) specifically, if network access has been denied and there couldn't have been an upadate possibly received.

I think the observation is just out of date now. "Haven't used Chrome for some time by now." At present, Little Snitch does just fine at blocking GoogleSoftwareUpdate.

While it's indeed unlikely that there is deliberately hiding, there is a chance that the google updater triggers something in some (OS-level) components via some (implicit) IPC mechanism that causes load spikes in those components. You'd hardly see any load for the real culprit itself but those other connected components may run hot.

This user says their WindowServer runs hot. Some Chrome-related software may have entered a state where it accidentally DoS'es the WindowServer either due to a bug in google software or a bug in WindowServer that google software triggers, at least in the system configurations particular to this user.

True, that much is possible. But fairly unlikely, especially since Chrome's updater normally does not even pop up a GUI. We'd need stronger evidence than "I deleted some Google stuff and rebooted and now feels faster". I suppose the author did claim to have reproduced it on two computers, but only once each, and with no objective performance measurements. Sadly, there are a lot of things that can make macOS 'randomly' seem slower or faster, especially after rebooting, and with subjective measurements, confirmation bias is a huge factor.

Well, the author is blaming it on the updater kinda, but it could have been chrome itself or the updater might be trying to create a window for whatever purpose in a tight loop or do something else that somehow ends up eventually calling into the WindowServer. There are plenty of things that can go wrong.

I had my own run in with chrome recently where dwm.exe (Desktop Windows Manager on win10) would eat and eat memory until everything OOM'ed. Didn't use much CPU tho. I eventually tracked it down to a single chrome tab that had a specific website open. It's reproducible at least on my system but I haven't yet had the time to look into it more thoroughly. If I had to guess, it was the website making Chrome use some "hardware layers/surfaces" or something like that and cause the corresponding buffers in dwm to be retained forever. No idea if it's a chrome bug or a dwm bug or even some kind of driver bug, and just closing the tab was enough as a "quick fix".

WindowServer CPU before/after is as objective as I've got. I'm convinced there's a fire, but I can only show you the smoke: https://twitter.com/lorenb/timelines/1338892756752732169

For those that didn't measure, it's almost irrelevant — I'm telling you it's not a subtle difference. It's night-and-day.

It's very low on my list of plausible theories, but if there was a hypothetical keystone exploit, what is the latest on code-injecting WindowServer?

Also added an FAQ to the site: https://chromeisbad.com/#faq to address the low-hanging fruit of obvious objections to the possibility that Chrome/keystone is doing something to the system to cause it to thrash.

I’ve been having WindowServer problems for month taking almost 100% of cpu out of the blue. I never could find any solutions and believe me it’s really painful when working when my IDE becomes so slow if takes seconds for every keystroke. So far it seems to fix my problem and I have the same computer setups. I switched to Brave to get back the Dev Tools. I don’t have a day to take off to analyze the my system deeply without knowing where to start so in my case it’s a welcome fix

Afaik you don't need to hide from the monitor to cause load by WindowServer while staying silent yourself. You just need to do graphics-intensive stuff. WindowServer then shows up as the manifestation of graphics being processed.

In fact, Un-googled Chromium (without the autoupdater) easily causes load that's displayed as WindowServer's, for me—when I open a Youtube video on my oldish Macbook with a shitty integrated video card. However there's little chance that I would think this to be caused by something else.

I may have got it wrong, but I interpreted the page to say only that Chrome and/or its updater made Window Server work hard, not that they're impersonating it.

Chrome does have the capacity for screen sharing (e.g. Chrome Remote Desktop), but I assume it wouldn't inject any extensions into the window server unless it was actively invoked.