Hmm, that's an interesting point. I believe the concern was around potential for confusion when a mix of enforced and report-only policies was defined, so the admin wouldn't forget to flip the switch from reporting to enforcing and end up with a false sense of confidence. There are also some implementation challenges with doing both; we'd need to track two separate set of policies, one enforced and one reporting-only, but active simultaneously. The latter is a solvable problem but we already got a lot of feedback over the perceived complexity of the model. :)
Nevertheless I think your use case for parallel research / testing makes a lot of sense. Lucas. On Mar 12, 2010, at 2:45 PM, Nick Kralevich wrote: > https://wiki.mozilla.org/Security/CSP/Spec#Report-Only_mode > > If both a X-Content-Security-Policy-Report-Only header and a > X-Content-Security-Policy header are present in the same response, a warning > is posted to the user agent's error console and any policy specified in > X-Content-Security-Policy-Report-Only is ignored. The policy specified in > X-Content-Security-Policy headers is enforced. > > > Why is this? This seems like an unnecessary burden which prevents groups > from tightening their security policies over time. > > For example, here at Google, I'm interested in helping resolve some of our > Mixed Content warnings, so I might run the following header on all Google > HTTPS sites: > > X-Content-Security-Policy-Report-Only: allow https://*:443; options > inline_script eval-script; report-uri /someUri > > This will allow me to collect information on all the mixed-content > violations which may occur. > > However, in the future, a different group may decide that they want to > enforce a tighter policy, and may add the header: > > X-Content-Security-Policy: [something else] > > All of a sudden, two reasonable changes by two different people will result > in a user visible error, and will suppress my ability to collect information > about mixed-content errors. > > To me, it seems valuable to support both X-Content-Security-Policy > and X-Content-Security-Policy-Report-Only, as it allows sites to test new > restrictions without disrupting their current restrictions. > > -- Nick > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
