[webappsec] more on the right directive for workers

<hat = individual>

To follow up from some discussion on today's call for the larger audience
on the list:

We are still debating what directive should control from where Workers can
be created.

(We have consensus that the execution context of the Workers themselves
should be governed by whatever CSP policy is delivered with them, or
inherit the parent browsing context's policy if created from data:, blob:,
filesystem: or similar schemes.)

Currently workers are governed by the script-src directive on the logic
that they are "like scripts".

But I think that Workers are not really "like scripts" in their security
impact because they have their own distinct execution context.  Workers are
always given the same effective origin as their creating page, regardless
of the origin of their contents, (like <script src=foo.js>) but otherwise
have similar security properties to a child browing context. That a worker
can access the application cache, ndexDB and cookies, make XHR requests to
the server, etc. is nothing that a same-origin child browsing context can't
also do.

I think the notion is made clearer if we think about a future in which
Workers could be non-same origin.  (for example, if we wanted to allow
something like an OAuth token service to be implemented through postMessage
ports, but in a lightweight way that didn't require an associated DOM and
full browsing context)  It seems clear that in such a case we wouldn't
allow a Non-Same-Origin Worker privileged access to anything in the
creating browsing context - that the access rights Workers currently have
to shared state with their parent context is a logical extension of the
Same-Origin Policy, and not a special case.

And this same thought experiment also makes clear, I think, that if we did
have a future with Non-Same-Origin Workers, governing them with
"script-src" would be wrong.  It would be nice to future-proof CSP here
against this likely evolution.

So, I think that it makes the most sense to create a new directive for
Workers.  A couple options exist here:

1) Create "worker-src" and have it govern only workers, shared workers,
service workers, etc.
  1a) Break compatibility for the small number of resources currently using
"script-src" to govern workers and hope policy authors upgrade
  1b) As workers are always less powerful than scripts, have an
(immediately deprecated) fail-back that anything in "script-src" is
inherently also allowed as a "worker-src" (but not the other way around)

2) Create "child-src" and have it govern all child execution contexts:
workers, frames, pop-ups
  2a) Have "frame-src" continue as a deprecated synonym for "child-src"
  2b) Have "frame-src" as a more restrictive sub-directive of "child-src"
if present.

 (compatibility options for 2 are same as 1, but would be special-cased for
Workers only, not other child contexts)

Interested to hear others's thoughts on other and better options, or which
of these they prefer.

-Brad