RE: Trimming the SecurityPolicy DOM interface

Thanks, Alex, for your careful thoughts here, and I venture we're all proud that you think so highly of CSP.

We definitely need to consider this perspective, and I look forward to Adam's new proposal.

However...I think that the situation with CSP does have some unique characteristics that make it different than the typical feature and merit some consideration.   I hope I can express our motivations here as well as you did yours.
First, CSP has a somewhat adversarial relationship with the DOM.  It begins with the assumption that the DOM may not be quite trustworthy.  Version 1.0 lacks any sort of DOM API precisely because it had a design goal of being "out of band" to everything that goes into constructing the content of a dynamic resource.  We are walking that back only with compelling evidence of necessity.

Next, as a security mechanism, we worked from a "first, do no harm" principle.  We didn't want there to be any way for an adversary to use CSP to make a resource less secure.   Reflected XSS filters offer a good lesson in the pitfalls of this type - clever folks found ways to abuse the mechanism to introduce XSS where none existed before, or to, e.g. disable frame-busting code intended to protect against clickjacking.   It turns out "do no harm" is very hard (if you stay tuned into this list, you'll see Peleus drop a nuclear bomb of this sort on my UISecurity work soon :() and I am very proud of our conservatism and success so-far in this task for CSP 1.0.

Finally, we have sought, often against our own instincts, to Keep It Simple.   As security professionals, we are aware that subtle and complex mechanisms are preferred by careful-thinking developers that want to maximize the security of their applications.  Those same careful-thinking developers are typically the loudest voices contributing to the specification process -- but they are also the audience that is least in need of useful security mechanisms.  They will do a good job of producing a secure application anyway.  There may be much more value to add to the ecosystem by producing a mechanism that is simple to understand and deploy, without the "gotchas" that tend to piggyback on the subtlety that the truly elite developers crave.  A dynamic, one-way policy mechanism that works sometimes, doesn't work other times, and introduces another piece of critical state to track across the execution context of a complex application, is tricky in the extreme and likely to be used incorrectly.

I hope this doesn't come off as too defensive, but I hope it does convince you that we're not just overworked here, but do have legitimate and carefully considered motivations behind our choices so far.   Creating something that's generative and finds creative uses beyond those we imagined is surely every author's highest ambition and  greatest satisfaction, so thank you for your contributions in pushing us towards that.  Powerful articulations of the goals of imaginative and ambitious users are the best help we can have to find the careful balance we're seeking.

Cheers,

Brad




From: Alex Russell [mailto:slightlyoff@google.com]
Sent: Friday, May 24, 2013 10:02 AM
To: Adam Barth
Cc: public-webappsec@w3.org; Mike West; www-tag@w3.org List; Anne van Kesteren; Yehuda Katz; Marcos Caceres
Subject: Re: Trimming the SecurityPolicy DOM interface

Apologies for not replying more fully before.

I've spent some time putting my thinking on this in blog-post form:

http://infrequently.org/2013/05/use-case-zero/

On Saturday, April 27, 2013, Adam Barth wrote:
Alex, would you be willing to share the specific use cases you have in
mind?  We just want to make sure there are solid use cases for the
features in the spec.

Adam


On Sat, Apr 27, 2013 at 11:31 AM, Alex Russell <slightlyoff@google.com<mailto:slightlyoff@google.com>> wrote:
> I object to these changes in the strongest possible terms. If it is not
> possible to implement CSP policy enforcement on top of your API, it is not
> sufficient.
>
> On Apr 27, 2013 5:46 PM, "Adam Barth" <w3c@adambarth.com<mailto:w3c@adambarth.com>> wrote:
>>
>> As discussed at the face-to-face meeting, I've trimmed the
>> SecurityPolicy DOM interface to just the first four attributes:
>>
>> https://dvcs.w3.org/hg/content-security-policy/rev/f338192860c5
>>
>> At the meeting, we discussed that these attribute have strong use
>> cases, but we couldn't think of any strong use cases for the remaining
>> DOM interfaces.
>>
>> If folks come up with strong use cases, we should consider adding back
>> the removed interfaces (or adding new interfaces that better address
>> those use cases).
>>
>> Note: At the face-to-face, we discussed making some of these attribute
>> writable in some circumstances, but I haven't made that change yet
>> because it probably deserves more discussion.
>>
>> Adam
>>
>