Re: JavaScript URLs and script-src nit

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