- From: Mike West <mkwst@google.com>
- Date: Mon, 1 Sep 2014 16:06:08 +0200
- To: Daniel Veditz <dveditz@mozilla.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=fe5Epok1DTA_FO8K0qw3zd9PeZg4iqO6y9A7y4fEdeRg@mail.gmail.com>
On Wed, Aug 27, 2014 at 9:49 AM, Daniel Veditz <dveditz@mozilla.com> wrote: > Mozilla is not currently planning to implement section 7.2 child-src and > would prefer that this feature be delayed to a later edition of the CSP > spec or outright killed. Or maybe we just don't understand the > usefulness of the change. Originally this was defined to unify frame-src > and Workers but since then the rules for Workers have changed > considerably (they need to specify their own policy header). Does it > still make sense to deprecate the frame-src that existing policies are > using if the child-src directive ends up covering only frames anyway? > I don't understand the objection. `child-src` covers the workers that the protected resource can load, in the same way that `frame-src` covered the pages that the protected resource can frame. In both cases, a new environment is created. For frames, they've always had their own CSP. For workers, we're newly defining them as having their own CSP. This means to me that the threat models are similar, and should be treated similarly. > If we keep child-src then the spec needs to say what happens during > frame loads if a policy specifies both child-src and frame-src (and they > aren't identical). > As Anne notes, this is covered. I hope it's covered, anyway. It's more or less the same case as a policy that includes two `child-src` directives. -mike
Received on Monday, 1 September 2014 14:06:58 UTC