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

On Thu, Feb 26, 2015 at 11:51 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> hm .. to be honest, the spec still reads like it forces the
> plugin-type directive on the iframe resource (HTML page). Is that
> intentional or am I bad at reading the spec?
>
> Also, what about <iframe src="data:text/html,<iframe src=...>"> Does
> plugin-types inherit to the second iframe inside? What if it was an
> object tag?
>
>
> Separately, I am a bit confused why you are worried about this case.
> Why not apply the same logic to images then: See
> http://htmlpad.org/csp-img-test/
> Developers might think "img-src 'none' made me think I can't show any
> images"
>
> There is a big difference between iframes and direct plugin includes.
> When someone embeds the plugin directly in an iframe, it doesn't get
> stuff like 'allowScriptAccess' etc.


I am not a plugin guy, so I've been naively operating under the assumption
that plugins are plugins, no matter how they're embedded. In that context,
distinguishing between `<object>` and `<iframe>` embeds has never made much
sense to me.

Can you enumerate the difference in privilege between a plugin embedded via
`<object>` and a plugin embedded via `<iframe>`? If there are real and
relevant differences, then it's probably reasonable to revisit both Blink's
implementation and the spec text.

For me personally, non frame-src
> directives applying to iframes makes it very weird and hard to reason
> about CSP.


Well, there are frames and there are frames. I completely agree that
loading a new document in a frame should create a new browsing context, and
"start fresh" for most things. We have explored directives that reach down
into those frames to alter behavior ('upgrade-insecure-resources' and
'sandbox' come to mind), but in general it seems like a sensible boundary.

Loading a resource directly into a frame, on the other hand, doesn't have
the same feel. It seems clear to me that a developer who wants to block
plugins from executing on her site (via `object-src 'none'`) would expect a
plugin embedded directly in a frame to be blocked.


> If we are (understandably)  worried about being able to iframe non
> HTML content, I am all for creating a separate directive for that;
> that disallows this sort of navigations to images, plugins, etc in an
> iframe. But that should be separate and apply to fonts/images, and so
> on, imo.
>

Why would you accept that, but not `object-src` applying to those loads? It
seems inconsistent with the rest of your argument, so I feel like I must be
missing something.

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