Google Chrome has an API accesible only from *.google.com

Original Article ↗ Hacker News Discussion ↗

What was discovered

  • Chrome bundles a hidden “Hangouts Services” extension with a hardcoded allowlist for *.google.com.
  • From any *.google.com page, JavaScript can message this extension to access CPU, GPU, memory usage and detailed CPU info (e.g., model name, core count, per-core usage).
  • Example code in the thread shows chrome.runtime.sendMessage to the extension ID returning full system CPU data; it fails on non‑Google domains.

Technical scope and how it works

  • The extension uses documented Chrome extension APIs like chrome.system.cpu (and related system APIs).
  • These APIs are generally available to any extension that requests the right permissions, but normal websites cannot call them directly.
  • The Google-bundled extension is preinstalled, hidden in chrome://extensions, and pre‑granted permissions for *.google.com.
  • The same mechanism works in other Chromium-based browsers (e.g., Edge, Brave) unless explicitly disabled; ungoogled‑chromium disables it via a build flag.

Stated / inferred use cases

  • Multiple comments tie this to Google Meet’s “Troubleshooting” panel, which shows live system‑wide CPU usage and, in Chrome only, suggests performance debugging steps.
  • Historical context: originally introduced around 2013 for Hangouts/WebRTC debugging; some suggest it’s now technical debt that persisted into Meet.

Privacy, security, and tracking concerns

  • Data exposed is system stats and hardware details, not full “system access,” but can aid browser fingerprinting or cross‑tab correlation.
  • Some argue it marginally increases attack surface (if *.google.com is spoofed via DNS+MITM), but others note that defeating HTTPS/HSTS/CT to do this implies much worse capabilities already.
  • There is disagreement on severity: some see this as routine telemetry; others see any undisclosed privileged path from web content to hardware as problematic.

Anticompetitive / neutrality concerns

  • Major thread theme: Google gives its own web apps capabilities (e.g., Meet CPU diagnostics) that competitors’ websites cannot match without getting users to install their own extension.
  • This is compared to past “special APIs for first‑party apps” controversies (e.g., Microsoft/IE, browser quirks files).
  • Some argue this is textbook monopoly leveraging and should interest regulators; others counter that Chrome is optional software and such integration is acceptable.

Alternatives, mitigations, and open questions

  • Possible mitigations: build Chromium with the feature disabled; use ungoogled‑chromium, Firefox, or Safari; block the component extension via enterprise policy; avoid Google domains.
  • Some say the API should remain extension‑only but not be wired directly to Google sites; others suggest prompting users for permission.
  • It remains unclear exactly how broadly Google uses this data beyond Meet‑style diagnostics.