Add external <script type=speculationrules>

[vickiez]

Add external <script type="speculationrules">

Allows a speculation rules script element to have a src pointing to a
file of speculation rules, enabling developers to easily reuse a set of
speculation rules across HTML documents.

WICG/nav-speculation#348

Spec changes:

• Add a row for external speculation rules in the attributes table of
  4.12.1 The script element

• During prepare the script element, handle the case where src
  content attribute is present and type is "speculationrules"

• Define a "fetch speculation rules" algorithm to be used by both the
  external script and 7.6.3 The Speculation-Rules header sections.

---

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/blob/master/speculation-rules/external-speculation-rules-errors.html
  • CL with test update: https://chromium-review.googlesource.com/c/chromium/src/+/7034064/9/third_party/blink/web_tests/external/wpt/speculation-rules/external-speculation-rules.html
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/40170951
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2008350
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=305428
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
• Corresponding HTML AAM & ARIA in HTML issues & PRs:
• MDN issue is filed: Add external <script type=speculationrules> mdn/mdn#789
• The top of this comment includes a clear commit message to use.

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

---

/scripting.html ( diff )
/speculative-loading.html ( diff )
/webappapis.html ( diff )

[noamr]

Thanks for working on this! See initial comments.

[noamr]

This destination needs to be defined in the fetch spec.

[vickiez]

There's a change in progress here: whatwg/fetch#1841. Happy to help with that one, is there a proper order for merging the changes across specs?

[domfarolino]

Merging them as close together as possible provided they are both unblocked and generally agreed upon is fine. But regarding this PR: is there cross-browser interest in this feature overall? The PR template is pretty scant.

[vickiez]

Filled in the PR template with implementation bugs and just created position requests here:
Support external <script type=speculationrules> · Issue #1343 · mozilla/standards-positions
Support external <script type=speculationrules> · Issue #604 · WebKit/standards-positions

[vickiez]

Also for some context - this change was meant to be included in the base speculation rules spec change to achieve completeness. I was planning on merging it into Domenic's branch, but his change was merged into HTML first. See the comment here - #11123 (comment)

[domfarolino]

See #11697 (comment), but just so the sentiment doesn't get lost in that thread, let me ask here: is there cross-browser support for this? I'm asking because the PR template is a bit bare and I'm not sure where other folks stand on this PR, although I'm happy to review it.

[hiroshige-g]

For CSP, there are three conceptually separate things being discussed in the context of external speculation rules:

• [1] Applying some CSPs to external <script type="speculationrules">.
• [2] Introduce new speculation rules CSP directives, moving out from script-ish handling (not limited to external external <script type="speculationrules">):
  • Integrate with speculation rules w3c/webappsec-csp#776
  • Add the "speculationrules" destination fetch#1841
• [3] The discrepancy between loading speculation rules from HTTP headers (CSP exempted) and from external <script type="speculationrules"> (CSP applied).
  • Working as intended in the current spec: https://html.spec.whatwg.org/multipage/speculative-loading.html#speculative-loading-injected-content
  • Revisiting e.g. in Add the "speculationrules" destination fetch#1841 (comment)

Do we want to settle all of them before implementing (or shipping?) external <script type="speculationrules">? Or do we want to proceed incrementally? Or should we decouple [2] and [3] from the core effort of external <script type="speculationrules">?

I think applying script-src to external <script type="speculationrules"> can be a first incremental step (satisfying [1] in pre-[2] settings, while [2] and [3] can be still separately tackled), but I'd like to hear how the CL author (@vickiez) and CSP folks (@mikewest @antosart) think about this kind of planning.

[antosart]

Proceeding in steps makes sense to me, although it probably makes sense to have an idea of the plan so that decisions we take first don't block us later on.

For [1] and [2], if we want a new CSP directive that applies to speculationrules, defining it right away might make more sense than enforcing script-src temporarily and later changing it. Unless we decide that the new directive will fall back to script-src if not present (which could make perfectly sense), in which case doing [1] first and later [2] sounds good to me.

The discussion on [3] can come later. If the only reason for exempting headers is this one, then a new directive could solve that problem, too.

[vickiez]

Thank you for clarifying the issues @hiroshige-g, and +1 to @antosart on proceeding incrementally with a plan in mind.

I think it makes sense to use script-src as a fallback to the new directive; sounds like developers did expect CSP to apply to script elements and it already takes effect for inline scripts. This is how I see the plan:

After [1]:

• Header: exempt from CSP
• Script element: script-src-elem → script-src → default-src

After [2] introduces a new speculationrules directive:

• Header: speculationrules → default-src
• Script element: speculationrules → script-src-elem → script-src → default-src

For [3], the header/script discrepancy can be resolved as part of [2] since a dedicated directive avoids the strict-CSP problem that motivated the header exemption in the first place.

So the plan would be:

1. Apply initial CSPs to external <script type="speculationrules"> (CL)
2. Follow-up (Integrate with speculation rules w3c/webappsec-csp#776 + Add the "speculationrules" destination fetch#1841): Introduce the speculationrules directive, applying to both header and script element, with appropriate fallback chain

Does that align with everyone's thinking?

[antosart]

After [2] introduces a new speculationrules directive:

• Header: speculationrules → default-src
• Script element: speculationrules → script-src-elem → script-src → default-src

Why not having both resolve in the same way as speculationrules → script-src-elem → script-src → default-src? Seems easier not to have to differentiate between the two.

[vickiez]

After [2] introduces a new speculationrules directive:

• Header: speculationrules → default-src
• Script element: speculationrules → script-src-elem → script-src → default-src

Why not having both resolve in the same way as speculationrules → script-src-elem → script-src → default-src? Seems easier not to have to differentiate between the two.

I agree it is simpler to have the same fallback chain. I was thinking of the friction that motivated header CSP exemption in https://chromestatus.com/feature/5123809745829888, but sites will be able to avoid breakage from strict script-src policies by using the new speculationrules directive. If that sounds good to everyone, here is the revised plan:

After [2] introduces a new speculationrules directive:

• Header and script element: speculationrules → script-src-elem → script-src → default-src