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

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