Re: Multiple Content-Security-Policy headers

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:06:12 UTC