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

+abarth, who likely has opinions.

I would very much prefer to avoid versioning to whatever extent possible.
Versioning brings both implementation complexity (as we'd have to implement
both behaviors) and author complexity (as both behavior would have to be
understood, and an author would have to choose one (or do UA sniffing or
something equally miserable)).

I think the risk of breakage is low, given the low penetration of CSP in
general, and the relatively edge-case nature of these changes. That said,
it's certainly something we could try to measure to give the WG some data.

For the record, Chrome has removed support entirely for the old prefixed
header in trunk, and that change should be rolling out to stable Very Soon™.

-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.)


On Wed, Jan 8, 2014 at 5:27 AM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> 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.)
> >
> >
>