Holiday changes to the CSP 1.1 editor's draft.

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