Re: Trimming the SecurityPolicy DOM interface

On Sat, May 25, 2013 at 11:04 PM, Hill, Brad <bhill@paypal-inc.com> wrote:

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

Hey Brad,

I do! CSP is incredible. I can't wait for it to be ubiquitous.


>
>
> 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.
>

That's entirely OK. I'm not suggesting implementing CSP in the DOM of the
document that is being controlled.  Instead what I'm suggesting is that you
should be designing the API *as though* it were being used to implement the
feature. That's a completeness and accuracy check on the API. Reasoning
about what to expose from a straight de-sugaring can
happen orthogonally. It's not clear to me that there are any real issues
here, however: the declarative API would only be subverted if the rules the
system was enforcing were mutable from the page. I don't imagine anyone
here is proposing such an API (except perhaps for the *addition* of new
restrictions at runtime).


>  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.
>

I don't think that's the right frame for any API design. You'd be better
off not exposing anything than doing a secenario-solving exercise in which
you're pulled by the winds of who can yell at you loudest in this version
or the next.


> 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 L) 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.
>

I have spent time in the trenches as a security professional in a past
life. You don't have to apologize to me for being conservative; only for
fielding bad API ;-)


>   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>
> 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> 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
> >>
> >****
>