Re: [webappsec] more on the right directive for workers

On 12/3/2013 10:11 PM, Brad Hill wrote:
> So, I think that it makes the most sense to create a new directive for
> Workers.

I agree.

> 1) Create "worker-src" and have it govern only workers, shared workers,
> service workers, etc.

What about importScripts() inside a worker? That should be controlled by
the Worker's CSP script-src (if any) I should think.

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

Will 1b) actually help anything? Unless it's a permanent alias (in which
case why are we bothering?) then at some point we're dealing with the
broken compatibility of 1a anyway. We should investigate how much
breakage there actually will be, but unless it's a lot I lean toward
taking the pain sooner. It will only affect more sites over time.

> 2) Create "child-src" and have it govern all child execution contexts:
> workers, frames, pop-ups

I wish we had started out this way, but now that frame-src is entrenched
this may be too wrenching a change. We would definitely need to continue
supporting frame-src in one of your two variations, and if that's the
case then we haven't gained much as we might as well keep frames and
workers in separate directives.

Also, at the moment workers are restricted to same-origin only. While
that may change in the future, in the present it seems somewhat odd to
have "child-src 'self' blog.mysite.com;". Would authors expect that to
make non-same-origin blog.mysite.com magically allowed in Workers now?

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

Given those two choices I prefer 2b). Keep it for compatibility, but
done expand its functionality. Although 2a would be less work to implement.

-Dan Veditz