RE: ISSUE-4: Policy combination

I have been curious for a while now: in every instance previous to "first-wins", policy combinations resulted in the least privilege implied by the union.  But when an enforceable policy and a report-only policy are both present, report-only gets to override and negate enforcement.  This behavior remains in the new "first-wins" language. 

What's the reason for this exception to the general philosophy?   

I admit I'm being lazy here in not trawling the archives, but it is at least an on-topic question now. :)

-Brad

> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Thursday, December 08, 2011 6:16 PM
> To: Brandon Sterne
> Cc: public-webappsec@w3.org; Giorgio Maone
> Subject: Re: ISSUE-4: Policy combination
> 
> I've updated the spec reflect the "first-wins" behavior.
> 
> Adam
> 
> 
> On Thu, Dec 8, 2011 at 1:57 PM, Brandon Sterne <bsterne@mozilla.com>
> wrote:
> > I'm also fine with making the change to Adam's "first-wins" proposal.
> >
> > -Brandon
> >
> >
> > ----- Original Message -----
> > From: "Adam Barth" <w3c@adambarth.com>
> > To: "Giorgio Maone" <g.maone@informaction.com>
> > Cc: public-webappsec@w3.org
> > Sent: Thursday, December 8, 2011 1:16:03 PM
> > Subject: Re: ISSUE-4: Policy combination
> >
> > On Thu, Dec 8, 2011 at 12:55 PM, Giorgio Maone
> <g.maone@informaction.com> wrote:
> >> Eric Rescorla wrote, On 08/12/2011 21.32:
> >>> 1. In the header, a policy which specifies a policy-uri which takes
> >>> 10 seconds to load. 2. In the body, a meta tag with a complete
> >>> policy Which one of these did the agent "encounter first"?
> >>
> >> The former. And if it times out, enforce default-src 'none'.
> >
> > Correct.  policy-uri needs to block processing of the page until the
> > policy can be fetched anyway.
> >
> > Adam
> >
> >
> >> Eric Rescorla wrote, On 08/12/2011 21.32:
> >>> Is this deterministic? Consider the case where a document has two
> >>> policies:
> >>>
> >>> 1. In the header, a policy which specifies a policy-uri which takes
> >>> 10 seconds to load. 2. In the body, a meta tag with a complete
> >>> policy
> >>>
> >>> Which one of these did the agent "encounter first"?
> >>>
> >>> -Ekr
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Dec 8, 2011 at 12:10 PM, Giorgio Maone
> >>> <g.maone@informaction.com>
> >>> wrote:
> >>>> +1 for A, first seen wins.
> >>>>
> >>>> -- G
> >>>>
> >>>> Adam Barth wrote, On 08/12/2011 20.35:
> >>>>> One of our open issues is about how to deal with multiple CSP
> >>>>> policies for a given resource.  At TPAC, one resolution we
> >>>>> discussed was the following:
> >>>>>
> >>>>> 1) If a resource has multiple HTTP headers containing CSP
> >>>>> policies, enforce all of the policies.  Because CSP policies only
> >>>>> reduce privileges (never grant privileges), that effectively means
> >>>>> that an action is allowed only if it is allowed by all the CSP policies.
> >>>>>
> >>>>> 2) If a resource has a CSP policy from an HTTP header, then we
> >>>>> ignore any CSP policies that might be contained in <meta> elements.
> >>>>> Otherwise, the user agent enforces all the CSP policies found in
> >>>>> <meta> elements.
> >>>>>
> >>>>> Another resolution (which I advocate) is the following:
> >>>>>
> >>>>> A) The first CSP policy the user agent encounters for a document
> >>>>> wins.
> >>>>>
> >>>>> IMHO, approach (A) is better than approach (1+2) for two reasons.
> >>>>> First, it's simpler.  CSP is already more complex that it should be.
> >>>>> Adding more complexity is costly, both now in terms of
> >>>>> implementation and in the future in terms of constraints.
> >>>>>
> >>>>> Second, approach (1+2) constrains future evolution of CSP.  For
> >>>>> example, suppose we wanted to include
> >>>>> http://wiki.whatwg.org/wiki/Meta_referrer as a CSP directive.  How
> >>>>> would we define the combination of policies containing referrer
> >>>>> directives?  We'd have to define some ordering like "never <
> >>>>> origin < always", but where does default fit in?
> >>>>>
> >>>>> These are, in some sense, the same concern.  We can implement
> >>>>> combination today, but it imposes constrains on the future that we
> >>>>> might wish we didn't have later.
> >>>>>
> >>>>> Adam
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >

Received on Friday, 9 December 2011 19:03:51 UTC