How Chromium's Privacy Budget Capped Identifiable API Calls

Chromium's Privacy Budget was an experimental anti-fingerprinting proposal designed to limit the amount of identifiable user data websites could extract through browser APIs. This article details how the proposal attempted to quantify data exposure using information entropy, assign privacy costs to specific browser requests, and enforce a strict cap on API calls to prevent cross-site user tracking without breaking standard web functionality.

Quantifying Identifiability with Entropy

To cap identifiable data, Chromium first needed a standardized way to measure it. The Privacy Budget proposal relied on Claude Shannon’s information theory, measuring user identifiability in "bits of entropy."

Every browser API that reveals device or user characteristics—such as screen resolution, hardware concurrency, or installed fonts—was analyzed through large-scale telemetry across the broader population of Chrome users. The browser assigned a numerical cost to each API based on how uniquely its return value identified a user:

  • Low Entropy: An API returning a very common value, like a standard 1920x1080 screen resolution or a widely used timezone, carried a very low entropy cost.
  • High Entropy: An API revealing a rare combination of audio hardware, specific GPU models, and custom system fonts carried a high entropy cost.

In information theory, one bit of entropy cuts the pool of possible users in half. Since roughly 33 bits of entropy are enough to uniquely identify a single person out of the entire global population, the Privacy Budget aimed to cap a website's data collection well below that threshold.

Accounting for Correlated API Surfaces

Measuring individual API calls in isolation was not practical because many browser attributes are inherently linked. For example, querying the navigator.platform API and the navigator.userAgent API often reveals the exact same operating system data. If a website called both, charging the full entropy cost for each would unfairly deplete the website's budget, as the second call provided no new identifying information.

To solve this, Chromium engineers grouped correlated APIs into "equivalence classes" and measured their joint entropy. The browser tracked which data points had already been exposed to a specific website during a session. It only deducted from the privacy budget when a new API call revealed fresh, uncorrelated identifying information. Passive data sent automatically with every network request, such as the IP address and standard HTTP headers, was considered the baseline cost before any JavaScript APIs were even executed.

Enforcing the Cap

The core mechanism of the proposal was the budget enforcement itself. Chromium aimed to set a maximum threshold of entropy that any single web origin (website) could consume.

Every time a website's script executed a "high-entropy" API call, the browser subtracted the corresponding bit-value from that site's remaining allowance. The system was designed to differentiate between normal site operations and malicious tracking:

  • Benign Scripts: A website checking screen dimensions to load a mobile-friendly layout would consume a fraction of the budget and function normally.
  • Fingerprinting Scripts: Aggressive trackers that rapidly query dozens of obscure APIs related to WebGL, HTML5 Canvas, and AudioContext to build a unique hardware profile would quickly exhaust their allotted budget.

Actions Taken When the Budget Runs Out

Once a website hit its entropy cap, the browser intervened to prevent further identification. Chromium proposed several enforcement mechanisms for API calls made after the budget was depleted:

  1. Returning Generic Values: The browser would return a standardized "fallback" value, such as reporting a default system font or a generic 8-core CPU, regardless of the user's actual hardware.
  2. Blocking Execution: The API call would simply fail or return an error, halting the fingerprinting script's ability to gather more data.
  3. Adding Noise: The browser would introduce slight, random variations into the returned data (such as slightly altering canvas rendering metrics), invalidating the stability of the fingerprint.

By forcing the APIs to return common or randomized values after the cap was reached, the browser ensured the user remained blended into a large crowd of similar devices.

The Challenges That Ended the Proposal

Despite its strong mathematical foundation, the Privacy Budget proposal was eventually abandoned by the Chromium team. The primary hurdle was that legitimate, modern web applications—such as browser-based video editors, conferencing tools, and 3D gaming platforms—frequently requested the exact same hardware, audio, and graphics APIs as malicious fingerprinting scripts.

Enforcing a strict entropy cap often broke these advanced web features because the browser could not reliably determine the intent behind an API call. Additionally, continuously calculating real-time joint entropy across thousands of evolving web APIs proved too complex to maintain accurately, leading Chromium to retire the Privacy Budget in favor of more targeted anti-fingerprinting defenses.