Re: ISSUE-4: Policy combination

Fixed.

Adam


On Fri, Dec 9, 2011 at 5:54 PM, Brandon Sterne <bsterne@mozilla.com> wrote:
> It appears I failed to clearly specify the intended behavior in the document, but the feature Brad describes (simultaneous report-only and blocking modes) was certainly intended in the original design of CSP. �This feature enables a great method for sites to iterate toward an "optimal" policy: serve a permissive policy in blocking mode and a more restrictive policy in report-only mode, and then once confidence is obtained in the correctness of the more restrictive policy, it can be uplifted into the blocking mode. �Indeed, I made several public statements to this effect at OWASP events this year (Irvine and DC).
>
> When I agreed with Adam's proposal for "first policy wins", my assumption was that the above was still true. �I assumed that the first report-only policy would win and, independently, the first blocking policy would win, but that these policies would be carried out separately by the UA. Does this seem to be a reasonable approach?
>
> Cheers,
> Brandon
>
>
> ----- Original Message -----
> From: "Brad Hill" <bhill@paypal-inc.com>
> To: "Adam Barth" <w3c@adambarth.com>
> Cc: "Brandon Sterne" <bsterne@mozilla.com>, public-webappsec@w3.org, "Giorgio Maone" <g.maone@informaction.com>
> Sent: Friday, December 9, 2011 12:58:08 PM
> Subject: RE: ISSUE-4: Policy combination
>
> Aha, I think I misread the diff. �The new language only says that you MUST NOT have both, and is not really clear what behavior is if you do.
>
> Allow me to take off my hat as chair here for a moment, to represent a contrary opinion as a site operator on two topics here. �(voices thus far on this topic have been mostly browser implementers)
>
> RE: Presence of both Content-Security-Policy and Content-Security-Policy-Report-Only
>
> From an developer/operational perspective, it seems like it's a nice feature to be able to have both an enforced and a monitored policy simultaneously, to allow incremental refinement. �You can set for enforcement the policies you know are compatible, and monitor experimental additions that further reduce privileges.
>
> Deployment of CSP for legacy sites will be hard enough without making it an essentially one-shot process, or forcing site to turn off their known-good policies while they experiment with stricter versions.
>
> RE: Policy combinations vs. first-wins
>
> Consider the case where a site owner has a set of CSP policies that it wants to guarantee are enforced for all resources, but also has individual resource owners who want to opt-in to tighter restrictions. � Coordinating this type of thing, e.g. between a corporate infosec group and individual app development teams, is difficult in the real world, especially for large sites.
>
> �We can solve this in one of two places:
>
> �1. �The user agent can combine the policies, incrementally dropping privileges as tokens are encountered.
> �2. �The site operator can combine the policies, e.g. by observing policies at a network-edge device and re-writing a unified policy.
>
> With regard to the specific concern of Adam's regarding policies (e.g. Meta-Referrer) that don't have a clear ordering or union algorithm, I think the above implies that we still need a define a standard algorithm for policy combination, even if we punt that complexity to site operators instead of browser vendors.
>
> The question then comes down to who should be responsible for implementing the combination algorithm. �Doing it in the browser implies fewer implementations by people who arguably know better what they are doing, and introduces less total complexity into the ecosystem. �Doing it server-application-side introduces an entirely new component, and one that is reasonably complex if it has to look for meta http-equiv, whereas the browser is mostly doing this work already.
>
> -Brad
>

Received on Saturday, 10 December 2011 04:47:08 UTC