- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 8 May 2012 12:43:52 -0700
- To: Tanvi Vyas <tanvi@mozilla.com>
- Cc: Daniel Veditz <dveditz@mozilla.com>, public-webappsec@w3.org
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 > 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 19:44:54 UTC