Intent to Ship: 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/whatwg/fetch/pull/1840

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, enhancing Incognito's protections against cross-site tracking when users choose to browse in this 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. 

1% Experiment Summary

Our 1% stable Incognito experiment did not show any statistically significant movement for Incognito-specific Core Web Vitals. Furthermore, we did not receive any breakage reports pertaining to this experiment.

As the feature is only enabled for third party resources in Incognito sessions, the sample size is smaller than we typically observe in a 1% experiment. We plan to carefully ramp the experiment to evaluate performance and stability impact before launching to Incognito 100%.

Blink component

Blink>Network>FetchAPI 

TAG review

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

TAG review status

Closed (resolution: decline)

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. We are attempting to mitigate this risk by applying temporary exceptions if we determine that the intervention on a particular domain may cause significant user experience impact.

Gecko: No signal

WebKit: Shipped/Shipping Safari has a similar feature as part of "Intelligent Tracking Prevention" (ITP)

Firefox: Shipped/Shipping Firefox has a similar feature as part of "Enhanced Tracking Protection" 

Web developers: <will fill out after explainer publication> 

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?

No, we are not proposing to ship this on WebView.

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 even before we ship.

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?

We are exploring ways to test this feature via WPT. This isn’t possible today given the implementation-defined nature of blocked resources. Some explorations are discussed here.

Flag name on about://flags

chrome://flags/#enable-fingerprinting-protection-blocklist-incognito

Finch feature name

EnableFingerprintingProtectionInIncognito

Rollout plan

(RARE) Experiment users ramp up over time

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/431761692

Launch bug

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

Estimated milestones

Shipping on Desktop	140
Shipping on Android	140

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5188989497376768

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/NJvGkSvLk8I?e=48417069 

[Alex Russell]

Will this be enabled for all Chromium browsers by default?

[Zainab Rizvi]

Hi, Alex! This will only be enabled for Chrome's Incognito mode. 

[Gregg Tavares]

Does this enable more detection of incognito mode by sites? 

--
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/CAFhOYsjkJMw5aXR6T%3DQiiajtqAC0s9uqaWEZYgM6J4hUj5W7fA%40mail.gmail.com.

[Zainab Rizvi]

Yes, though Script Blocking in Incognito would have the same observable effect as extensions that block resources, such as ad blockers. The team is also adding monitoring to see if incognito detectability is on the rise due to these features.  

[Chris Harrelson]

In case of something breaking: When a script is blocked, is the user able to find that out in a site settings dialog?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjGDTA_6ONhuHAxhg7yi-n9kC2y9JdL5nXtUzjb3FXd2Q%40mail.gmail.com.

[Zainab Rizvi]

Hi Chris! We will have a few UI indicators when a resource is blocked:

1. The "eye" icon will show up in the Omnibox that will allow users to disable the feature on a particular top-level site. 

2. There is a toggle in settings for users to disable the feature entirely.

3. For developers, a dedicated issue will pop up in the "Issues" tab. 

4. For developers, there is a dedicated network error in the "Network" tab. 

[Chris Harrelson]

Ok, thanks for clarifying.

LGTM1

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsieQ5z%3DKQEOQ_ELRSXHW1-agGASiD0aaVpkCku_BR%2BL%2Bg%40mail.gmail.com.

[Philip Jägenstedt]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-WO%3DLD3JeHnD3Bz%2BfO2YACZfFaaCAv2VzERBNP23fmNw%40mail.gmail.com.

[Alex Russell]

I remain concerned that this behaviour isn't going to be shared by other Chromium-based browsers. Web Platform behaviour differences between our implementations opens up risks of ongoing divergence, and so I'm going to LGTM3 on the condition that documentation is produced for other embedders that wish to adopt the same behaviour in a straightforward way.

Best,

Alex

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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjkJMw5aXR6T%3DQiiajtqAC0s9uqaWEZYgM6J4hUj5W7fA%40mail.gmail.com.

--
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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjGDTA_6ONhuHAxhg7yi-n9kC2y9JdL5nXtUzjb3FXd2Q%40mail.gmail.com.

--
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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsieQ5z%3DKQEOQ_ELRSXHW1-agGASiD0aaVpkCku_BR%2BL%2Bg%40mail.gmail.com.

--
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.

[Mike West]

Hey Alex! Thanks for your feedback (and LGTM :) )!

On documentation: we have a PR up against Fetch at https://github.com/whatwg/fetch/pull/1840 which aims to clarify the timing and web-facing impact of a blocking decision, and the list of affected domains is up at https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md. What additional documentation would you like to see that would improve consistency across vendors?

That said, I think we have to broadly accept that different vendors are going to make different decisions about which resources they allow to load in a given context. This is already the case from a security perspective with choices between Safe Browsing and SmartScreen, and is already the case from a privacy perspective with decisions around subsetting blocklist vendors' lists which vary given each user agent's priorities and risk tolerance. I don't think it's likely that there's going to be alignment on a single list in the near-term. That doesn't seem fatal to me, as long as we agree on the web-facing impact. Does that more or less align with your view, or should we be aiming for a different compatibility bar in the long run?

-mike

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/CAFhOYsjkJMw5aXR6T%3DQiiajtqAC0s9uqaWEZYgM6J4hUj5W7fA%40mail.gmail.com.

--
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/CAFhOYsjGDTA_6ONhuHAxhg7yi-n9kC2y9JdL5nXtUzjb3FXd2Q%40mail.gmail.com.

--
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/CAFhOYsieQ5z%3DKQEOQ_ELRSXHW1-agGASiD0aaVpkCku_BR%2BL%2Bg%40mail.gmail.com.

--
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.

[Alex Russell]

Nothing first that I'm not asking from an Edge perspective (we have the resources to follow along with most things y'all do), a sketch for how a small browser might implement bloxking using the same list y'all do would be enough for me.

Thanks!

[Mike West]

Ok, it sounds like you're asking for something conceptually similar to https://learn.microsoft.com/en-us/microsoft-edge/web-platform/tracking-prevention? I think we can pull that together.

Thanks for the suggestion!

-mike

[Yoav Weiss (@Shopify)]

Some questions I asked on the I2E are still left unanswered.

Overall, I think this feature will cause interop issues by definition, at least for the 57 domains on the list that are marked as "some URLs are affected". 

I'd appreciate it if y'all can hold back on shipping this until this is further discussed at the API owners meeting.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeX3%3DUG8acCZ%2B%3DBimN9vT%2BXMtWdBOAp0ZaBL9VZF7isUw%40mail.gmail.com.

[Alex Russell]

(sorry for previous typos)

Per today's API OWNERS meeting, this intent is being held until Yoav's questions are resolved. I don't expect that this will be delayed long, and stakeholders will meet soon and update this thread with resolutions.

Best,

Alex

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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjkJMw5aXR6T%3DQiiajtqAC0s9uqaWEZYgM6J4hUj5W7fA%40mail.gmail.com.

--
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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjGDTA_6ONhuHAxhg7yi-n9kC2y9JdL5nXtUzjb3FXd2Q%40mail.gmail.com.

--
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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsieQ5z%3DKQEOQ_ELRSXHW1-agGASiD0aaVpkCku_BR%2BL%2Bg%40mail.gmail.com.

--
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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-WO%3DLD3JeHnD3Bz%2BfO2YACZfFaaCAv2VzERBNP23fmNw%40mail.gmail.com.

--
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.

[Zainab Rizvi]

Some of the team met with Yoav to discuss his concerns, primarily those around list interop and inquiries/appeals coming from 3rd party scripts hosted on CDNs.

For those interested in list interop, we plan to propose a breakout session at TPAC on the topic, and look forward to collaborating with other vendors and interested folks (feel free to reach out to us directly before TPAC).

We also discussed revising our appeals and inquiries process to allow owners of third-party assets to confirm a list of affected resources hosted on a CDN directly from Disconnect. This way CDN providers need not be involved in the process as intermediaries.

We further discussed how blocked resources are surfaced in DevTools Issues and the Network Panel, so developers should also be able to discover affected resources independently.

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/CAFhOYsjkJMw5aXR6T%3DQiiajtqAC0s9uqaWEZYgM6J4hUj5W7fA%40mail.gmail.com.

--
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/CAFhOYsjGDTA_6ONhuHAxhg7yi-n9kC2y9JdL5nXtUzjb3FXd2Q%40mail.gmail.com.

--
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/CAFhOYsieQ5z%3DKQEOQ_ELRSXHW1-agGASiD0aaVpkCku_BR%2BL%2Bg%40mail.gmail.com.

--
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/CAOMQ%2Bw-WO%3DLD3JeHnD3Bz%2BfO2YACZfFaaCAv2VzERBNP23fmNw%40mail.gmail.com.

--
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.

[Yoav Weiss (@Shopify)]

Thanks Zainab!

My concerns were indeed addressed:

* On the interop front, the team showed willingness to collaborate with other browsers/engines on a more accurate, but not-necessarily-public list.

* My concerns regarding the appeal process were addressed by the team's willingness to revise the process and potentially not require platform providers to be in the loop when appeals are made by 3rd parties RE resources that are hosted on their CDNs. I suspect that would make it significantly more feasible.

So from my perspective, this intent can be unblocked (and I believe it has the 3 required LGTMs).