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

We talked about this on the call this week.

For my part, I agree with what I read as your conclusion: 1.1 is a version
where we have the potential to make backwards-incompatible changes without
significant impact. If we break one of the few large sites using CSP, we'll
learn about it quickly, and can individually help them work out a solution.

I'd suggest the following: I'll implement the CSSOM change behind the flag
in Blink, turn it on locally, and browsing around on Facebook and Github.
If they break, I'll email folks to see if they can easily add 'unsafe-eval'
to their `script-src` directives.

The worker change is, more or less, a no-op, given that workers are
restricted to same-origin resources at the moment anyway.

WDYT?

-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 Mon, Jan 13, 2014 at 11:53 PM, Ian Melven <ian.melven@gmail.com> wrote:

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