The behaviour of `unsafe-dynamic` you propose seems pretty confusing to describe to me (you have to distinguish between "parser-inserted" and not), and I'm not sure how it integrates with other browser functionality.

A particular case I'm confused about is:

1. create a new document with document.implementation.createDocument()

2. use that document to safely parse untrusted HTML (as is done by DOMPurify)

3. use appendChild() to copy nodes from that document into a second document

It seems like the scripts would run in that case (assuming the target document had a CSP of `unsafe-dynamic`), even though the scripts were created by the parser?

I'm also worried that it randomly tinkers with other parts of the CSP in peculiar ways (a `hash` or a `nonce` is required to run the initial script, you can't use an origin or `unsafe-inline` or `unsafe-eval`).

I'm not totally against the idea, because it seems useful to get more people using a CSP, but I think the current approach is very complicated. It might be simpler to add `unsafe-dynamic` that lets you do appendChild(script); but which doesn't break any of the other CSP directives, and solve the compatibility issue with server-side user-agent detection.

Sent via Superhuman

On Sun, Feb 14, 2016 at 3:58 PM, Martin Thomson<martin.thomson@gmail.com>wrote:

On 14 February 2016 at 16:39, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
Personally, my preference for increasing complexity is in the order---web apps and then browsers and then standards.
The priority of constituencies would (perfectly) disagree on this point.
https://www.w3.org/TR/html-design-principles/#priority-of-constituencies
The thing I'm trying to wrap my head around is how this fits with the general CSP design pattern. How does adding this directive narrow the set of things that are permitted? It actually appears to do the opposite. The purpose being to give dynamically inserted scripts an exemption.