Re: why does plugin-types inherit to nested browsing contexts?

That's just poor phrasing on my part. The intent of that section was to
control the case where a plugin is embedded via an <iframe> element. That
is, the plugin document is created _directly in_ a _directly nested_
browsing context.

That is, the intent is to allow authors to say "Please don't allow me to
directly embed anything other than PDF, please.". The intent is not to
reach down into embedded documents.

I've attempted to fix the text in
https://github.com/w3c/webappsec/commit/7a31bfef36eb6b7047e61388bc17379abd2f10c9.
WDYT?

-mike



--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Thu, Feb 26, 2015 at 1:48 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> hmm .. isn't the embedding of a SWF inside an SWF is outside the
> browser's reasoning / security any how, right? The browsing context
> hierarchy here is the iframe one, I thought. What the current
> inheritance rules mean is that my csp policy affects all pages I
> iframe. That is a bit weird. So, I might disallow flash on my site by
> setting plugin-types; but I can't iframe youtube now, which seems an
> unnecessary restriction.
>
> cheers
> Dev
>
> On 25 February 2015 at 16:29, Emily Stark <estark@google.com> wrote:
> > Thanks Brad. I think there may be still some distinction between
> object-src
> > and plugin-types that I'm missing: shouldn't object-src also be
> inherited?
> > If foo.com has a policy of object-src allowed.com 'self', and foo.com
> embeds
> > a SWF from allowed.com which embeds a SWF from disallowed.com, isn't
> that
> > also a trivial bypass?
> >
> > On Wed, Feb 25, 2015 at 2:39 PM, Brad Hill <hillbrad@gmail.com> wrote:
> >>
> >> I'm going to guess this is due to some peculiarities in how Flash and
> PDF
> >> allow embedding.  In this situation for CSP the plugin document is
> treated
> >> like a script.  So e.g. a script can be loaded from "allowed.com" but
> can't
> >> then inject another script element from "disallowed.com" if that's not
> in
> >> policy.  Similarly, a SWF from "allowed.com" shouldn't be allowed to
> then
> >> embed another SWF from "disallowed.com", or this would be a trivial
> bypass.
> >>
> >> On Wed Feb 25 2015 at 2:23:17 PM Emily Stark <estark@google.com> wrote:
> >>>
> >>> While investigating a few CSP bugs in Chrome, I noticed this text in
> the
> >>> CSP 1.1 spec for plugin-types:
> >>>
> >>> "Whenever the user agent creates a plugin document in a browsing
> context
> >>> nested in the protected resource, if the user agent is enforcing any
> >>> plugin-typesdirectives for the protected resource, the user agent must
> >>> enforce those plugin-types directives on the plugin document as well."
> >>> (http://www.w3.org/TR/2014/WD-CSP11-20140211/#plugin-types)
> >>>
> >>> Dev (cc'ed) and I found this behavior a little odd and were wondering
> why
> >>> plugin-types is inherited. Is the goal to give a developer a way to say
> >>> "don't allow Flash to appear anywhere in the content area of my page?"
> Why
> >>> is this directive inherited but not any others?
> >>>
> >>> Thanks,
> >>> Emily
> >
> >
>
>