Add the "speculationrules" destination

[domenic]

Part of whatwg/html#11426, for requests initiated by the Speculation-Rules HTTP header.

---

This should be merged a bit after whatwg/html#11426. Otherwise it will reference the WICG draft.

• At least two implementers are interested (and none opposed):
  • See Add speculation rules prefetch html#11426
• Tests are written and can be reviewed and commented upon at:
  • This is tested by all tests of the header: https://github.com/web-platform-tests/wpt/blob/c669bcf970fe50b56e0ee53de9c2097a012dafc7/speculation-rules/prefetch/resources/ruleset.py#L40-L43
• Implementation bugs are filed:
  • See Add speculation rules prefetch html#11426
• MDN issue is filed: "speculationrules" request destination missing mdn/content#40289
• The top of this comment includes a clear commit message to use.

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

---

Preview | Diff

[domenic]

This is ready to merge!

[annevk]

I'm a bit torn on the spelling consistency with existing destinations as I believe Dictionary Compression and FedCM are breaking it (not sure if intentionally, but probably too late to change).

[annevk]

Are you sure this is accurate? Wouldn't this be governed by connect-src at least?

[domenic]

No, per discussion with CSP folks, header-initiated fetches are not generally governed by CSP at all. The reasoning is that CSP is a mechanism for protection against HTML injection defense, not header-injection defense; if an attacker can inject headers, then they can mess up your CSP and do all sorts of bad things.

I guess Link might be governed by CSP, but that's more of a historical accident...

[annevk]

I'm not sure I agree with that.

I think it also depends on the order the headers are processed in. If the CSP header is processed first (and I hope that it is), any fetch following it would automatically be subject to CSP.

[domenic]

Yeah, not sure, probably something to discuss with the CSP spec editors if you want to make changes to that policy...

[annevk]

@antosart mind chiming in?

I think in the HTML standard we create a policy container from navigation response first thing and I wouldn't expect us to fetch anything else before that is complete. (This happens deep into https://html.spec.whatwg.org/#create-navigation-params-by-fetching if I'm reading things correctly.)

Are you also suggesting for instance that we would not take Referrer Policy into account here?

[antosart]

If I understand correctly, fetches do indeed happen after the policy container is created from the navigation response. However, the current proposal is to have Speculation-Rules headers explicitly bypass CSP by allowlisting the "speculationrules" destination in CSP (w3c/webappsec-csp#776). Digging a bit, that seem to be the result of experiments and discussion (see https://chromestatus.com/feature/5123809745829888?gate=5093909324365824).

I expect the reason for this to be rooted in the attempt of CSP to do (at least) two things at the same time, i.e. control script execution and gate outgoing requests (which in the case of script-src end up colliding even if they are conceptually distinct - fetching a script content is not the same as executing it). Gating the Speculation-Rules header behind script-src would make it impossible to use the feature with strict CSP. Gating it behind something else (e.g. connect-src) could be somehow confusing given that the other way to specify speculationrules is in a script tag (for which script-src does apply). It's not totally clear to me what the best option is here, but I think it would make sense to have some record/explanation of why the choice was made.

[annevk]

I don't think that the usage of <script> necessarily implies script-src. script-src makes sense when the result is script execution, but if we were to use <script> for JSON modules or some such it shouldn't use script-src but the same thing that the "json" destination devolves into. I think the same kind of rationale applies here, which I suspect means connect-src in the end.

I know some at Google don't care about the exfiltration angle of CSP, but I don't think we have ever reached agreement on giving up on it, so until we get there I think new fetch contexts should play by the same rules as existing ones.