W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2014

Re: [CSP] kill or delay child-src?

From: Mike West <mkwst@google.com>
Date: Mon, 1 Sep 2014 16:06:08 +0200
Message-ID: <CAKXHy=fe5Epok1DTA_FO8K0qw3zd9PeZg4iqO6y9A7y4fEdeRg@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
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.

Received on Monday, 1 September 2014 14:06:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:40 UTC