- From: Eric Rescorla <ekr@rtfm.com>
- Date: Thu, 8 Dec 2011 12:32:24 -0800
- To: Giorgio Maone <g.maone@informaction.com>
- Cc: public-webappsec@w3.org
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 Thursday, 8 December 2011 20:33:33 UTC