This weekend, developer Lauren Brictor Google Chrome for Mac – or more specifically its auto-update algorithm – has released a website claiming that the Windows server process in MacOS continues to have high CPU usage, damaging MacOS performance, even on high-end machines.
The website contains information on how to completely remove Chrome and its updater from your Mac to reverse your performance, and went so far as to call it “malware” (that word has been removed). Many users reported that it worked and that everything got very fast after Google Chrome was removed from their computers.
I preface this by making it very clear that I am not a fan of Google Chrome. I installed it because some of the things I installed online needed it, but my favorite browser is always Safari. The technical side of this story and some of the questions I thought while reading Loren’s report piqued my interest. Those questions include: Can a process hide itself from the performance monitor while running? When does the update process run, and what does it do? Is Google Chrome Update Really the Cause of this Windows Server CPU app that people are looking at?
Can a process hide itself from the activity monitor while running?
I have no definite answer to this question. The only practical way to do this is to monitor the system running the processes and if function monitoring is detected, stop my process so that the user does not see it on the activity monitor. I do not know why Google’s Keystone Updater does this, and some quick static analysis of its binaries does not reveal such tactics.
When does the update process run, and what does it do?
Google’s Keystone service, like other service type applications and processes running on the Mac, registers itself with the system using the launched property list. Launch is the daemon responsible for creating processes in MacOS, and is a configuration file based on an initialized property list, which tells the initiator how to run a given service.
In the case of the Google Chrome update, it registers two services, which are supported by the same binary, ~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent.
“Keystone User Agent” Service a StartInterval Set to the value of 3623 Seconds, so it runs once an hour to check for updates. Another is that the “Keystone XPC service” only launches when a Google app wants to check for updates as needed. These are not services that run indefinitely, they are launched from time to time to check for updates, or when a Google app wants to talk to them, it’s even more interesting to claim that they slow down Windows.
As for what this renewal agent is doing, I have done some basic reverse engineering using static analysis of the relevant binary using Hopper. It handles things like uploading crash reports, as well as checking for updates to Google apps like Chrome. When it was actually running it could be seen on the activity monitor, in which case it would appear as “Google Software Update”.
Keep in mind that this basic research does not guarantee that you will not do anything harmful in any way, which means that by the time I notice it, I have not found anything dangerous.
Is Google Chrome Update Really the Cause of this Windows Server High CPU Utility That People View?
This is the main question I kept answering during my tests. Tested on the 2019 16 ”MacBook Pro with Core i9 processor and 16GB of RAM. The machine was plugged into the external display, no applications other than basic background tasks were actively done during the tests, and I left Caffeinated The engine will run to prevent falling asleep.
Using tools that allow you to monitor software readings over time, such as CPU usage, I recorded two sessions: one with Google Chrome installed, the other with Google Chrome, and the upgrade services uninstalled. I used the first 30 minute window of the Instruments session to measure the CPU usage of the window server in each situation.
From the above comparison, when you see that Chrome is installed, the Windows server process is used 50s Of the CPU during the test window. It was used without Chrome and its update 49s. Given the very small difference (the way below that causes visible performance issues) I do not see this as a confirmation of the problem.
Besides, show the full claim that a process running once an hour will bring more CPU usage to a completely unrelated computer service. Windows Server is responsible for displaying the MacOS UI on the screen, which spends its time CGXUpdateDisplay Method, rendering CALayers, a software update verification (without UI) is a completely unrelated task.
Why do people think this slows down Chrome’s Mac performance?
As for why people feel this problem and its solution, I can think of a few possibilities. One of them is the placebo effect: you have a problem, you do what someone tells you to fix the problem, and then you feel like the problem is fixed. This is more common on computers than you think. Another confirmation bias: you hate Google and Google Chrome (hey, not a fan, we might be friends), and you find a story that fits your opinion about the software, so you believe it instinctively.
Another thing that can work here is that the instructions on Lauren’s website tell you to restart the machine exactly after the steps described, but it’s not necessary to uninstall Google’s software update. In fact, in my tests, I made sure it was not working and uninstalled and then running launchctl unload, Then removes the initiated property lists and binary from the system. I did it because a rebooted computer would always feel faster than one running for weeks, and I had to remove that test from my tests.
If you still feel that Google Chrome is slowing down your Mac performance, by all means, I recommend Safari instead.
FTC: We use revenue generating automated connections. Further.
Check out the 9to5Mac on YouTube for more Apple News: