- From: Brandon Sterne <bsterne@mozilla.com>
- Date: Thu, 10 Mar 2011 08:59:47 -0800
- To: Anne van Kesteren <annevk@opera.com>
- CC: Adam Barth <w3c@adambarth.com>, Collin Jackson <collin.jackson@sv.cmu.edu>, "public-web-security@w3.org" <public-web-security@w3.org>
On 03/10/2011 04:44 AM, Anne van Kesteren wrote: > On Tue, 08 Mar 2011 20:11:35 +0100, Adam Barth <w3c@adambarth.com> wrote: >> We're going to be more successful getting folks to use CSP for new >> kinds of policies in the future if CSP has less intrinsic baggage. >> For example, Anne's From-Origin HTTP header should be a CSP directive >> not yet-another-HTTP-header, but he's not going to like any coupling >> between From-Origin and how inline event handlers behave. > > Yeah that would be weird. I'm still a bit unsure as to whether putting > all these policies in the same header makes sense. They are orthogonal > issues. It feels very similar to the <object> disaster. Some kind of > framework element that can handle a ton of things, but is not very good > at any of them. One could make an argument that things like From-Origin and frame-ancestors, which restrict embedding contexts, deserve to be split out from Content Security Policy, which could then be strictly about content loading and other behavior within our own top-level document. That would permit us to keep the default policy stronger and would arguably lead to a more secure average configuration for CSP. (What does an empty policy mean, anyway?) For me, it basically boils down to the question: how far do we want to expand the scope of CSP? All of the recent specification drafts have *content injection* as the threat model. If we add from-origin or similar directives, we're already expanding the scope. I'm still on the fence myself. The orthogonality of directives in Adam and Collin's proposal is a very nice property to have. The more-secure-by-default argument continues to resonate with me, though. -Brandon
Received on Thursday, 10 March 2011 16:58:34 UTC