Skip to content

Commit

Permalink
Remove CSP dynamic code compilation block
Browse files Browse the repository at this point in the history
This has been upstreamed to the CSP spec.
  • Loading branch information
lukewarlow committed Sep 9, 2024
1 parent cf78f7e commit 60f9094
Showing 1 changed file with 3 additions and 7 deletions.
10 changes: 3 additions & 7 deletions spec/index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -748,9 +748,9 @@ anElement.innerHTML = trustedTypes.emptyHTML; // no need to create a policy
: <dfn>emptyScript</dfn>
:: is a {{TrustedScript}} object with its [=TrustedScript/data=] value set to an empty string.

Note: This object can be used to detect if the runtime environment has [[#csp-eval]]. While native Trusted Types implementation can
support `eval(TrustedScript)`, it is impossible for a polyfill to emulate that, as
eval(TrustedScript) will return its input without unwrapping and evaluating the code.
Note: This object can be used to detect if the runtime environment has support for dynamic code compilation.
While native Trusted Types implementation can support `eval(TrustedScript)`, it is impossible for a polyfill to
emulate that, as eval(TrustedScript) will return its input without unwrapping and evaluating the code.

<div class="example" id="empty-script-example">
<xmp highlight="js">
Expand Down Expand Up @@ -1483,10 +1483,6 @@ strings (|createdPolicyNames|), this algorithm returns `"Blocked"` if the
`"Blocked"`.
1. Return |result|.

### Support for dynamic code compilation ### {#csp-eval}

Note: See [https://github.com/w3c/webappsec-csp/pull/659](https://github.com/w3c/webappsec-csp/pull/659) which upstreams this integration.

# Security Considerations # {#security-considerations}

Trusted Types are not intended to protect access to [=injection sinks=] in an
Expand Down

0 comments on commit 60f9094

Please sign in to comment.