Intent to Experiment: Script Blocking in Incognito

[Zainab Rizvi]

Contact emails

riz...@google.com, mk...@chromium.org

Explainer

https://github.com/explainers-by-googlers/script-blocking

Specification

https://github.com/explainers-by-googlers/script-blocking/blob/main/index.bs

Summary

Mitigating API Misuse for Browser Re-Identification, otherwise known as Script Blocking is a feature that will block scripts engaging in known, prevalent techniques for browser re-identification in third-party contexts. These techniques typically involve the misuse of existing browser APIs to extract additional information about the user's browser or device characteristics.

To strike this balance between protection and usability, this proposal focuses on blocking scripts in a third-party context in Incognito mode. This proposal uses a list-based approach, where only domains marked as “Impacted by Script Blocking” on the Masked Domain List (MDL) in a third-party context will be impacted.

When the feature is enabled, Chrome will check network requests against the blocklist.  This feature will reuse Chromium's subresource_filter component, which is responsible for tagging and filtering subresource requests based on page-level activation signals and a ruleset used to match URLs for filtering.

Blink component

Blink>Network>FetchAPI

TAG review

https://github.com/w3ctag/design-reviews/issues/1114

TAG review status

Pending

Risks

Interoperability and Compatibility

There shouldn’t be any interop concerns. In terms of compatibility, this feature is anticipated to have an impact on websites that rely on scripts from domains identified as serving fingerprinting techniques. Sites that integrate third-party scripts from identified domains may experience functional breakage or render incorrectly when accessed in Incognito mode.

Gecko: Shipped/Shipping (https://support.mozilla.org/en-US/kb/trackers-and-scripts-firefox-blocks-enhanced-track)

WebKit: Shipped/Shipping (https://webkit.org/tracking-prevention/#private-browsing-mode)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Goals for experimentation

We will run a 1% stable experiment for users when in Incognito mode. Our motivation is functional in nature: we would like to better understand the breakage impact on sites, performance impact of checking requests against a blocklist, as well as testing that updates to the MDL, such as domain additions and removals (from changes to Disconnect's source lists or successful appeals) propagate to Chrome clients.

We will consider site breakage rates (indicated via user reports, aggregated UMA logging) as well as performance metrics (e.g., page load time, memory usage).

Ongoing technical constraints

None

Debuggability

We have added support in DevTools Issues to indicate which requests are being blocked by this feature. We also have chrome://flags/##enable-fingerprinting-protection-blocklist-incognito which developers and users can use for testing suspected breakage.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

We plan to launch this on all Blink platforms except WebView.

Is this feature fully tested by web-platform-tests?

No

We are exploring ways to test this feature via WPT. We want to test the correct integration and ordering of the script blocking mechanism within the Fetch API.

Flag name on about://flags

Enable Fingerprinting Protection Blocklist In Incognito

Finch feature name

EnableFingerprintingProtectionInIncognito

Requires code in //chrome?

True

Tracking bug

https://g-issues.chromium.org/issues/411138638

Launch bug

https://launch.corp.google.com/launch/4367306

Estimated milestones

We would like to run the experiment from M137 to M142 inclusive.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5188989497376768?gate=5165545720381440

[Yoav Weiss (@Shopify)]

On Mon, Jun 16, 2025 at 4:24 PM 'Zainab Rizvi' via blink-dev <blin...@chromium.org> wrote:

Contact emails

riz...@google.com, mk...@chromium.org

Explainer

https://github.com/explainers-by-googlers/script-blocking

Specification

https://github.com/explainers-by-googlers/script-blocking/blob/main/index.bs

Summary

Mitigating API Misuse for Browser Re-Identification, otherwise known as Script Blocking is a feature that will block scripts engaging in known, prevalent techniques for browser re-identification in third-party contexts. These techniques typically involve the misuse of existing browser APIs to extract additional information about the user's browser or device characteristics.

To strike this balance between protection and usability, this proposal focuses on blocking scripts in a third-party context in Incognito mode. This proposal uses a list-based approach, where only domains marked as “Impacted by Script Blocking” on the Masked Domain List (MDL) in a third-party context will be impacted.

When the feature is enabled, Chrome will check network requests against the blocklist.  This feature will reuse Chromium's subresource_filter component, which is responsible for tagging and filtering subresource requests based on page-level activation signals and a ruleset used to match URLs for filtering.

Blink component

Blink>Network>FetchAPI

TAG review

https://github.com/w3ctag/design-reviews/issues/1114

TAG review status

Pending

Risks

Interoperability and Compatibility

There shouldn’t be any interop concerns.

You mention above that Chrome will use its own list and below that this is shipped in other engines.

Presumably they use different lists for this.

Do we expect to see convergence on that front? Do we expect other Chromiums to follow Chrome and use its list? Have their own? Something else?

 

In terms of compatibility, this feature is anticipated to have an impact on websites that rely on scripts from domains identified as serving fingerprinting techniques.

I think it'd be good to expand on the "identified" part. Is there some transparency as to how domains have found themselves on that list? Is there a public appeal process?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsgKDRo%3D0g%2BtJpej_ET0_2Ed20B407myiu%3D%2BicVnB7JboQ%40mail.gmail.com.

[Mike West]

Hey Yoav, thanks for your questions!

On Monday, June 16, 2025 at 5:11:02 PM UTC+2 Yoav Weiss wrote:

On Mon, Jun 16, 2025 at 4:24 PM 'Zainab Rizvi' via blink-dev <blin...@chromium.org> wrote:

Contact emailsriz...@google.com, mkwst@chromium.org

Explainerhttps://github.com/explainers-by-googlers/script-blocking

Specificationhttps://github.com/explainers-by-googlers/script-blocking/blob/main/index.bs

Summary

Mitigating API Misuse for Browser Re-Identification, otherwise known as Script Blocking is a feature that will block scripts engaging in known, prevalent techniques for browser re-identification in third-party contexts. These techniques typically involve the misuse of existing browser APIs to extract additional information about the user's browser or device characteristics.

To strike this balance between protection and usability, this proposal focuses on blocking scripts in a third-party context in Incognito mode. This proposal uses a list-based approach, where only domains marked as “Impacted by Script Blocking” on the Masked Domain List (MDL) in a third-party context will be impacted.

When the feature is enabled, Chrome will check network requests against the blocklist.  This feature will reuse Chromium's subresource_filter component, which is responsible for tagging and filtering subresource requests based on page-level activation signals and a ruleset used to match URLs for filtering.

Blink componentBlink>Network>FetchAPI

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/1114

TAG review statusPending

Risks

Interoperability and Compatibility

There shouldn’t be any interop concerns.

You mention above that Chrome will use its own list and below that this is shipped in other engines.

I think the suggestion is that "script blocking" as a feature is shipping in several other engines. You're correct that the lists in use are distinct.

Do we expect to see convergence on that front?

In the status quo, browsers have landed on different heuristics and different list providers. It's unclear whether folks will generally agree on a list, and I'd suggest that it's probably more important for us to agree on the infrastructure and web-facing implications of blocking than to agree on the specific set of domains a given user agent chooses to block.

 

Do we expect other Chromiums to follow Chrome and use its list? Have their own? Something else?

We've published the list on GitHub, so it's entirely possible for other browsers to land on a similar list if it turns out to be effective.

  

In terms of compatibility, this feature is anticipated to have an impact on websites that rely on scripts from domains identified as serving fingerprinting techniques.

I think it'd be good to expand on the "identified" part. Is there some transparency as to how domains have found themselves on that list?

 

The explainer's Detection and Blocklist Creation section lays out a high-level story, and https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md is a more detailed list of the domains affected.

Is there a public appeal process?

Yes, similar to the process for IP protection: see the "Appeals" section of the explainer for detail.

 

-mike

 

Sites that integrate third-party scripts from identified domains may experience functional breakage or render incorrectly when accessed in Incognito mode.

Gecko: Shipped/Shipping (https://support.mozilla.org/en-US/kb/trackers-and-scripts-firefox-blocks-enhanced-track)

WebKit: Shipped/Shipping (https://webkit.org/tracking-prevention/#private-browsing-mode)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Goals for experimentation

We will run a 1% stable experiment for users when in Incognito mode. Our motivation is functional in nature: we would like to better understand the breakage impact on sites, performance impact of checking requests against a blocklist, as well as testing that updates to the MDL, such as domain additions and removals (from changes to Disconnect's source lists or successful appeals) propagate to Chrome clients.

We will consider site breakage rates (indicated via user reports, aggregated UMA logging) as well as performance metrics (e.g., page load time, memory usage).

Ongoing technical constraints

None

Debuggability

We have added support in DevTools Issues to indicate which requests are being blocked by this feature. We also have chrome://flags/##enable-fingerprinting-protection-blocklist-incognito which developers and users can use for testing suspected breakage.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?No

We plan to launch this on all Blink platforms except WebView.

Is this feature fully tested by web-platform-tests?No

We are exploring ways to test this feature via WPT. We want to test the correct integration and ordering of the script blocking mechanism within the Fetch API.

Flag name on about://flagsEnable Fingerprinting Protection Blocklist In Incognito

Finch feature nameEnableFingerprintingProtectionInIncognito

Requires code in //chrome?True

Tracking bughttps://g-issues.chromium.org/issues/411138638

Launch bughttps://launch.corp.google.com/launch/4367306

Estimated milestones

We would like to run the experiment from M137 to M142 inclusive.

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5188989497376768?gate=5165545720381440

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Domenic Denicola]

LGTM to experiment.

I applaud the efforts to specify here what has previously been a UA heuristic. Although my first impression was that a spec was not too important, because the UA could always pretend there was a network error, closer review of the draft reveals that this is not the case: there's a number of observable other checks that could happen beforehand, and so this is actually observable.

I've opened https://github.com/explainers-by-googlers/script-blocking/issues/2 on some of the details of this factoring.

On Monday, June 16, 2025 at 11:24:42 PM UTC+9 Zainab Rizvi wrote:

Contact emails

riz...@google.com, mkwst@chromium.org

[Yoav Weiss (@Shopify)]

On Mon, Jun 16, 2025 at 6:11 PM Mike West <mk...@chromium.org> wrote:

Hey Yoav, thanks for your questions!

On Monday, June 16, 2025 at 5:11:02 PM UTC+2 Yoav Weiss wrote:

On Mon, Jun 16, 2025 at 4:24 PM 'Zainab Rizvi' via blink-dev <blin...@chromium.org> wrote:

Contact emailsriz...@google.com, mkwst@chromium.org

Explainerhttps://github.com/explainers-by-googlers/script-blocking

Specificationhttps://github.com/explainers-by-googlers/script-blocking/blob/main/index.bs

Summary

Mitigating API Misuse for Browser Re-Identification, otherwise known as Script Blocking is a feature that will block scripts engaging in known, prevalent techniques for browser re-identification in third-party contexts. These techniques typically involve the misuse of existing browser APIs to extract additional information about the user's browser or device characteristics.

To strike this balance between protection and usability, this proposal focuses on blocking scripts in a third-party context in Incognito mode. This proposal uses a list-based approach, where only domains marked as “Impacted by Script Blocking” on the Masked Domain List (MDL) in a third-party context will be impacted.

When the feature is enabled, Chrome will check network requests against the blocklist.  This feature will reuse Chromium's subresource_filter component, which is responsible for tagging and filtering subresource requests based on page-level activation signals and a ruleset used to match URLs for filtering.

Blink componentBlink>Network>FetchAPI

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/1114

TAG review statusPending

Risks

Interoperability and Compatibility

There shouldn’t be any interop concerns.

You mention above that Chrome will use its own list and below that this is shipped in other engines.

I think the suggestion is that "script blocking" as a feature is shipping in several other engines. You're correct that the lists in use are distinct.

Do we expect to see convergence on that front?

In the status quo, browsers have landed on different heuristics and different list providers. It's unclear whether folks will generally agree on a list, and I'd suggest that it's probably more important for us to agree on the infrastructure and web-facing implications of blocking than to agree on the specific set of domains a given user agent chooses to block.

 

Do we expect other Chromiums to follow Chrome and use its list? Have their own? Something else?

We've published the list on GitHub, so it's entirely possible for other browsers to land on a similar list if it turns out to be effective.

On that list, I see 57 domains/hosts marked as "Some URLs are affected".

Are you planning to publish *which* URLs on those domains are affected? That would enable both eventual interoperability as well as allow affected sites to know they are affected, and hence appeal this in case they believe it's unjustified.

[Zainab Rizvi]

Thank you for the LGTM, Domenic! 

Thanks for the question, Yoav. At the moment, we are not planning on publishing which URLs are impacted for those domains because we were concerned with evasion by trivially changing those specific URLs. You raise a good point about interoperability so we'd be curious to hear if there is interest from other vendors in adopting parts of the list. 

[Yoav Weiss (@Shopify)]

On Fri, Jun 20, 2025 at 5:21 PM Zainab Rizvi <riz...@google.com> wrote:

Thank you for the LGTM, Domenic! 

Thanks for the question, Yoav. At the moment, we are not planning on publishing which URLs are impacted for those domains because we were concerned with evasion by trivially changing those specific URLs.

Can't impacted domains trivially move URLs to a different domain?
 

You raise a good point about interoperability so we'd be curious to hear if there is interest from other vendors in adopting parts of the list. 

Beyond interoperability, how are entities that have assets on any one of the 57 CDNs (that include AWS, Google, Cloudflare, DropBox, etc) supposed to know they are blocked? How should they appeal if they disagree with their blocking?