Hey Yoav, thanks for your questions! On Monday, June 16, 2025 at 5:11:02 PM UTC+2 Yoav Weiss wrote:
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 Specificationhttps://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. I think the suggestion is that "script blocking" as a feature is shipping in several other engines. You're correct that the lists in use are distinct. Do we expect to see convergence on that front? In the status quo, browsers have landed on different heuristics and different list providers. It's unclear whether folks will generally agree on a list, and I'd suggest that it's probably more important for us to agree on the infrastructure and web-facing implications of blocking than to agree on the specific set of domains a given user agent chooses to block. Do we expect other Chromiums to follow Chrome and use its list? Have their own? Something else? We've published the list on GitHub <https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md>, so it's entirely possible for other browsers to land on a similar list if it turns out to be effective. 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? The explainer's Detection and Blocklist Creation section <https://github.com/explainers-by-googlers/script-blocking/#detection--blocklist-generation> lays out a high-level story, and https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md is a more detailed list of the domains affected. Is there a public appeal process? Yes, similar to the process for IP protection: see the "Appeals" section of the explainer <https://github.com/explainers-by-googlers/script-blocking/#appeals> for detail. -mike 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 Statushttps://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/1819e48d-a770-4424-ab10-b362c2d383aan%40chromium.org.
