- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Tue, 7 Jan 2014 20:27:07 -0800
- To: Ian Melven <ian.melven@gmail.com>
- Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
The discussion in http://lists.w3.org/Archives/Public/public-webappsec/2013Dec/0057.html is also at its core due to the absence of versioning. Is there any precedent here? How did other standards deal with the versioning issue? On 7 January 2014 11:37, Ian Melven <ian.melven@gmail.com> wrote: > > #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 Wednesday, 8 January 2014 04:27:55 UTC