Consider removing plugin-types

[annevk]

It's only implemented in Chrome and has the same vulnerability as typemustmatch, namely that it can be used for a cross-origin MIME type search. (There's also a number of processing model issues around the handling of MIME types, but they don't matter so much if it's removed.)

[briansmith]

Basically <object> and <embed> themselves need to be deprecated and everybody needs to use object-src 'none'. This is already mostly the case because other browsers don't implement plugin-types. Steering people away from using <object> and <embed> in HTML is whatwg/html#4592.

It's not reasonable to have cases where one must use <object> but then have no way to limit which types of objects are allowed through CSP, because plugins are so dangerous.

This seems like a CSP-EE type control, so maybe moving this to CSP-EE, which has a negotiation mechanism, might make sense.

[Sora2455]

The only reason I use plugin-types is because Chrome, Edge, and Safari all fire CSP violation events if you set object-src: 'none' and then directly link to a PDF file (I can't remember if you need to set target="_blank" or not). Their built-in PDF viewers use <object> tags, and for some bizzare reason the previous page's CSP still applies to it, violating the object-src directive.

(Firefox's PDF viewer is built in JavaScript using the <canvas> tag, so it isn't a problem).

To avoid the violations, I have to set object-src 'self' on any page that can link to a PDF (which is a lot). To try to patch the giant gaping hole that leaves, I set plugin-types: application/pdf.

If we are going to remove plugin-types, can these bugs be fixed first?

[briansmith]

@Sora2455 That's useful to know. If you have the energy, I would file bug reports with the browsers directly and link to them from here.

[Sora2455]

I tried to produce a reduced test case, only I couldn't reproduce my error. I combed through my CSP logs more carefully, and now I actually think it's just Safari that has the bug (the Edge and Chrome violations appear to be because of Ext.net usage).

So now I have a reduced test case, but not access to a Safari browser to test it in. Bummer.

This page claims that setting rel="noreferrer" fixes the issue, so I'll try that and let you know if I stop getting Safari CSP violations.

[lbherrera]

I think @sirdarckcat and @terjanq looked into plugin-types for cross-origin MIME type search and the conclusion was that it was not possible to use it to do so. I did some tests and CSP appears to block the load of the resource only if the type attribute doesn't match the directive. It doesn't seem to take into consideration the actual mime type of the cross-origin resource (testcase).

[annevk]

Okay, so that means that the one implementation of this feature is also non-compliant. That even more strongly suggests it ought to be removed.

[mikewest]

1. It surprises me that no other browser shipped plugin-types. I'm pretty sure I implemented it in WebKit, for example. Weird.

2. Chrome's behavior is a little more complicated than @lbherrera suggests, but @annevk is correct that it doesn't match the spec. Basically, we check the type attribute against the CSP declaration, and then rely on the plugin infrastructure to do the enforcement (similar conceptually to the way the SRI integration works). If you replace application/json in your example with application/pdf or application/x-shockwave-flash, you should see blocking behavior (you won't see it on jsbin because of sandbox, but you will see it if you self-host the file somewhere).

The spec should certainly line up with what vendors are doing, and I'm willing to be convinced that there's no value to the header at all, but I'm loath to just remove it, as there are absolutely sites out there that lock themselves down to only the PDF plugin because of Chrome's implementation details.

At a glance, 10,190 response's headers in HTTP Archive contain both the strings plugin-types and application/pdf. I haven't dug into that number at all to see if any are actually valid policies, but it's not clear to me that there's no value here in the form Chrome's shipping.

[Sora2455]

I haven't encountered my error again after implementing rel="norefferer", though I did find a tweet from a Google Engineer who encountered my bug in Chrome: https://twitter.com/PhilippeDeRyck/status/811448160975552512

[annevk]

@mikewest is there still value now that PDF is the sole "plugin"? But also, unless other implementers adopt this I don't think it has passed the test of belonging in a standard.

[mikewest]

On the "other implementers" point, it does something in WebKit (see HTMLPluginImageElement::canLoadPluginContent for instance). It doesn't look to do the same things it does in Chrome, of course, which is a good argument in favor of changing the status quo.

Given that plugins are dead (huzzah!), I agree that it makes sense to remove the directive both from the spec and from implementations (though possibly keeping some special devtools behavior for the plugin-types directive so we let developers know what's going on). I think I can volunteer @antosart to do that in Chromium. He might be interested in doing the spec work as well? Removing plugin-types would let us get rid of a few pieces of infrastructure that only it depends upon (media-type-list, as well as the plugin hook in HTML).

It's also worth thinking about object-src, which I think we need to keep around as long as we keep <object> and <embed>, but which we'd probably want to start thinking of as a narrower form of frame-src as we shift those elements towards frame's behavior?

[annevk]

Yeah, that would be good.

[sideshowbarker]

@antosart Now that e9895ed is merged, can we close this issue?

[antosart]

Yes, I forgot to close this.

[sideshowbarker]

Yes, I forgot to close this.

Cheers - thanks