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 On Tue, Jul 22, 2025 at 12:07 PM Alex Russell <slightly...@chromium.org> wrote: > 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 > > On Wednesday, July 16, 2025 at 6:39:57 PM UTC+1 Philip Jägenstedt wrote: > >> LGTM2 >> >> On Wed, Jul 16, 2025 at 5:55 PM Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> Ok, thanks for clarifying. >>> >>> LGTM1 >>> >>> On Wed, Jul 16, 2025 at 8:51 AM 'Zainab Rizvi' via blink-dev < >>> blink-dev@chromium.org> wrote: >>> >>>> 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 >>>> <https://source.chromium.org/chromium/chromium/src/+/main:net/base/net_error_list.h;l=136?q=BLOCKED_BY_FINGER&sq=&ss=chromium> >>>> in >>>> the "Network" tab. >>>> >>>> On Wed, Jul 16, 2025 at 11:32 AM Chris Harrelson <chris...@chromium.org> >>>> wrote: >>>> >>>>> In case of something breaking: When a script is blocked, is the user >>>>> able to find that out in a site settings dialog? >>>>> >>>>> On Tue, Jul 15, 2025 at 7:59 AM 'Zainab Rizvi' via blink-dev < >>>>> blink-dev@chromium.org> wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> On Mon, Jul 14, 2025 at 7:23 PM Gregg Tavares <g...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Does this enable more detection of incognito mode by sites? >>>>>>> >>>>>>> On Mon, Jul 14, 2025 at 1:08 PM 'Zainab Rizvi' via blink-dev < >>>>>>> blink-dev@chromium.org> wrote: >>>>>>> >>>>>>>> Hi, Alex! This will only be enabled for Chrome's Incognito mode. >>>>>>>> >>>>>>>> On Mon, Jul 14, 2025 at 2:19 PM Alex Russell < >>>>>>>> slightly...@chromium.org> wrote: >>>>>>>> >>>>>>>>> Will this be enabled for all Chromium browsers by default? >>>>>>>>> >>>>>>>>> On Monday, July 14, 2025 at 8:54:57 AM UTC-7 riz...@google.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> <https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md> >>>>>>>>>> (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 >>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> <https://explainers-by-googlers.github.io/script-blocking/#testing> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> <https://issues.chromium.org/issues/370696608> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>> 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+unsubscr...@chromium.org. >>>>>>>> To view this discussion visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjkJMw5aXR6T%3DQiiajtqAC0s9uqaWEZYgM6J4hUj5W7fA%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjkJMw5aXR6T%3DQiiajtqAC0s9uqaWEZYgM6J4hUj5W7fA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>> 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+unsubscr...@chromium.org. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjGDTA_6ONhuHAxhg7yi-n9kC2y9JdL5nXtUzjb3FXd2Q%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjGDTA_6ONhuHAxhg7yi-n9kC2y9JdL5nXtUzjb3FXd2Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsieQ5z%3DKQEOQ_ELRSXHW1-agGASiD0aaVpkCku_BR%2BL%2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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+unsubscr...@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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-WO%3DLD3JeHnD3Bz%2BfO2YACZfFaaCAv2VzERBNP23fmNw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcoG9g7PfsKLYHQW27EpTNoACR43AdmoONNEGL8kW5a4A%40mail.gmail.com.
