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 On Tue, Jul 22, 2025 at 4:00 PM Alex Russell <slightly...@chromium.org> wrote: > 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! > > On Tue, Jul 22, 2025, 11:47 AM Mike West <mk...@google.com> wrote: > >> 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%3DeX3%3DUG8acCZ%2B%3DBimN9vT%2BXMtWdBOAp0ZaBL9VZF7isUw%40mail.gmail.com.
