Introduce "override fetch".

[mikewest]

This change aims to explain how and when user agents intervene against requests in order to protect users. It introduces a few stage in Fetching, which gives user agents a clear hook after a set of prerequisite checks (MIX, CSP, etc.) are performed in Main Fetch.

This was originally proposed (and is explained in a bit more detail) in https://explainers-by-googlers.github.io/script-blocking/, and the hook's details and exact positioning were informed by the discussion in explainers-by-googlers/script-blocking#2.

• At least two implementers are interested (and none opposed):

  • Multiple browsers ship this kind of behavior (whether in the form of Safe Browsing, tracking protection, etc). The brief discussion in Location of this check explainers-by-googlers/script-blocking#2 suggests that there's interest in standardizing the broad strokes of the behavior by providing this implementation-defined hook.

• Tests are written and can be reviewed and commented upon at:

  • The exact set of resources against which user agents intervene is not (and likely cannot be) standardized. https://explainers-by-googlers.github.io/script-blocking/#testing suggests one approach to testing which might allow vendors to verify that their interventions are consistently positioned within Fetch, but that infrastructure hasn't yet been built or agreed-upon. If there's interest in doing so, I'll happily file an issue against web-platform-tests/rfcs to discuss.

• Implementation bugs are filed:

  • As above, all browsers currently ship something like this. In my (limited) testing, they all seem to agree on the broad strokes of when the check happens.

• MDN issue is filed:

  • This seems unnecessary for this change, but I'm happy to put together documentation if it's deemed helpful.

• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[mikewest]

Hey @annevk! This is my interpretation of your suggestion from explainers-by-googlers/script-blocking#2 (comment). Not at all an urgent request, but I'll appreciate feedback when you have time.

cc @domenic and @ZainabAq as an FYI, since y'all had excellent feedback on the original proposal.

[mikewest]

Friendly ping, @annevk: @slightlyoff asked about this in a thread on GitHub, so I would like to get it cleaned up and landed if it's still in-line with what you'd like to see.

[annevk]

Thanks for writing this up. I'd like to double check internally this is the kind of flexibility we are okay with, but generally this looks good to me. Based on that I left a number of editorial comments. I didn't spot anything wrong.

Would @bvandersloot-mozilla be a good person to okay this for Mozilla?

[mikewest]

Thanks for the suggestions (and especially for those you fixed yourself!), I've run through all of them and hope the PR is in decent shape for your colleagues and @bvandersloot-mozilla, et al. to run through as well.

[MayyaSunil]

@mikewest We discussed this internally at Mozilla and are aligned with this change. Thank you for putting it together.

[mikewest]

Thanks, @MayyaSunil! @annevk, anything to fix up from Apple's perspective?

[annevk]

No. I think for testing we should at least have some kind of issue filed. It doesn't have to be a WPT RFC though, unless Mozilla is interested in that.

[mikewest]

Filed web-platform-tests/rfcs#227.