Re: Multiple Content-Security-Policy headers

We have time scheduled for it.

On Tue, May 8, 2012 at 1:05 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:
> On 5/8/12 12:43 PM, Adam Barth wrote:
>>
>> On Tue, May 8, 2012 at 11:17 AM, Tanvi Vyas<tanvi@mozilla.com>  wrote:
>>>
>>> Thinking about this a bit more, I like Adam's proposed method - take each
>>> source through all policies, if a source is forbidden by any one of them,
>>> the source is not allowed.
>>>
>>> This method is more future proof and doesn't require the spec to specify
>>> intersections per directive.  Suppose that in the future we have a
>>> directive
>>> "fruit" with 2 possible values - "apples" and "oranges".  Neither
>>> directive
>>> value is safer than the other, but one policy may have the value "apples"
>>> and another may have the value "oranges".  Using this method, "apples"
>>> will
>>> only be allowed if it passes all policies.  (The corresponding
>>> intersection
>>> rule for this directive would then be to only include this directive in
>>> the
>>> combined policy if it exists in all policies with the same value.
>>>  Otherwise, don't include this directive at all.)
>>>
>>> As far as implementation, browser vendors could decide (for performance
>>> reasons) to create per directive intersection rules that would yield the
>>> same behavior as this method.
>>>
>>> One question - what would happen if the two policies had different
>>> report-uris?  If we follow this heuristic, we wouldn't send any reports,
>>> correct?
>>
>> Given two policies A and B, the current spec will send violations of
>> policy A to any report URIs in policy A and any violations of policy B
>> to report URIs in policy B.  We can loosen this up to make it
>> permissible to send violations to all the report-uris if that's easier
>> for you to implement.
>>
>> Adam
>>
> Let's discuss this on today's call.
>
> ~Tanvi
>
>
>
>>> On 5/7/12 6:07 PM, Daniel Veditz wrote:
>>>>
>>>> On 5/7/12 3:36 PM, Adam Barth wrote:
>>>>>
>>>>> On Mon, May 7, 2012 at 3:29 PM, Tanvi Vyas<tanvi@mozilla.com>    wrote:
>>>>>>
>>>>>> Instead, what if we set precedence for different types of headers.  If
>>>>>> firefox see's Content-Security-Policy and X-Content-Security-Policy,
>>>>>> it
>>>>>> ignores X-Content-Security-Policy.  If Webkit sees
>>>>>> Content-Security-Policy
>>>>>> and X-WebKit-CSP, it ignores X-WebKit-CSP.  If either browser see's
>>>>>> two
>>>>>> of
>>>>>> the same headers (2 Content-Security-Policy, 2
>>>>>> X-Content-Security-Policy, or
>>>>>> 2 X-Webkit-CSP), set the policy to default-src 'none'.
>>>>>
>>>>> I'd rather not spec what implementations should do with
>>>>> vendor-prefixed headers, if we can avoid it.
>>>>>
>>>>> I guess I was mistaken.  I thought you and dveditz preferred that the
>>>>> user agent combined multiple policies.  If you and Dan would prefer
>>>>> that multiple Content-Security-Policy headers cause the user agent to
>>>>> enforce default-src 'none', I'm happy to update the spec to require
>>>>> that.
>>>>
>>>> We definitely prefer combined policies; it seems far more useful
>>>> than default-src 'none'. Whether you apply each in series or try to
>>>> intersect them for performance reasons is an implementation detail
>>>> that should lead to the same result. We're fine having it specified
>>>> that clients should behave "as if" they were combined that way.
>>>>
>>>> Whether the standard header should obsolete any experimental ones or
>>>> combine with it is a separate issue and was the main thrust of
>>>> Tanvi's mail. I've been assuming we'd obsolete the
>>>> experimental/prefixed versions but you're not wrong that it might be
>>>> useful for experimentation with future features. Probably better
>>>> than prefixed directives, anyway.
>>>>
>>>> -Dan Veditz
>>>
>>>
>
>

Received on Tuesday, 8 May 2012 20:36:47 UTC