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

Hi,

I know versioning was explicitly rejected while the CSP 1.0 spec was being
developed - i'm not arguing that it should be reconsidered but wanted to
raise the issue that breakage is a real problem with these changes.

Re: penetration - according to Isaac Dawson's latest scan of the Alexa Top
1 million websites "Only 269 sites are using the w3 specification’s
Content-Security-Policy header, with 95 of these URLs coming from
Facebook." However, there's obviously a long tail of smaller websites
(which likely find it much easier to adopt CSP) which may be using the
unprefixed header so this data isn't the whole picture.

As far as this breakage being limited to edge cases, I suppose that these
cases could be considered that way. As I understand it, #4 requires a site
using the unprefixed header to be using JS workers. #5 requires a site
already specifying unsafe-inline for script-src to be setting certain style
attributes from script. As always, data is helpful but it won't cover all
cases. One example here is the recent change to Blink to check all
ancestors for XFO (which IE has already done) which ended up being backed
out because it broke a Google site - it was considered unlikely that change
would lead to breakage as well and I had that very discussion in the
corresponding Firefox bug ;)
I guess there's always good old evangelism and warnings in the developer
console (for what those are actually worth in terms of impact) as another
approach for implementors, but given how much the X- headers are still
being used, I'm pretty skeptical...  It's also particularly difficult from
the CSP evangelism side to try to convince sites to adopt CSP if the
perception becomes "CSP might break my site with new versions".

The prefixed header being deprecated is a very different case - it won't
break sites that don't also send the unprefixed header, they will load as
usual, just with no protection from CSP, which won't be user visible
(unless they get XSS'd :P ). The changes in the 1.1 spec will actually
cause parts of sites to potentially not load or take effect and the users
(and site developers) will see this and perceive it as breakage.

However, I'm not arguing breakage is never OK - just that it always needs
to be considered and changes that may cause breakage need to be looked at
in terms of the big picture. My personal opinion after talking to others is
that lack of an ability to whitelist inline scripts (no hash-source and
nonce-source yet) and the difficulty of authoring a CSP for a complex site
are the biggest current barriers to widespread CSP adoption. As CSP 1.1
plans to address the former and tooling and strategies (a la Garrett's post
earlier today) are built to handle the latter, I see CSP 1.1 as potentially
helping adoption greatly (well, that's what I hope anyways) and from that
point on, lack of adoption might not be a reasonable justification for
non-backwards compatible changes. So really if I have any takeaway point
here, I guess it's 'let's try to fold all non-backwards compatible changes
into CSP 1.1 (as these are) and at least implicitly accept that it might
not be possible to make those sorts of changes post 1.1'.

thank you for your time and consideration,
ian




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

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