Removing plugins? #6003

domenic · 2020-10-01T17:50:09Z

With Flash deprecation, it might be the case that browsers no longer implement plugins, and as such we could remove some of the spec complexity around them.

Note, however, that we do need to keep enough to allow rendering of PDFs, and to allow rendering of HTML pages (and other supported content types) in embed and object. So it's not like we can completely gut the embed and object sections.

And, it looks like at the time of #3958, Chrome treated PDFs as plugins. So maybe we can't remove much.

Anyway, some candidates for removal:

Page load processing model for plugin documents, under the assumption that PDFs count as inline content that doesn't have a DOM (TODO test if that assumption holds; the above indicates it might not in Chrome)
Sandboxing infrastructure for plugins, but see Interop: pdf might or might not render in a sandboxed iframe (depending on a browser) #3958 for PDF-related concerns
Description of plugins
NavigatorPlugins and friends, but see Consider a standardized way to detect PDF in HTML? #3462; PDF support might end up living here in existing browsers.
embed and especially object could likely be simplified to be more like iframe.
The param element might be able to be totally neutered and moved to the obsolete section.

The param simplification likely holds even if PDF ends up staying around as a plugin. (And in turn we can close #387.)

The text was updated successfully, but these errors were encountered:

annevk · 2020-10-05T08:31:12Z

If we can remove https://html.spec.whatwg.org/#concept-embed-type that would be nice. Hopefully browsers do not look for .pdf.

annevk · 2021-01-06T09:50:48Z

The way Chrome and Firefox support PDF is as the result of a navigation, so plugin documents continue to exist, but I'm not sure they would be different from inline content that doesn't have a DOM as the result is basically a document with an opaque origin.

A question that came up in annevk/orb#5 is whether we can make these always create nested browsing contexts. ~~I suspect that won't work due to images, but it might be worth investigating more. (See also w3c/webappsec-fetch-metadata#37 and w3c/webappsec-fetch-metadata#45.)~~ whatwg/fetch#948 suggests this might be possible now plugins are removed, but we may need to keep some quirks. Seems very much worth investigating.

cc @anforowicz @arturjanc @mikewest

annevk · 2021-01-09T08:19:06Z

For navigator.plugins and navigator.mimeTypes I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1164635 and https://bugs.webkit.org/show_bug.cgi?id=220495.

(There was a small error this also fixes in that we didn't reference a definition of the name attribute that was inclusive of the name attribute of the object element.) Part of #6003.

domenic · 2021-01-15T18:21:31Z

It looks like @mfreed7 is interested in having Chrome follow Firefox and return empty for navigator.plugins and navigator.mimeTypes, hooray!

@annevk, can you give more details on what Firefox does? For example, I could imagine:

Totally removing PluginArray, MimeTypeArray, Plugin, and MimeType, and having navigator.plugins and navigator.mimeTypes return (frozen?) normal arrays.
Not removing any interfaces, and just having the lists always be zero-length, and navigator.plugins.refresh() always a no-op

... or something in between

I suspect (2) is going to be easiest, but is that what Firefox did? A spec PR would be great, where we can hash out the details.

(Also, I guess navigator.javaEnabled() always returns false now?)

mfreed7 · 2021-01-15T19:28:57Z

😄

For at least a while (weeks? a milestone or two?) my plan is to just do #2. That also appears to be what Firefox has done, at least in effect. And in Chromium, FYI, javaEnabled() has been false since M45.

I'd be happy to do more (i.e. #1), but I suspect that would cause major compat issues. Navigator.plugins is used on 60% of pageloads today. And I would guess those numbers will stay high even after the APIs start returning [].

domenic · 2021-01-15T19:40:02Z

On the compat front, I suspect that removing PluginArray and MimeTypeArray would be hard, because of the extra methods (refresh(), item(), and namedItem()) which wouldn't be present on normal arrays.

But removing Plugin and MimeType might be easier, since if navigator.plugins and navigator.mimeTypes return [], then the only way to detect their existence is by checking for window.Plugin and window.MimeType, which is pretty pointless (and so, I would suspect, unlikely).

Going with just (2) for now makes a lot of sense to me; you're already taking on a nice chunk of work!

mfreed7 · 2021-01-15T20:17:26Z

Good point about Plugin and MimeType. Perhaps while I'm emptying the arrays, I'll also add use counters for the Plugin and MimeType constructors. Then we can see how often people construct those directly.

Part of #6003.

domenic · 2021-01-15T20:30:14Z

They don't even have constructors, so literally the only thing people could be doing is accessing the properties, like if (window.Plugin) or something.

I posted a PR at #6296. As you can see there, because the arrays are now always empty and thus no Plugin or MimeType instances can ever exist, we can simplify their IDL and algorithms dramatically.

Part of #6003.

davidp3 · 2021-01-15T20:44:19Z

I suspect (2) is going to be easiest, but is that what Firefox did?

Firefox does (2) but not as a special case -- the arrays are just naturally empty. In an upcoming cleanup patch, they will be replaced with hard-coded empty arrays but still type (2) -- we do still have the PluginArray and MimeTypeArray IDL types. But this is the browser's only use of those types -- finding a way to get rid of them would be nice.

I guess we also still have the Plugin and MimeType types but they are useless as mentioned.

foolip · 2021-01-18T19:05:22Z

I guess we also still have the Plugin and MimeType types but they are useless as mentioned.

I looked into this a bit in mdn/browser-compat-data#7863 last week. On Safari iOS, the Plugin and MimeType interfaces are not exposed, while PluginArray and MimeTypeArray are. This makes some sense since the "arrays" are always empty, and there can be no instances of Plugin or MimeType.

This behavior seems to go back to iOS 8, but I haven't confirmed in detail if all aspects of is changed then. In any case it's not new.

I think this gives some confidence that not having Plugin or MimeType is web compatible, and it seems worth trying to match Safari iOS by removing them.

tomayac · 2021-01-19T08:48:56Z

According to brave/brave-browser#1549, Brave has been returning static values for plugins and mimeTypes for a while now.

Part of #6003.

mfreed7 · 2021-01-19T21:03:05Z

Thanks for the comments here. Please see the blink-dev discussion for more context, but I'm hoping to make this change in Chromium Canary soon, to at least see what the compat impact is. I like the idea of removing Plugin and MimeType also, given the iOS research above.

@rniwa, @hober any thoughts on this one?

mfreed7 · 2021-01-20T19:25:59Z

Ok, the change has landed in Chromium ToT. If anyone notices a site issue, please file a bug and cc me.

I've also filed a bug to track the potential removal of window.Plugin and window.MimeType entirely.

rniwa · 2021-01-21T00:54:41Z

Okay, I've asked internally, and I got a reply that we had to list the PDF plugin or else multiple websites would ask the user to download Adobe Acrobat Reader so there is some compatibility risk for this change.

mfreed7 · 2021-01-22T00:49:33Z

Okay, I've asked internally, and I got a reply that we had to list the PDF plugin or else multiple websites would ask the user to download Adobe Acrobat Reader so there is some compatibility risk for this change.

Great, thanks for that information. I'll watch for similar bug reports against Chromium. Do you happen to know when that change was attempted/reverted? I'm wondering if things may have (hopefully!) changed since then.

Part of #6003.

* Editorial: remove redundant "the" * Meta: default branch rename Also correct a broken link. Not even w3.org URLs are that cool. Helps with whatwg/meta#174. * Editorial: clean up calls to "parse a URL" It actually takes a string, so calls should be clear about that. * Review Draft Publication: January 2021 * Simplify <link>s In particular, remove their activation behavior, stop them from matching :link and :visited, and stop suggesting that they be focusable areas. This also includes a slight expansion and rearrangement of the link element's section to make it clearer what hyperlinks created by <link> are meant for, contrasting them to <a> and <area> hyperlinks. Closes whatwg#4831. Closes whatwg#2617. Helps with whatwg#5490. * Meta: remove demos/offline/* (whatwg#6307) These are no longer needed as of e4330d5. * Meta: minor references cleanup Use more HTTPS and drop obsolete HTML Differences reference. * Editorial: anticlockwise → counterclockwise We use en-US these days. Spotted in https://twitter.com/iso2022jp/status/1352601086519955456. * Use :focus-visible in the UA stylesheet See w3c/csswg-drafts#4278. * Editorial: align with WebIDL and Infra * Fix "update a style block" early return The new version matches implementation reality and CSSWG resolution. The algorithm was also inconsistent, as it looked at whether the element was in a shadow tree or in the document tree, but it was only specified to be re-run if the element becomes connected or disconnected. The CSSWG discussed this in w3c/csswg-drafts#3096 (comment) and http://wpt.live/shadow-dom/ShadowRoot-interface.html tests this. This also matches closer the definition of <link rel="stylesheet">, which does use connectedness (though it uses "browsing-context connected", which is a bit different): https://html.spec.whatwg.org/#link-type-stylesheet * Modernize and refactor simple dialogs This contains a small bug fix, in that confirm() and prompt() said "return" in some cases instead of "return false" or "return null" as appropriate. Other notable changes, all editorial, are: * Factoring out repeated "cannot show simple dialogs" steps, which will likely expand over time (see e.g. whatwg#6297). * Separating out and explaining the no-argument overload of alert(). * Passing the document through to the "printing steps", instead of just having them talk about "this Window object". * Meta: add definition markup for MessageEvent * Remove <marquee> events They are only supported by one engine (Gecko). Closes whatwg#2957. * Clarify when microtasks happen * Ignore COEP on non-secure contexts Fixes whatwg#6328. * Editorial: update URL Standard integration * Editorial: only invoke response's location URL once Complements whatwg/fetch#1149. * Track the incumbent settings and active script in Promise callbacks Closes whatwg#5213. * createImageBitmap(): stop clipping sourceRect to source's dimensions It has been found in whatwg#6306 that this was an oversight at the time of its introduction. Current behavior goes against author expectations and no implementer has opposed the change to "no-clip". Tests: web-platform-tests/wpt#27040. Closes whatwg#6306. * Remove CSP plugin-types blocking With Flash not being supported anymore, the CSP directive plugin-types has lost its main reason for being and is being removed from the Content Security Policy specification: w3c/webappsec-csp#456. This change removes references to the relevant algorithm from the Content Security Policy spec. * Meta: set more dfn types A follow-up to: * whatwg#5694 * whatwg#5916 * Editorial: occuring → occurring * Make all plugin-related APIs no-ops Part of whatwg#6003. * Disallow simple dialogs from different-origin domain iframes Closes whatwg#5407. * Revive @@iterator for PluginArray/MimeTypeArray/Plugin @@iterator is implicitly installed by defining an indexed property getter. Since there is no other way to define it exclusively, this restores some methods back to being indexed getters. This fixes an inadvertent observable behavior change in d4f07b8. * Adjust web+ scheme security considerations to account for FTP removal Also, network scheme is now reduced to HTTP(S) scheme. Helps with whatwg#5375, but form submission issue remains. See whatwg/fetch#1166 for context. * Meta: export pause Nobody but XMLHttpRequest take a dependency on this please. You have been warned. Context: whatwg/xhr#311. * Fix typo: ancestor → accessor Fixes whatwg#6374. Co-authored-by: Dominic Farolino <domfarolino@gmail.com> Co-authored-by: Anne van Kesteren <annevk@annevk.nl> Co-authored-by: Domenic Denicola <d@domenic.me> Co-authored-by: Emilio Cobos Álvarez <emilio@crisal.io> Co-authored-by: Momdo Nakamura <xmomdo@gmail.com> Co-authored-by: Jake Archibald <jaffathecake@gmail.com> Co-authored-by: Yutaka Hirano <yhirano@chromium.org> Co-authored-by: Shu-yu Guo <syg@chromium.org> Co-authored-by: Kaiido <tristan.fraipont@gmail.com> Co-authored-by: Antonio Sartori <anton.sartori@gmail.com> Co-authored-by: Michael[tm] Smith <mike@w3.org> Co-authored-by: Ikko Ashimine <eltociear@gmail.com> Co-authored-by: Carlos IL <carlosjoan91@gmail.com> Co-authored-by: Kagami Sascha Rosylight <saschanaz@outlook.com> Co-authored-by: Simon Pieters <zcorpan@gmail.com>

This addresses the discussion starting at #6003 (comment). It ensures browsers only vary on a single boolean, "PDF viewer supported". Then, it: * Standardizes a new navigator.pdfViewerSupported property which exposes that boolean directly. * Makes the legacy navigator.plugins and navigator.mimeTypes APIs expose a uniform set of Plugin and MimeType objects, across every browser, in one of two configurations (depending on the PDF viewer supported boolean). * Gets rid of the generic plugin path in navigation, instead replacing it with specific paths for application/pdf and text/pdf which are tied to the PDF viewer supported boolean. Closes #6317 since that idea is no longer possible in this framework. Helps with #6003.

As reported by dg12 on Matrix, with Flash no longer being supported, it shouldn't be listed as an example of the use of plugins. Furthermore, since whatwg#6003 aims to remove any complexity around plugins except for that which is needed for PDF viewers, it is clear that plugins in general are no longer an extensibility mechanism.

domenic · 2021-07-22T22:21:05Z

I think we've finished the saga of navigator.plugins and navigator.mimeTypes.

At the next triage meeting I'd like to discuss if anyone is willing to spend time on the other issues in the OP.

With Flash no longer being supported, it shouldn't be listed as an example of the use of plugins. Furthermore, since #6003 aims to remove any complexity around plugins except for that which is needed for PDF viewers, it is clear that plugins in general are no longer an extensibility mechanism.

Instead, sandboxed iframes are just never allowed to display plugins. (Which, in the modern world, just means PDFs.) Closes #3958. Helps with #6003.

Instead, sandboxed documents are just never allowed to display plugins. (Which, in the modern world, just means PDFs.) Closes #3958. Helps with #6003.

mfreed7 · 2021-10-04T17:57:45Z

Quick check in on this issue. Chromium implemented and shipped the "Fixed" set of plugins and mimetypes in M94, which has been in stable release for about a week at this point. It is still too early to declare a full success, but I can at least report that I do not know of any reported breakage bugs due to this change. Which at least means that this change doesn't break the world. I'll update here if something does come up that looks bad, but otherwise we can perhaps conclude that the fixed plugin lists are web compatible.

mfreed7 · 2021-11-10T20:14:51Z

It has now been about a month and a half, and Chromium is almost 2 versions past M94 where these changes were made. I am unaware of any reported issues. I think it might now be safe to declare victory in removing this fingerprinting vector.

For reference, here are the related implementation bugs:

Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1720353
WebKit: https://bugs.webkit.org/show_bug.cgi?id=220495
Chromium (fixed): https://bugs.chromium.org/p/chromium/issues/detail?id=1164635

Given that plugins are gone from the web platform (with their full removal from the spec being tracked in #6003), it is not useful. In some browsers it can be used to figure out the URL of an <object>, even when that <object> is not being used for a plugin, via params named "movie", "src", "code", or "url". But we decided to remove this behavior from browsers instead of specifying it. This retains the HTMLParamElement interface, as well as the parser behavior of <param>. Closes #387. Helps with #6003.

This addresses the discussion starting at whatwg#6003 (comment). It ensures browsers only vary on a single boolean, "PDF viewer supported". Then, it: * Standardizes a new navigator.pdfViewerSupported property which exposes that boolean directly. * Makes the legacy navigator.plugins and navigator.mimeTypes APIs expose a uniform set of Plugin and MimeType objects, across every browser, in one of two configurations (depending on the PDF viewer supported boolean). * Gets rid of the generic plugin path in navigation, instead replacing it with specific paths for application/pdf and text/pdf which are tied to the PDF viewer supported boolean. Closes whatwg#6317 since that idea is no longer possible in this framework. Helps with whatwg#6003.

With Flash no longer being supported, it shouldn't be listed as an example of the use of plugins. Furthermore, since whatwg#6003 aims to remove any complexity around plugins except for that which is needed for PDF viewers, it is clear that plugins in general are no longer an extensibility mechanism.

Instead, sandboxed documents are just never allowed to display plugins. (Which, in the modern world, just means PDFs.) Closes whatwg#3958. Helps with whatwg#6003.

Given that plugins are gone from the web platform (with their full removal from the spec being tracked in whatwg#6003), it is not useful. In some browsers it can be used to figure out the URL of an <object>, even when that <object> is not being used for a plugin, via params named "movie", "src", "code", or "url". But we decided to remove this behavior from browsers instead of specifying it. This retains the HTMLParamElement interface, as well as the parser behavior of <param>. Closes whatwg#387. Helps with whatwg#6003.

domenic · 2022-11-30T10:41:38Z

A status update:

Much of what the OP lists has been completed. What remains is:

Removing the concept of a plugin, and ensuring every part of the spec that used to interface with it, instead talks about PDF rendering.
Simplifying object and embed, as much as possible.

It's tempting to entangle these tasks. E.g. do browsers really check for file extensions for PDFs? Do mutations of the classid attribute really cause PDFs to reload? Is the type attribute still relevant when PDFs are the only option? Etc.

Some sub-issues on this subject:

See crbug.com/1315717 for more details, but this flag has been disabled on Stable Chrome for >3 weeks (and smaller percentages for much longer than that) and no bugs have been reported. This CL removes the feature entirely, which removes the ability to use a <param> element inside an <object> element, to set the object's URL. The I2D is at [1]. More discussion is at [2]. [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/dDu4CgAwRwQ/m/--LdmX3vEwAJ [2] whatwg/html#6003 Fixed: 1315717 Bug: 572908 Change-Id: I1dbd0b9f7567be77f3ce39911690323296e89f70 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4134107 Reviewed-by: Reilly Grant <reillyg@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1092542}

domenic added the removal/deprecation Removing or deprecating a feature label Oct 1, 2020

annevk added the topic: embed and object label Jan 6, 2021

annevk mentioned this issue Jan 11, 2021

PDF loading examples web-platform-tests/wpt#27129

Open

annevk mentioned this issue Jan 12, 2021

Remove the object element from submittable elements #6281

Merged

3 tasks

domenic added a commit that referenced this issue Jan 15, 2021

Make all plugin-related APIs no-ops

6eb7e83

Part of #6003.

domenic mentioned this issue Jan 15, 2021

Make all plugin-related APIs no-ops #6296

Merged

3 tasks

domenic added a commit that referenced this issue Jan 15, 2021

Make all plugin-related APIs no-ops

abf3fea

Part of #6003.

domenic added a commit that referenced this issue Jan 19, 2021

Make all plugin-related APIs no-ops

91587f4

Part of #6003.

annevk mentioned this issue Jan 21, 2021

Remove Plugin and MimeType classes #6317

Closed

domenic added a commit that referenced this issue Feb 5, 2021

Make all plugin-related APIs no-ops

fb1900d

Part of #6003.

domenic added a commit that referenced this issue Feb 8, 2021

Make all plugin-related APIs no-ops

d4f07b8

Part of #6003.

annevk mentioned this issue Feb 24, 2021

Some outdated description in Introduction #6412

Closed

andreubotella mentioned this issue Jul 16, 2021

Editorial: Plugins are no longer an extensibility mechanism #6867

Merged

past mentioned this issue Jul 20, 2021

Upcoming HTML standard issue triage meeting on 7/1/2021 #6739

Closed

domenic added agenda+ To be discussed at a triage meeting and removed agenda+ To be discussed at a triage meeting labels Jul 22, 2021

past mentioned this issue Aug 5, 2021

Upcoming HTML standard issue triage meeting on 8/5/2021 #6884

Closed

domenic added a commit that referenced this issue Aug 9, 2021

Remove the notion of "secured plugins"

ef166a5

Instead, sandboxed iframes are just never allowed to display plugins. (Which, in the modern world, just means PDFs.) Closes #3958. Helps with #6003.

domenic mentioned this issue Aug 9, 2021

Remove the notion of "secured plugins" #6946

Merged

3 tasks

annevk pushed a commit that referenced this issue Aug 30, 2021

Remove the notion of "secured plugins"

c2bcadd

Instead, sandboxed documents are just never allowed to display plugins. (Which, in the modern world, just means PDFs.) Closes #3958. Helps with #6003.

past removed the agenda+ To be discussed at a triage meeting label Sep 2, 2021

past mentioned this issue Sep 2, 2021

Upcoming HTML standard issue triage meeting on 9/2/2021 #6936

Closed

hamishwillee mentioned this issue Mar 4, 2022

[WebAPI] Implement navigator.pdfViewerEnabled mdn/content#13370

Closed

7 tasks

domenic mentioned this issue Apr 12, 2022

Obsolete the <param> element #7816

Merged

3 tasks

mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022

Remove the notion of "secured plugins"

8562a2b

Instead, sandboxed documents are just never allowed to display plugins. (Which, in the modern world, just means PDFs.) Closes whatwg#3958. Helps with whatwg#6003.

This was referenced Nov 30, 2022

Export navigable container document #8556

Merged

Add sandbox attribute to <object> element #2514

Closed

AnudeepChPaul mentioned this issue Aug 1, 2023

[FLEXIN-212] - Now generating security headers twilio/twilio-webchat-react-app#43

Merged

1 task

annevk mentioned this issue Sep 16, 2024

Description corresponding of "Any other attribute" of embed element is not found #10626

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Removing plugins? #6003

Removing plugins? #6003

domenic commented Oct 1, 2020

annevk commented Oct 5, 2020

annevk commented Jan 6, 2021 •

edited

Loading

annevk commented Jan 9, 2021

domenic commented Jan 15, 2021

mfreed7 commented Jan 15, 2021

domenic commented Jan 15, 2021

mfreed7 commented Jan 15, 2021

domenic commented Jan 15, 2021

davidp3 commented Jan 15, 2021

foolip commented Jan 18, 2021 •

edited

Loading

tomayac commented Jan 19, 2021

mfreed7 commented Jan 19, 2021

mfreed7 commented Jan 20, 2021

rniwa commented Jan 21, 2021

mfreed7 commented Jan 22, 2021

domenic commented Jul 22, 2021

mfreed7 commented Oct 4, 2021

mfreed7 commented Nov 10, 2021

domenic commented Nov 30, 2022

Removing plugins? #6003

Removing plugins? #6003

Comments

domenic commented Oct 1, 2020

annevk commented Oct 5, 2020

annevk commented Jan 6, 2021 • edited Loading

annevk commented Jan 9, 2021

domenic commented Jan 15, 2021

mfreed7 commented Jan 15, 2021

domenic commented Jan 15, 2021

mfreed7 commented Jan 15, 2021

domenic commented Jan 15, 2021

davidp3 commented Jan 15, 2021

foolip commented Jan 18, 2021 • edited Loading

tomayac commented Jan 19, 2021

mfreed7 commented Jan 19, 2021

mfreed7 commented Jan 20, 2021

rniwa commented Jan 21, 2021

mfreed7 commented Jan 22, 2021

domenic commented Jul 22, 2021

mfreed7 commented Oct 4, 2021

mfreed7 commented Nov 10, 2021

domenic commented Nov 30, 2022

annevk commented Jan 6, 2021 •

edited

Loading

foolip commented Jan 18, 2021 •

edited

Loading