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

[Antonio Sartori]

Contact emails

antonio...@chromium.org

Explainer

https://github.com/w3c/webappsec-csp/issues/394

Specification

None

Summary

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 https://github.com/w3c/webappsec-csp/issues/394, 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

Blink>SecurityFeature>ContentSecurityPolicy

TAG review

None

TAG review status

Not applicable

Risks

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

None

Gecko: This was never implemented in gecko, and gecko seems favorable to remove it from the specification (https://github.com/w3c/webappsec-csp/issues/394)

Edge: No signal

WebKit: No signal yet, but I opened a bug https://bugs.webkit.org/show_bug.cgi?id=220724

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

https://bugs.chromium.org/p/chromium/issues/detail?id=1168001

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5742693948850176

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF4nxPt8-50fonALCNXw9Ez0qbvv7BAVCvX%3D7ezgiP9S8w%40mail.gmail.com.

[Antonio Sartori]

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]

A meta-question: did you generate this intent email via chromestatus.com? It wasn't picked up by the tooling for https://bit.ly/blinkintents, 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.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF582BqLCaEXZccB2pH5F30Y0R2Mk%2B%2Bb6XHoBThUp4BogA%40mail.gmail.com.

[Yoav Weiss]

LGTM2

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

[Antonio Sartori]

Yes I did generate this email via chromestatus.com.

[Alex Russell]

LGTM3 to remove directly.

[Chris Harrelson]

LGTM3 to remove directly based on the compat data presented.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF6hpxoJYy6-b5RPVfaM_Autr7ULZ-Vxf50Gs9KyedPL0g%40mail.gmail.com.