- From: Eric Rescorla <ekr@rtfm.com>
- Date: Tue, 8 May 2012 13:35:43 -0700
- To: Tanvi Vyas <tanvi@mozilla.com>
- Cc: Adam Barth <w3c@adambarth.com>, Daniel Veditz <dveditz@mozilla.com>, public-webappsec@w3.org
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