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 Friday, 9 December 2011 20:58:58 UTC