In a series of tweets by developer Luca Casonato – it was brought to everyone’s attention that a potentially problematic feature exists within Google Chrome and other Chromium-based browsers like Microsoft Edge and Brave. As it turns out, these browsers have a built-in extension that grants all Google-owned domains, such as *.google.com, exclusive access to detailed system information.
This information includes CPU architecture data with a few specifics, such as model name and processor usage data. This capability, which is used for performance monitoring and debugging, is unavailable to non-Google domains.
This built-in extension, which does not appear in the standard Chrome extensions panel and cannot be disabled, was traced back to a commit in October 2013, with a code review available here. The feature allows Google services like Google Meet to monitor system resources and offer performance advice, such as closing tabs if the CPU is under heavy load. This functionality is achieved through a particular API call that retrieves detailed processor information and system performance metrics.
Simon Willison figured out a way to trigger the API (with GPT-4o, no less) to show how this works in practice:
When running the snippet Simon shared on a non-Google site, the response is that the specific call cannot be used. But, when visiting any official Google site – the call goes through, and a detailed response is generated:
The API in question retrieves detailed information about the system’s CPU, which includes the architecture type, specific model, supported features, number of logical processors, and comprehensive usage statistics for each core. For instance, it identifies the CPU architecture as “x86_64,” and lists features like MMX and various versions of SSE and AVX instruction sets. It also reveals the CPU model. Additionally, it provides detailed usage metrics for each core, including idle time, time spent on kernel and user processes, and total active time.
This allows Google Hangouts, or its modern equivalent, Google Meet, to gather additional information from the browser, such as the current load on the user’s CPU. On Hacker News, a user who works at Google confirmed that the troubleshooting feature in Google Meet uses this capability to monitor CPU utilization.
You can try this out for yourself by going to Google Meet and starting a new session:
You can then navigate from the settings menu to “Troubleshooting & help,” which shows the real-time CPU usage associated with this API.
Why is this a problem?
Most people who saw Luca’s post on Twitter viewed it as unfair competition, as it gives Google services an advantage. For instance, Google Meet can adjust its performance based on system load, while competitors like Zoom require users to install external add-ons for similar functionality.
Then there’s the question of fingerprinting. Historically, browsers have been scrutinized for their fingerprinting capabilities. For example, the EFF has highlighted how browser fingerprinting can be more invasive than cookies, as it can persist even when users take steps to delete their browsing history or use incognito mode. This kind of API can easily be abused to fingerprint users’ devices with high accuracy, creating unique profiles based on CPU, GPU, and memory data.
Another interesting note is that this also works in incognito mode, which could very well be utilized to fingerprint users across different sessions. The same goes for not having a Google account. It’s well-known that getting this kind of hardware information is not something you can do with a web browser – unless you’re Google, in this case.
The regulatory landscape, particularly in the European Union, includes laws like the GDPR and the Digital Markets Act (DMA), emphasizing user privacy and fair competition.
Exclusive access to such detailed system data could be seen as violating these principles, as it provides Google with an unfair competitive advantage and undermines user privacy protections.
It’s also unclear whether browsers like Edge and Brave were even aware of this hidden extension before Luca disclosed it. When doing an internal test, all the popular Chromium-based web browsers (Edge, Brave, Opera) returned the exact system details in response to the API call.
How did Google respond?
As soon as this article was finished, Stack Diary sent out a range of questions to Google’s press team to ask about things like awareness of the hidden API’s potential for fingerprinting, their justification for exclusive access to detailed system information, measures to prevent data misuse, plans to disable the API, and whether other Chromium-based browsers were informed about this feature.
In response to our questions, Google provided a brief statement through a spokesperson:
Today, we primarily use this extension for two things:
To improve the user experience by optimizing configurations for video and audio performance based on system capabilities.
To provide crash and performance issue reporting data to help Google services detect, debug, and mitigate user issues. Both are important for the user experience and in both cases we follow robust data handling practices designed to safeguard user privacy.
a Google spokesperson
The response acknowledges the extension’s existence (the same spokesperson also said that it is “a bit of a legacy extension”), and provides some insight into its intended use, but it falls short of addressing the broader concerns raised by the community.
Google’s actions have affected its reputation over the years regarding features that scream, “This could be used to spy on people.” This is true regardless of whether the hidden extension is legacy or critical to their operations, where a product can’t operate without it.
While Google’s response provides some insight into its use of this API, it also highlights a broader issue in the tech industry. By emphasizing user experience and debugging capabilities, Google prioritizes functionality and service quality. While potentially beneficial for users of Google services, this approach raises questions about the balance between innovation and fair competition in the web ecosystem.
Google’s position as a major browser developer and a service provider puts them in a unique situation. Their ability to implement features that enhance their own services showcases the potential for integrated ecosystems. However, it also underscores the challenges other companies face trying to compete on a level playing field.
For now, users of Chrome and other Chromium-based browsers should be aware that Google has access to detailed system information that isn’t available to other websites or services. While Google states this is used to improve user experience, the lack of transparency and control over this feature is worth paying attention to.
