Google has begun testing a new Incognito-mode protection that blocks third-party scripts from using browser fingerprinting techniques to re-identify users across sites. The feature, called Script Blocking in Incognito, relies on a carefully curated Masked Domain List (MDL) and a proposed change to the Fetch specification that gives browsers a standard hook to intercept and block requests before they execute.
The feature, detailed in the Privacy Sandbox initiative and discussed in Chromium developer forums, represents Chrome’s first direct attempt to combat cookieless tracking in private browsing sessions. It does not silently block all fingerprinting—instead, it checks outgoing network requests against a list of domains known to serve fingerprinting code, and only intervenes for active third-party resources like scripts or iframes.
How Script Blocking Works—Technical Details
The mechanism reuses the MDL infrastructure originally built for IP Protection. A subset of that list, the Blocked Domain List, contains domains flagged as “Impacted by Script Blocking.” When Incognito is active and a page requests an active resource from a flagged domain, Chrome blocks the execution. Static resources like images and stylesheets pass through unaffected.
The Fetch Hook: A Standards-Based Intervention
To implement such blocking cleanly, Google’s engineers proposed a small, targeted change to the WHATWG Fetch specification. The change—now under review as a pull request—defines an “intervention” stage after standard checks such as Content Security Policy (CSP) and mixed-content rules. Browsers that adopt the hook can block or shim requests systematically, making the behavior predictable for web developers. This is a deliberate move away from ad-hoc heuristics toward a standardized point of control that any user agent can leverage.
Third-Party Only, and No First-Party Collateral Damage
Script Blocking only operates in third-party contexts. If a resource shares the same registrable domain as the top-level page, or if both domains belong to the same entity according to Disconnect.me’s mapping, Chrome treats it as first-party and leaves it untouched. This reduces the risk of breaking legitimate website functionality while focusing on cross-site trackers.
For shared CDNs, where blocking an entire host would cause widespread breakage, Chrome calculates the proportion of traffic that serves fingerprinting code. If it falls below a threshold, only the specific URL paths are blocked, not the whole domain.
What Gets Blocked—and What Doesn’t
Script Blocking targets active fingerprinting scripts that exploit APIs like Canvas, WebGL, font enumeration, and the Audio API. These scripts compute a unique, stable device signature without relying on cookies. By preventing the script from loading at all, Chrome cuts off the computation at the source.
It does not target static resources, nor does it apply in regular browsing mode—only in Incognito windows. The feature also comes with built-in exceptions: Chrome may temporarily lift blocking on domains where intervention disrupts anti-fraud defenses or breaks particularly sensitive sites (e.g., .gov and .edu). Domain owners can appeal incorrect blocklist entries through the MDL appeals process.
How It Compares to Safari, Firefox, and Edge
Browser tracking protection has evolved quickly, but approaches differ.
- Safari (Intelligent Tracking Prevention): ITP uses heuristics and machine learning to classify domains, caps cookie lifetimes, and blocks third-party cookies by default. Protections apply in both normal and private browsing. Safari’s fingerprinting defenses are broader and not confined to a static list.
- Firefox (Enhanced Tracking Protection): ETP blocks known trackers and fingerprinters using a mix of Disconnect lists and Mozilla’s own heuristics. It operates in private windows by default and can be set to strict mode in regular sessions, with a visible shield UI.
- Microsoft Edge (Tracking Prevention): Edge balances a blocklist with less aggressive defaults, offering a middle ground between protection and compatibility.
Chrome’s Script Blocking is decidedly more conservative: it is list-based, limited to Incognito, and targets only active scripts from domains explicitly listed. That narrow scope means it may break fewer sites, but it also leaves regular browsing unprotected unless users habitually open Incognito windows.
Importantly, the spec-level Fetch hook could allow other Chromium-based browsers to adopt similar protections, though Google does not plan to require other vendors to enforce the MDL. This could lead to fragmentation across Edge, Opera, and Brave, each with their own policies.
What Users Will See
When Script Blocking intervenes, Chrome plans to surface a UI indicator that signals protection is active for the top-level page. Users will be able to disable Script Blocking either globally via Chrome settings or on a per-site basis through the indicator. DevTools will also show which requests were blocked, aiding developers in debugging.
Early reports from a WindowsLatest article claimed Chrome would show an “eye” icon when blocking occurs. However, that specific icon is not confirmed in official Privacy Sandbox documentation or Blink design documents. Until Google officially documents the UI, such details should be treated as provisional.
Deployment and Current Status
Chrome ran a 1% stable Incognito experiment to gauge site breakage and performance. The team observed no statistically significant change in Incognito-specific Core Web Vitals during the initial window, a promising sign for compatibility. Google intends to ramp up carefully, monitoring feedback before pushing the feature to 100% of Incognito users.
The feature can be tested now by enabling the flag chrome://flags/#enable-fingerprinting-protection-blocklist-incognito in a Chrome profile and opening an Incognito window. Developers and site owners should use DevTools to inspect blocked resources and report any breakage through official channels.
For Windows Users and IT Administrators
Privacy-conscious Windows users who already lean on Incognito will gain a meaningful reduction in cross-site re-identification risks. But it’s critical to understand the limits: Script Blocking does not anonymize your traffic. Your IP address and server-side signals can still reveal your identity. For stronger anonymity, combine browser protections with a VPN or Tor.
Enterprise admins should track Chrome policy updates and test internal applications that embed third-party scripts. If a critical vendor’s domain lands on the MDL, the appeals process or a first-party integration may be needed to avoid service disruptions.
Site owners—especially those operating analytics or advertising services—should review the publicly available Masked Domain List on GitHub. If your domain is flagged, you can appeal via Disconnect.me. In the long run, migrating scripts to a first-party context or adopting Privacy Sandbox APIs may be a more durable solution than hoping to stay off a blocklist.
Benefits: A Pragmatic Step Toward Better Privacy
The primary gain is the disruption of cookieless tracking pipelines. By blocking the execution of known fingerprinting code in private windows, Chrome raises the cost for adtech and analytics companies that stitch user activity across domains. That strengthens the Incognito promise: a browsing session that leaves no local traces is also less likely to be linked to your identity through fingerprinting.
Moreover, the pursuit of a standardized Fetch intervention hook is a net positive for the web. If adopted, it creates a clear, interoperable point where privacy interventions can be applied, making it easier for developers to understand what a browser might block and why.
Risks, Trade-Offs, and Open Questions
Despite its careful design, Script Blocking faces several challenges.
1. List-Based Coverage vs. Evasion
A static blocklist is only as good as its maintenance. Fingerprinting actors can obfuscate code, change domains, or move to first-party contexts to avoid detection. The Chrome team acknowledges this as an ongoing arms race and has built crawler-based detection, but no list can catch everything.
2. Web Compatibility and Breakage
Blocking active scripts can break functionality beyond tracking—login flows, payment integrations, or performance monitoring. Chrome includes exceptions for sensitive domains, but edge cases will surface. The success of the feature depends on how effectively Google manages breakage reports and maintains the MDL’s accuracy.
3. Incognito-Only Scope and Fragmentation
By limiting protection to Incognito, Chrome leaves regular browsing sessions exposed unless users proactively open private windows. This is a deliberate trade-off to minimize disruption, but it also creates a two-tier privacy experience. Meanwhile, other Chromium forks may not enforce the MDL, leading to inconsistent protections across the ecosystem.
4. Transparency and Trust
Trust in the mechanism hinges on clear, timely appeals and transparent listing criteria. Chrome publishes the MDL, but the details of signature detection, list update cadence, and exception handling will need to be communicated openly to avoid perceptions of favoritism or bias.
5. The Fingerprinting Arms Race Continues
Blocking one technique pushes attackers to innovate. Future fingerprinters may combine subtle timing signals, new APIs, or first-party data flows. This arms race is inherent to privacy engineering, and browsers must continue to adapt.
A Balanced Assessment
Script Blocking in Incognito is a beneficial, if limited, addition to Chrome’s privacy toolbox. It acknowledges the reality of fingerprinting—an invisible, cookie-less tracking method—and offers a list-based, conservative defense that minimizes site breakage. The effort to standardize intervention hooks shows a commitment to a cleaner web architecture, not just a Chrome-only fix.
Yet it is not a substitute for more aggressive protections like those in Firefox or Safari. Users must understand that Incognito plus Script Blocking still leaves IP-address exposure and server-side tracking untouched. For those truly seeking anonymity, additional measures are necessary.
The feature’s long-term value will depend on how well Google maintains the MDL, handles appeals, and communicates with both users and developers. If executed well, it could significantly reduce the most prevalent fingerprinting vectors in private browsing sessions. If under-resourced or opaque, it may become another step in an endless cat-and-mouse game. As the experiment ramps up, all eyes will be on the balance between privacy gains and real-world web compatibility.