Re: JavaScript URLs and script-src nit

Also: not having a default policy means that it's more intuitive to combine
two CSP policies, if doing so becomes necessary in the future. Combining a
CSP policy with an empty policy shouldn't make it more or less restrictive.

On Fri, Feb 18, 2011 at 10:55 PM, Collin Jackson
<collin.jackson@sv.cmu.edu>wrote:

> On Feb 18, 2011 9:35 PM, "Daniel Veditz" <dveditz@mozilla.com> wrote:
> > On 2/18/11 9:19 PM, Collin Jackson wrote:
> >> It's confusing to have some
> >> security features that are on by default and others that you have to
> >> turn on manually. The empty policy should have no effect.
> >
> > How is it much different than specifying different DOCTYPES in an
> > HTML document and triggering different quirks/standards modes in
> > browsers?
>
> I don't consider the use of DOCTYPEs to trigger different quirks/standards
> modes to be a model we should aspire to for CSP; it does not scale well with
> multiple vendors to have a default policy. If there is a default policy,
> there will be a strong temptation for vendors to add new things to it over
> time and subtle vendor differences in default behavior create huge pain for
> web developers; this is how "reset stylesheets" came to be used in the CSS
> context. I think CSP should be versioned in the same way new features are
> introduced into HTML: the default document is empty, user agents ignore tags
> they don't understand, and if a vendor does implement a standard tag they
> should implement it in a standard way. Of course, vendors will want to
> support a baseline set of functionality and script-src will definitely be
> part of every vendor's implementation.
>
> > Why would anyone want to send a header that had no effect?
>
> There's no reason to send an empty policy, but that's not a reason to have
> a default policy. The point is, it should be possible to send a
> frame-ancestors directive without implicitly also changing how javascript
> URLs work.
>
> Collin Jackson
>