Request for Deprecation Trial: Remove Content Security Policy directive 'plugin-types'

Skip to first unread message

Antonio Sartori

Jan 19, 2021, 12:46:51 PM1/19/21

Contact emails





Motivation: The directive 'plugin-types' allows developers to restrict which types of plugin can be loaded via <embed> or <object> html elements. The main point was to allow developers to block Flash in their pages. But Flash support has been discontinued. As noticed in, the 'plugin-types' directive also suffers from some security issues. So there is not much point in having this anymore, and it seems a good occasion to remove it.

Blink component


TAG review


TAG review status

Not applicable


This was a security feature restricting which plugins a page could load. Removing this cannot possibly break any page. We would continue supporting Content Security Policies including the 'plugin-types' directive, but ignore the directive and report a console warning that the directive is not supported anymore.

Interoperability and Compatibility


Gecko: This was never implemented in gecko, and gecko seems favorable to remove it from the specification (

Edge: No signal

WebKit: No signal yet, but I opened a bug

Web developers: No signals

Is this feature fully tested by web-platform-tests?

It is at the moment, we would remove the tests.

Tracking bug

Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.

Yoav Weiss

Jan 19, 2021, 1:19:02 PM1/19/21
to Antonio Sartori, blink-dev
What does current usage look like? Can we attempt to remove it without a deprecation trial?

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Antonio Sartori

Jan 21, 2021, 2:35:26 AM1/21/21
to Yoav Weiss, Antonio Sartori, blink-dev
I would hope that we can avoid a deprecation trial.

From a very quick analysis: out of 26,874,208 page loads in the 2020-12-01 HTTP Archive run, 2093 (0,008%) contain both the keywords "plugin-types" and "content-security-policy".
Note that the real numbers of impact are actually even lower, since many of those 2093 results either allow application/pdf as plugin-type (which is the same as not specifying plugin-types), or contain the plugin-types in report-only mode, or contain an invalid plugin-types directive.

And, as noticed below, removing the plugin-types directive would not break those pages: it would just not forbid them to load pdfs.

Mike West

Jan 21, 2021, 8:50:12 AM1/21/21
to Antonio Sartori, Yoav Weiss, blink-dev
A meta-question: did you generate this intent email via It wasn't picked up by the tooling for, which means there's a mismatch somewhere.

I think this is something that's safe to remove, given our vague understanding of usage in the wild. It is very unlikely to break sites (as the removal gets rid of a restriction, rather than dropping functionality; in the worst case, something will unexpectedly load when it would previously have been blocked), and CSP retains the ability to control `<embed>` and `<object>` tags by URL. Developers who care about the content loading into their sites are likely better served by that kind of control, now that the most dangerous content which could have loaded into those contexts has been removed entirely. Likewise, Firefox never shipped this directive, which means that sites couldn't consistently rely upon it to prevent execution of any specific plugin type. Again, in the worst case, Chromium simply shifts to match Firefox's existing behavior, allowing more content to load than expected.

I also looked at the HTTP Archive data a little more closely. Of the 2,093 pages in the 2020-12-01 run you pointed to:

* 762 set `plugin-types` that contains `application/pdf`.
* 825 set `plugin-types application/json text/javascript`, which has the effect of blocking all plugins (and seems to substantially misunderstand what the mechanism aims to do...)
* 49 set `application/x-shockwave-flash`, which has little effect today.

IMO, the potential effect of this change is small, and the potential breakage is negligable. LGTM1 to remove directly.


Yoav Weiss

Jan 21, 2021, 8:52:57 AM1/21/21
to Mike West, Jason Robbins, Antonio Sartori, blink-dev

+Jason Robbins - for the meta question on RE this intent's title

Antonio Sartori

Jan 21, 2021, 11:26:05 AM1/21/21
to Yoav Weiss, Mike West, Jason Robbins, Antonio Sartori, blink-dev
Yes I did generate this email via

Alex Russell

Jan 21, 2021, 3:14:54 PM1/21/21
to blink-dev, Antonio Sartori,, Jason Robbins, Antonio Sartori, blink-dev,
LGTM3 to remove directly.

Chris Harrelson

Jan 21, 2021, 3:14:54 PM1/21/21
to Antonio Sartori, Yoav Weiss, Mike West, Jason Robbins, Antonio Sartori, blink-dev
LGTM3 to remove directly based on the compat data presented.

Reply all
Reply to author
0 new messages