Google is experimenting with a new Incognito-mode protection called Script Blocking in Incognito that will block third‑party scripts known to perform browser fingerprinting techniques, using a list‑based Masked Domain List (MDL) and a small change to the Fetch specification that gives browsers a standard “hook” to block or shim requests after normal checks like CSP and mixed content are performed. (windowslatest.com) (privacysandbox.google.com)
Chrome’s existing Incognito mode prevents local storage of history, cookies, and some site data, but it has never claimed to be an absolute shield against cross‑site tracking. The new Script Blocking proposal aims to materially improve privacy for users who choose Incognito by preventing third‑party scripts that rely on APIs such as Canvas, WebGL, fonts, and audio from executing when those scripts are flagged as problematic by Google’s tooling and the MDL process. Chrome will only block active third‑party resources (scripts or iframes) identified on the Blocked Domain List subset of the MDL; static resources like images or stylesheets are not blocked. (privacysandbox.google.com)
This is a deliberately conservative, list‑based approach: instead of trying to heuristically intercept all fingerprinting attempts, Chrome will check outgoing network requests against a curated blocklist and only intervene when the request matches an entry flagged as “Impacted by Script Blocking.” The goal is to reduce re‑identification and cross‑site linking performed by third‑party scripts that misuse legitimate web APIs. (groups.google.com)
However, the approach is not a panacea. It is list‑based and therefore inherently reactive; it does not eliminate the incentives for adtech to innovate around detection; and it creates a mixed protection surface across browsers and modes—Safari and Firefox already offer more aggressive, broader protections in many cases. Moreover, some product reporting (for example a specific “eye” icon UI) remains unverified by core project documentation and should be treated as provisional until Google documents it formally. (windowslatest.com, webkit.org, support.mozilla.org)
For Windows users who rely on Incognito for extra privacy, Script Blocking will likely meaningfully reduce certain re‑identification risks when it ships broadly. For privacy advocates and web developers, the project is an important test of how to reconcile usability, backwards compatibility, and robust protections in a market where browsers and adtech are in continuous tension. The MDL’s transparency, appealability, and responsiveness to obfuscation will determine whether this becomes a durable, trustworthy protection or another stopgap in the arms race against fingerprinting—an arms race that browser vendors, standards bodies, and the research community must continue to confront together. (groups.google.com)
Script Blocking in Incognito is rolling out as an experiment now; affected users and developers should test the feature under the chrome://flags entry, review the MDL if they manage domains that embed third‑party code, and watch for further updates from the Chromium team as the experiment scales. (groups.google.com, privacysandbox.google.com)
Source: windowslatest.com Google tests Safari-style script blocking in Chrome incognito on Windows 11 for private browsing
Background / Overview
Chrome’s existing Incognito mode prevents local storage of history, cookies, and some site data, but it has never claimed to be an absolute shield against cross‑site tracking. The new Script Blocking proposal aims to materially improve privacy for users who choose Incognito by preventing third‑party scripts that rely on APIs such as Canvas, WebGL, fonts, and audio from executing when those scripts are flagged as problematic by Google’s tooling and the MDL process. Chrome will only block active third‑party resources (scripts or iframes) identified on the Blocked Domain List subset of the MDL; static resources like images or stylesheets are not blocked. (privacysandbox.google.com)This is a deliberately conservative, list‑based approach: instead of trying to heuristically intercept all fingerprinting attempts, Chrome will check outgoing network requests against a curated blocklist and only intervene when the request matches an entry flagged as “Impacted by Script Blocking.” The goal is to reduce re‑identification and cross‑site linking performed by third‑party scripts that misuse legitimate web APIs. (groups.google.com)
How Script Blocking works — technical details
The Masked Domain List (MDL) and Blocked Domain List
- Chrome’s Script Blocking reuses the existing Masked Domain List (MDL) infrastructure used for IP protection and related Privacy Sandbox work.
- A subset of the MDL, the Blocked Domain List, contains domains (or specific URL paths) flagged “Impacted by Script Blocking.”
- Domains can be treated as whole hosts or, when they are shared CDNs, individual paths may be targeted instead of entire hosts to avoid collateral breakage. Chrome computes a proportion of traffic that serves matched code to decide whether a host is “shared.” (privacysandbox.google.com)
Where the blocking happens: a Fetch “hook”
- Google proposed a small, targeted change to the WHATWG Fetch processing model that introduces an explicit intervention stage where user agents (browsers) can block or “shim” requests after the usual checks such as Content Security Policy (CSP), mixed‑content rules, and other prerequisites.
- That Fetch change (an “override fetch” or intervention hook) has been proposed and reviewed in the WHATWG Fetch repo and is already under discussion among implementers. It provides a standard place for browsers to apply protections like script blocking. (github.com)
Scope and context rules
- Script Blocking only applies to third‑party contexts in Incognito mode. A resource served from the same registrable domain (or from domains mapped as the same entity via Disconnect’s mapping) is treated as first‑party and not blocked.
- Chrome uses entity lists (Disconnect mappings) to determine first‑party vs third‑party relationships and provides an appeals process for domain owners who believe they were misclassified. (privacysandbox.google.com)
Implementation and developer tooling
- The feature reuses Chromium’s subresource_filter for matching and filtering subresources.
- DevTools will show which requests were blocked and provide diagnostics to site owners.
- There’s an about://flags entry (Enable Fingerprinting Protection Blocklist In Incognito / EnableFingerprintingProtectionInIncognito) for testing before wide rollout. Chrome’s team ran a 1% stable Incognito experiment and intends to ramp carefully while monitoring breakage and performance metrics. (groups.google.com)
What this will (and will not) stop
What it targets
- Active fingerprinting scripts that compute device/browser characteristics via:
- Canvas rendering differences
- WebGL characteristics
- Font enumeration and detection
- Audio APIs used to fingerprint (audio‑based entropy)
- These techniques do not necessarily rely on cookies; their danger is the ability to produce a stable identifier that links a user across sites and sessions. Script Blocking aims to prevent the script execution that produces that identifier in third‑party contexts when the domain is on the Blocked Domain List. (privacysandbox.google.com)
What it does not (yet) target
- It is not a blanket anti‑fingerprinting enforcement across the web. Only domains explicitly flagged by the MDL and only in third‑party contexts inside Incognito are affected.
- Static resources—images, stylesheets—are generally not blocked.
- The proposal is not currently targeted at WebView (Android) and will not ship there per the publicly shared plans. (groups.google.com)
How this compares to existing browser protections
- Safari (WebKit) — ITP: Apple’s Intelligent Tracking Prevention (ITP) uses heuristics and classification to limit cross‑site tracking, aggressively capping cookie lifetimes, blocking third‑party cookies by default, and classifying domains with cross‑site tracking capabilities. Safari’s protections are broader in that they operate in normal and private browsing and are not explicitly limited to a list the same way Chrome’s initial experiment is. (webkit.org)
- Firefox — ETP: Mozilla’s Enhanced Tracking Protection blocks a wide set of known tracking techniques, including fingerprinters, and exposes a protections dashboard; its blocking extends beyond private windows depending on mode settings. Firefox uses lists (Disconnect, Mozilla’s own heuristics) and provides a visible shield UI when protections are active. (support.mozilla.org)
- Edge (Chromium) — Tracking Prevention: Microsoft’s Edge implements a blocklist/heuristic approach to tracking prevention, but historically has taken a less aggressive stance than Firefox/Safari in some areas and relies on similar lists and modes for users. Broader ecosystem interventions—like Chrome’s new Script Blocking—may not be adopted by all Chromium forks unless they choose to. Published Chromium discussions indicate Google does not plan to require other Chromium vendors to enforce the MDL in their builds. (groups.google.com)
What users will see and control
- When Script Blocking intervenes, Chrome intends to surface a UI indicator that shows a protection is active for the top‑level page and allows users to disable it for that site if needed.
- Chrome’s Privacy Sandbox page notes that users can disable Script Blocking in Chrome settings. DevTools will also offer visibility into blocked requests for debugging. (privacysandbox.google.com, groups.google.com)
Benefits: what this could deliver for privacy
- Reduced cross‑site re‑identification: By blocking the execution paths known to produce identifiers, Script Blocking can interrupt adtech and analytics pipelines that stitch user activity across domains without cookies.
- User‑selectable protection: The design favors giving users the ability to keep Script Blocking enabled in Incognito, while allowing per‑site exceptions when functionality breaks.
- Standards‑aligned intervention: By pursuing a Fetch spec hook, Google has signaled a preference for standardizing where user agents may intervene, which could make implementations clearer and testable across browsers. (github.com, privacysandbox.google.com)
Risks, trade‑offs, and open questions
1) List‑based approach: coverage vs. evasion
- A list‑based approach is effective against known, widely‑deployed fingerprinting scripts, but it can be circumvented by actors who:
- Serve slightly altered, obfuscated code to avoid matching signatures.
- Move infrastructure to hosts not on MDL lists, or use first‑party compromises to bypass third‑party classification.
- Detection and maintenance of the MDL is an ongoing arms race: crawlers and signature matchers will need to keep pace with obfuscation and inventive evasion techniques. Academic work shows fingerprinting code can be obfuscated but dynamic detection remains viable with effort. (arxiv.org)
2) Web compatibility and breakage
- Any blocking of active scripts risks breaking site functionality. The Chromium team explicitly plans temporary exceptions for domains where blocking would degrade anti‑fraud defenses or break particularly sensitive sites (e.g., .gov, .edu). Breakage reporting and an appeals process are part of the MDL workflow, but the trade‑off between privacy and compatibility will remain contentious in the web developer community. (privacysandbox.google.com, groups.google.com)
3) Incognito‑only scope and ecosystem fragmentation
- Chrome’s choice to limit the feature to Incognito mode makes it protective for private browsing sessions but leaves regular browsing potentially more exposed unless the user actively uses private windows.
- Other Chromium‑based browsers may not adopt Google’s MDL or the same enforcement model; the result could be inconsistency across Chromium forks and the potential for adtech to adapt by targeting non‑Incognito sessions or Chromium variants. The Blink discussion acknowledges different vendors ship different heuristics and lists. (groups.google.com)
4) Transparency and trust
- Blocking policy, inclusion criteria, and appeal mechanics will determine how much trust site owners and privacy advocates place in the mechanism. Chrome publishes MDL lists and offers appeals, but operational details—timelines, thresholds, and evidence—will matter for public confidence.
- Users should be wary of overclaiming privacy. Incognito + Script Blocking will lower certain re‑identification vectors but will not make browsing indistinguishable or anonymous without traffic anonymization (VPNs, Tor). The broader context of browser telemetry, enterprise policies, and ecosystem incentives matters—Chrome’s telemetry and privacy posture have created ongoing debate about user expectations.
5) Arms race and fingerprinting evolution
- Fingerprinters can shift tactics: moving from a small set of obvious API calls to more distributed signals, combining subtle timing/jitter signals, or relying on first‑party data flows. Any mitigation will alter the incentives and force further innovation on both sides.
What site owners and ad/analytics vendors need to do
- Review the MDL and check whether domains you operate or embed are listed or flagged with “Some URLs are affected.” Google publishes the MDL entries and provides an appeals process for affected sites. Site owners should ensure critical functionality is not dependent on blocked third‑party scripts in private browsing modes and consider migrating to privacy‑friendly integration patterns (server‑side, first‑party equivalents, or Privacy Sandbox APIs where appropriate). (privacysandbox.google.com)
- Use DevTools to test under the experimental flag (chrome://flags/#enable-fingerprinting-protection-blocklist-incognito) to see which resources may be blocked and adjust integrations accordingly. Chrome added DevTools support to surface blocked requests for diagnosis. (groups.google.com)
- If you rely on third‑party services, confirm whether those vendors are flagged and whether they can be reconfigured (e.g., host scripts under your top‑level domain or use server‑side calls) to avoid third‑party classification.
Deployment plan and current status
- Google ran a 1% stable Incognito experiment to measure site breakage and performance impact and saw no statistically significant change in Incognito‑specific Core Web Vitals during that initial experiment window. The team plans to carefully ramp the experiment before pushing to Incognito 100%. The feature’s launch and milestone tracking are publicly discussed in Blink groups and Chrome Platform Status. (groups.google.com)
- The Fetch intervention hook has a Pull Request in the WHATWG Fetch repository intended to standardize where browsers can implement such interventions; the PR has active discussion among implementers and reviewers. Standardizing the hook reduces the risk of divergent behaviour and improves interoperability for web developers and testing infrastructures. (github.com)
Practical advice for Windows users and admins
- To experiment:
- Enable the flag chrome://flags/#enable-fingerprinting-protection-blocklist-incognito in a test Chrome profile.
- Open an Incognito window and load sites that include third‑party analytics/ad scripts to observe any blocked requests in DevTools Issues.
- Report any site breakage to the site owner and, if a site you own is affected, follow the appeals instructions on the MDL GitHub documentation. (groups.google.com, privacysandbox.google.com)
- If you’re privacy‑conscious:
- Use Incognito for sessions where you want extra protections, but recognize that Incognito + Script Blocking does not anonymize your traffic—your IP and server‑side signals may still reveal identity.
- Combine browser protections with network protections (VPN, Tor) when stronger anonymity is required.
- For enterprise admins:
- Track Chrome policy changes and consider how exceptions will interact with managed policies. Site breakage or vendor reliance on blocked domains may affect internal applications or analytics pipelines.
Final assessment — balancing privacy gains vs. real‑world limits
Script Blocking in Incognito represents a pragmatic step forward: it acknowledges that fingerprinting—an increasingly common, cookieless tracking technique—can be mitigated at the browser level without breaking the web wholesale. By limiting the intervention to third‑party contexts and using a curated MDL, Google is prioritizing compatibility while delivering concrete protections in private sessions. The attempt to standardize a Fetch intervention hook is a positive architectural move that could make similar protections easier for other engines to adopt consistently. (privacysandbox.google.com, github.com)However, the approach is not a panacea. It is list‑based and therefore inherently reactive; it does not eliminate the incentives for adtech to innovate around detection; and it creates a mixed protection surface across browsers and modes—Safari and Firefox already offer more aggressive, broader protections in many cases. Moreover, some product reporting (for example a specific “eye” icon UI) remains unverified by core project documentation and should be treated as provisional until Google documents it formally. (windowslatest.com, webkit.org, support.mozilla.org)
For Windows users who rely on Incognito for extra privacy, Script Blocking will likely meaningfully reduce certain re‑identification risks when it ships broadly. For privacy advocates and web developers, the project is an important test of how to reconcile usability, backwards compatibility, and robust protections in a market where browsers and adtech are in continuous tension. The MDL’s transparency, appealability, and responsiveness to obfuscation will determine whether this becomes a durable, trustworthy protection or another stopgap in the arms race against fingerprinting—an arms race that browser vendors, standards bodies, and the research community must continue to confront together. (groups.google.com)
Script Blocking in Incognito is rolling out as an experiment now; affected users and developers should test the feature under the chrome://flags entry, review the MDL if they manage domains that embed third‑party code, and watch for further updates from the Chromium team as the experiment scales. (groups.google.com, privacysandbox.google.com)
Source: windowslatest.com Google tests Safari-style script blocking in Chrome incognito on Windows 11 for private browsing
