- From: Tanvi Vyas <tanvi@mozilla.com>
- Date: Tue, 08 May 2012 13:05:48 -0700
- To: Adam Barth <w3c@adambarth.com>
- CC: Daniel Veditz <dveditz@mozilla.com>, public-webappsec@w3.org
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