On Mon, Jun 16, 2025 at 4:24 PM 'Zainab Rizvi' via blink-dev < blink-dev@chromium.org> wrote:
> Contact emailsriz...@google.com, mk...@chromium.org > > Explainerhttps://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) > <https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md> > 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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EFetchAPI%22> > > 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. 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? > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?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 Status > https://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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsgKDRo%3D0g%2BtJpej_ET0_2Ed20B407myiu%3D%2BicVnB7JboQ%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/CAOmohSLS9T2j5A%2BHzMpCzS8mgWohJOaWGMqeywwG7T--Tka4%3Dg%40mail.gmail.com.
