Exempt the Speculation-Rules header from CSP

Per discussions, this is outside of CSP's threat model.

speculation-rules.bs

@@ -755,10 +755,11 @@ The algorithm needs patches to handle the "`script speculationrules`" type at th
 
 <h3 id="content-security-policy-patches-effective-directive">Get the effective directive for request</h3>
 
-The switch needs one additional case. At present, requests can only be issued in the case of the [:Speculation-Rules:] header, so `script-src-elem` is too specific and only `script-src` (or its fallback, `default-src`) applies.
+In [[CSP#effective-directive-for-a-request]], the switch on the request [=request/destination=] needs one additional case.
+<p class="note">At present, requests can only be issued in the case of the [:Speculation-Rules:] header, so CSP does not apply. If support is added for loading external rule sets via `<script src>`, for which CSP would apply, then the CSP directive selection will need to distinguish this case, such as by the introduction of a new request [=request/initiator=].</p>
 
 :  "`speculationrules`"
-:: 1. Return `script-src`.
+:: 1. Return null.
 
 <h2 id="fetch">Fetch</h2>
 
@@ -794,7 +795,7 @@ The same mitigations available to other features also apply here. In particular,
 
 The possibility of leaking link URLs via this mechanism is additionally mitigated by the fact that prefetch and prerender to plaintext HTTP (other than to localhost) is not permitted, and so such an on-path attacker could not directly observe preloading request URLs, but would only have access to metadata and traffic analysis. This does not, however, replace standard XSS protections.
 
-It's generally not expected that user-generated content will be added as arbitrary response headers; server operators are already going to encounter significant trouble if this is possible. It is therefore unlikely that the [:Speculation-Rules:] header meaningfully expands the XSS attack surface. Nonetheless, the [[CSP]] `script-src` directive applies in this case as well.
+It's generally not expected that user-generated content will be added as arbitrary response headers; server operators are already going to encounter significant trouble if this is possible. It is therefore unlikely that the [:Speculation-Rules:] header meaningfully expands the XSS attack surface. Therefore, [[CSP]] does not apply to the loading of rule sets via the header.
 
 <h3 id="type-confusion">Type confusion</h3>
 

triggers.md

@@ -98,7 +98,7 @@ The following example illustrates the basic idea:
 </script>
 ```
 
-(The use of `<script>` is basically because only a few elements allow the HTML parser to enter RCDATA mode, and `<script>` has already been used in this way. This doesn't necessarily mean that these rules should respect the `script-src` CSP directive.)
+(The use of `<script>` is basically because only a few elements allow the HTML parser to enter RCDATA mode, and `<script>` has already been used in this way. See [this section](#content-security-policy) for the impact of this choice on CSP.)
 
 For use cases where it is preferable to provide speculation rule sets without modifying a document, we introduce the `Speculation-Rules` HTTP header. The header's values are URLs to external resources containing speculation rule sets. The rules are expressed in the same JSON object format as the inline case. The MIME type of the resource must be `application/speculationrules+json`.
 
@@ -280,6 +280,8 @@ For document rules, `"relative_to"` can be paired directly with `"href_matches"`
 
 Speculation rules can be embedded inline within a `script` tag with `type="speculationrules"`, and restricted by the `script-src` and `script-src-elem` CSP directive. To allow inline speculation rules, use either the `'inline-speculation-rules'` or `'unsafe-inline'` keyword. Using `script-src 'inline-speculation-rules'` or `script-src-elem 'inline-speculation-rules'` helps developers to permit inline speculation rules but still disallow unsafe inline JavaScript.
 
+The loading of rules via the `Speculation-Rules` HTTP header is not restricted by CSP.
+
 The `default-src` directive can be used to restrict which URLs can be prefetched or prerendered.
 
 ### Eagerness
@@ -385,11 +387,9 @@ Another possible future extension, which would likely need to be restricted to s
 
 ### External speculation rules via script elements
 
-Like import maps, `<script>` elements can currently only load speculation rules inline, with the speculation rules JSON being contained in the `<script>` element's child text content. However, [like import maps](https://github.com/WICG/import-maps/issues/235), it would be convenient for authors if we allowed `<script type="speculationrules">` to instead have an `src=""` attribute pointing to an external URL.
-
-The requirements for external rule sets loaded via the `Speculation-Rules` header would also apply here, such as the use of the `application/speculationrules+json` MIME type.
+Like import maps, `<script>` elements can currently only load speculation rules inline, with the speculation rules JSON being contained in the `<script>` element's child text content. However, [like import maps](https://github.com/WICG/import-maps/issues/235), it would be convenient for authors if we allowed `<script type="speculationrules">` to instead have a `src=""` attribute pointing to an external URL.
 
-Some questions to answer here include the interaction with CSP. The answers might not necessarily be the same for import maps and speculation rules, since import maps give a more direct ability to interfere with script execution.
+The requirements for external rule sets loaded via the `Speculation-Rules` header would also apply here, such as the use of the `application/speculationrules+json` MIME type. Unlike the header, we would enforce CSP for `<script src>`.
 
 ### More speculation actions