- From: Ian Melven <ian.melven@gmail.com>
- Date: Tue, 7 Jan 2014 11:37:15 -0800
- To: Mike West <mkwst@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CA+0m=Fdc=3Ho30h1TDmnzRnAEnOBHR+_6=JQ70sKtByxbEsH4w@mail.gmail.com>
#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.) >
Received on Tuesday, 7 January 2014 19:37:43 UTC