#1114: Script Blocking (in Incognito mode)

Visit on Github.

Opened Jun 16, 2025

Hi TAG,

I'm requesting an early TAG design review of Script Blocking in Incognito.

This is a proposal for a Chrome feature in Incognito mode that will block the execution of known, prevalent techniques for browser re-identification used in third-party contexts. These techniques generally involve the use of existing browser APIs in ways that do not match the API's intended purpose and are designed to extract additional information about the user's browser or device characteristics.

Discussions

Discussed Jun 16, 2025 (See Github)

we resolved above

Comment by @christianliebel Jun 18, 2025 (See Github)

@ZainabAq Thank you for your proposal. Unfortunately, the TAG must decline to review it, as your proposal seems to be tied to a specific implementation for a single browser. The TAG's role is to consider web architecture from a broad perspective. Also, it seems to be in a very early stage, as much of the required information is missing.

Please note that this is not negative feedback. The TAG supports all efforts to make browsing more private, and we believe that your proposal could be a web platform feature, especially given that many engines have developed proprietary solutions.

For example, you could specify (or update existing specifications) that user agents are allowed to block certain fetches for privacy reasons and define how these fetches fail. We assume this is currently done by "exploiting" network behavior (e.g., ERR_BLOCKED_BY_CLIENT in Chrome).

We specifically want to point to our Observations on Private Browsing Modes and the Don’t reveal that private browsing mode is engaged design principle.

We encourage you to reopen this issue once the proposal is suited for standardization as a cross-engine web platform feature.

Comment by @yoavweiss Jun 18, 2025 (See Github)

One thing this effort could be specifying is ways for user-agents to report to site developers that scripts on their sites were blocked by the UA.

Comment by @mikewest Jun 21, 2025 (See Github)

@christianliebel: The monkey-patching draft at https://explainers-by-googlers.github.io/script-blocking/ might have some of the additional detail you could be looking for. I think that document contains the extent of what could reasonably be specified given today's divergence between different vendors' decisions about exactly which HTTP requests they'll refuse to make (and/or choose to replace).

@yoavweiss: I think it's a non-goal to reveal something other than a network error to the page. That's consistent with the private mode guidance @christianliebel pointed to above, and also with the behavior other user agents have generally coalesced around. That said, devtools integrations seem like an important part of the story, and I'm sure all user agent vendors would appreciate suggestions and discussions around how to make the developer experience as pleasant as possible.