Remove worker references from child-src section

[dveditz]

Section 6.1.1 child-src says

The child-src directive governs the creation of nested browsing contexts (e.g. iframe and frame navigations) and Worker execution contexts

Elsewhere (e.g. "Changes from Level 2", the script-src and default-src algorithms) a missing worker-src is defined to fall-back to script-src and then default-src, with no child-src.

[NB: the CSP3 re-definition of worker-src will break some existing users of CSP, both those who already assumed workers were scripts but have a bug as well as those who were doing the right thing with child-src and intentionally covering workers that way. Hopefully not too many sites]

[ckerschb]

After chatting with Mike it seems that Chrome has the following fallback in place:

• worker-src
• child-src
• script-src
• default-src

I think that is also the way that Firefox would like to implement it. Can we get the spec updated to reflect that behavior?

[mikewest]

Chrome's current behavior is a little more complicated than that:

1. For frames, we support frame-src, falling back to child-src, and default-src.

2. For workers, I'll copy-paste the comment from CSPDirectiveList::AllowWorkerFromSource.

   // In CSP2, workers are controlled via 'child-src'. CSP3 moves them to
   // 'script-src'. In order to avoid breaking sites that allowed workers via
   // 'child-src' that would have been blocked via 'script-src', we'll
   // temporarily check whether a worker blocked via 'script-src' would have been
   // allowed under 'child-src'. If the new 'worker-src' directive is present,
   // however, we'll assume that the developer knows what they're asking for, and
   // skip the extra fallback.
   //
   // That is, we'll block 'https://example.com/worker' given the policy
   // "worker-src 'none'", "worker-src 'none'; child-src https://example.com",
   // but we'll allow it given the policy
   // "script-src https://not-example.com; child-src https://example.com"
   // (because 'child-src' allows it) or "child-src https://not-example.com"
   // (because the absent 'script-src' allows it).
   //
   // TODO(mkwst): Remove this once other vendors follow suit.
   // https://crbug.com/662930

This combination is not pretty, and I'd be a little unhappy if we codified it. I was hoping other vendors would implement worker-src so we could drive down usage of child-src and remove it from the platform, but it doesn't look like that's happening quickly enough (removing Chrome's weird fallbacks would break a worker load on 0.006% of page views, which is not huge, but not nothing).

If you twisted my arm, I guess I could live with what it sounds like y'all are doing: putting child-src in the middle of both frame and worker loads, falling back to the one in the one case, and the other in the other. That's going to be a bit of a pain in the ass to deal with in the spec, as there's not really a concept of multiple fallback paths at the moment, but I'm sure @andypaicu can work that out if that's what folks other than me want to do.

[mikewest]

Ping @dveditz @ckerschb on the above?

[ckerschb]

I would be happy to remove the extra fallback but it seems the 'multiple' fallback option is the best we have at the moment. To summarize:

1. For frames we are definitely on the same page. If frame-src is present, then frame-src is used, falling back to child-src and ultimately default-src.

2. For workers, we first check if worker-src is present, if not, we check if child-src is present, if not, we check if script-src is present, if not, then ultimately default-src governs workers.

It would be easy to eliminate the child-src in between in Firefox' implementation, but given your breakage study I would rather go down that route of having multiple fallbacks.

[mikewest]

Ok, so you're planning on shipping frame-src -> child-src -> default-src on the one hand, and worker-src -> child-src -> script-src -> default-src on the other?

@andypaicu: Are you on board with speccing and implementing that in Chrome?

[andypaicu]

Yeah I'll take care of it