Re: Holiday changes to the CSP 1.1 editor's draft.

#4 and #5 appear to not be backwards compatible with CSP 1.0 (ie things
will be blocked that were allowed before these changed).

i know 1.1 things are behind a flag in Chrome and behind a pref in Firefox
but that's controlled by the user/developer
and not the site/policy author. I suppose a site can serve two versions of
the header and the browsers should
ignore the deprecated or unknown directives but that's sort of going
backwards to the prefixed and unprefixed header days.

there's no versioning in the CSP header so i'm curious about the strategy
for releasing breaking changes like these...
i suppose that may be left up to the browser implementors but i'm concerned
that they will never be able to switch on CSP 1.1
if it will break sites using CSP 1.0. looking at the prior example of the
unprefixed and prefixedd headers, i suppose that the X- header is
deprecated in Chrome already and there are plans to do the same in Firefox
but that's a 'fail open'  case for sites that are not also serving the
unprefixed header (which is also bad.. ).

thoughts very welcome.

cheers,
ian




On Fri, Jan 3, 2014 at 1:56 AM, Mike West <mkwst@google.com> wrote:

> I've made a few changes to the CSP 1.1 editor's draft over the holidays,
> and I'd like to get some feedback on some of the potentially controversial
> bits:
>
> 1. I've [removed the majority of the script interface][1]. I agree with
> the criticism of the currently specified API that folks like Alex
> Russell[2] and Yehuda Katz[3] have expressed, and I'd like to simply punt
> the work on an API compatible with the TAG's recommendations out to CSP
> 1.2. I have not, however, removed the `SecurityPolicyViolationEvent` fired
> upon violation. That seemed uncontroversial, clearly useful, and
> (selfishly) will make writing tests about 1000% easier.
>
> [1]:
> https://github.com/w3c/webappsec/commit/18882953ce2d8afca25f685557fef0e0471b2c9a
> [2]: http://infrequently.org/2013/05/use-case-zero/
> [3]:
> http://yehudakatz.com/2013/05/24/an-extensible-approach-to-browser-security-policy/
>
> 2. I've cleaned up the definition of policy delivery via a `meta`
> element[4]. The changes seem to be straightforward ports of the TODO text
> into spec text, with the addition of specifying that `sandbox` ought to be
> ignored, as Dan suggested in [5].
>
> [4]:
> https://github.com/w3c/webappsec/commit/3647b8fc86cdcb777b398f4587d55adbb1c02887
> [5]:
> http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0057.html
>
> 3. Workers no longer inherit policy from their owner document
> automatically[6], but only when generated from URLs with unique origins, as
> noted in [7].
>
> [6]:
> https://github.com/w3c/webappsec/commit/63534a54245df586bf02d44ceab07e6611450d15
> [7]:
> http://lists.w3.org/Archives/Public/public-webappsec/2013Dec/0007.html
>
> 4. New directives to govern workers and child browsing contexts: Workers
> are no longer governed by `script-src`, but by a new `worker-src`
> directive[8]. The `worker-src` directive defaults to a new 'default context
> sources' list, defined by a new `child-src` directive. `frame-src` also now
> inherits from that new directive. Finally, auxiliary browsing contexts
> (such as those created via `window.open`) are governed by a new `popup-src`
> directive (which also defaults to `child-src`). This is a bit distinct from
> Brad's proposal in [7], and I expect some discussion about the route I've
> taken.
>
> [8]:
> https://github.com/w3c/webappsec/commit/92a738a06d02fa1e24222394c2d361d9ec355406
>
> 5. Certain CSSOM operations are now blocked unless `'unsafe-eval'` is
> present in the `style-src` directive[9], as suggested in [10]. I've picked
> out the bits that appear to be dangerous, but left in bits that could
> theoretically cause more limited damage, along the lines of the suggestion
> in comment #0 of [11]. Comment #1 on that same bug expresses reservations
> with this approach; I generally agree with the response in comment #2, but
> welcome opinions.
>
> [9]:
> https://github.com/w3c/webappsec/commit/34103c6dd661c267c07bd99b04da653538781230
> [10]:
> http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0097.html
> [11]: https://bugzilla.mozilla.org/show_bug.cgi?id=873302
>
> With all of these in mind, I'd like to publish a new working draft based
> on this document.
>
> Once we have consensus on the above changes, there's one issue left that I
> know we need to address before moving to last call: blob/filesystem/etc.
> URLs. I'll make a proposal for those early next week, and bring it to the
> list for discussion. Are there any other issues that I've forgotten about
> which need to be addressed before last call makes sense?
>
> Thanks for your feedback!
>
> -mike
>
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>