Re: Making it easier to deploy CSP.

On Tuesday, February 16, 2016, Artur Janc <aaj@google.com> wrote:

> On Mon, Feb 15, 2016 at 1:46 AM, Conrad Irwin <conrad.irwin@gmail.com
> <javascript:_e(%7B%7D,'cvml','conrad.irwin@gmail.com');>> wrote:
>
>> 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.
>>
>
> This could likely be simplified to: *scripts created with
> document.createElement('script') *without much loss of generality.
>

I like this a lot more, would be happy with this being the definition and
having the document responsible for blessing the script at element creation
time; in general I don't think it's useful to transfer script elements
between documents so it would be good to have the policy prevent scripts
that are appended or copied around from running unless they were created by
the same documents createElement.



>
> Interesting... I think either behavior would be acceptable for the
> purposes of unsafe-dynamic so it's a question of what makes more sense for
> the spec and implementations. If you explicitly call
> appendChild([script-from-another-document]) then you are presumably doing
> it intentionally so the script could be blessed to execute. At the same
> time, we could stick to the very narrow definition of "script needs to be
> created with document.createElement()" and in practice the value of
> unsafe-dynamic wouldn't be diminished (the majority of JS APIs and widgets
> will be covered).
>
>
> These are both fair points. I mentioned some of our original rationale for
> requiring nonces and ignoring the whitelist in my reply to Martin --
> overall, there is precedent for adding new CSP directives in a
> backwards-compatible way, e.g. nonce-source causes 'unsafe-inline' to be
> ignored, so it seemed like continuing along the same vein might be
> preferable.
>
> Do you see any alternative approach which would not require user-agent
> detection? (I'm worried that it could be another non-trivial obstacle to
> CSP adoption, on top of some already difficult challenges).
>

I can't think of an easy one, so this may be a case for pragmatism beats
purity. The better approach is obviously the manual nonce one in all of
your code :) this is very much a transitionary hack, so it would be nice if
browsers don't have to support this long term anyway...


>
> Cheers,
> -Artur
>
>
>
>> Sent via Superhuman <https://superhuman.com/?utm_source=signature>
>>
>> On Sun, Feb 14, 2016 at 3:58 PM, Martin Thomson<martin.thomson@gmail.com
>> <javascript:_e(%7B%7D,'cvml','martin.thomson@gmail.com');>>wrote:
>>
>>> On 14 February 2016 at 16:39, Devdatta Akhawe <dev.akhawe@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','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.
>>>
>>
>>
>