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