Intent to Ship: Return empty for navigator.plugins and navigator.mimeTypes

238 views
Skip to first unread message

Mason Freed

unread,
Jan 15, 2021, 1:10:36 PMJan 15
to blink-dev

Contact emails

mason...@chromium.org

Explainer


https://github.com/whatwg/html/issues/6003

Specification

None

Summary

With the removal of Flash, there is no longer the need to return anything for navigator.plugins and navigator.mimeTypes. These APIs were used primarily for a) probing for Flash player support, or b) fingerprinting. As such, we'd like to return empty for these two properties. Gecko already switched to returning *only* Flash starting with Firefox 52, and returning empty as of Firefox 85.



Blink component

Blink

Search tags

navigatorplugins

TAG review

Not an API change, so no TAG review here.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

The usage rate for these two APIs is quite significant: https://chromestatus.com/metrics/feature/timeline/popularity/2662 https://chromestatus.com/metrics/feature/timeline/popularity/2660 Having said that, the perceived risk is much lower than those numbers might indicate. One of the main uses for these two APIs is fingerprinting. Another *was* probing for Flash player support and version number, though since 2016 Blink has only advertised the flash plugin with explicit user opt-in. And now that Flash is completely removed, these use cases should correctly detect no flash support. An additional use case may be attempting to detect PDF support, but given Mozilla's success with not reporting PDF support since Firefox 52, this is likely ok. In essence, returning empty seems to be the correct thing to do. For reference, as of Chrome 89, these are the returned values: navigator.plugins: Chrome PDF Plugin Chrome PDF Viewer Native Client navigator.mimetypes: application/pdf application/x-google-chrome-pdf application/x-nacl application/x-pnacl



Gecko: Shipped/Shipping (https://crbug.com/1164635) This is a request from Mozilla to follow suit.

Edge: No signal

WebKit: No signal

Web developers: No signals


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

No

Tracking bug

https://crbug.com/1164635

Sample links


https://output.jsbin.com/nebaruc

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5741884322349056

This intent message was generated by Chrome Platform Status.

Chris Harrelson

unread,
Jan 15, 2021, 4:10:02 PMJan 15
to Mason Freed, blink-dev
LGTM1

--
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/CAM%3DNeDi4VD6ZnsB5ghk-arG8tsycX2-rOe7dZ_q0dQGYkdThcg%40mail.gmail.com.

Yoav Weiss

unread,
Jan 18, 2021, 9:16:27 AMJan 18
to Mason Freed, blink-dev
On Fri, Jan 15, 2021 at 7:10 PM Mason Freed <mason...@chromium.org> wrote:

Contact emails

mason...@chromium.org

Explainer


https://github.com/whatwg/html/issues/6003

Specification

None

Summary

With the removal of Flash, there is no longer the need to return anything for navigator.plugins and navigator.mimeTypes. These APIs were used primarily for a) probing for Flash player support, or b) fingerprinting. As such, we'd like to return empty for these two properties. Gecko already switched to returning *only* Flash starting with Firefox 52, and returning empty as of Firefox 85.



Blink component

Blink

Search tags

navigatorplugins

TAG review

Not an API change, so no TAG review here.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

The usage rate for these two APIs is quite significant: https://chromestatus.com/metrics/feature/timeline/popularity/2662 https://chromestatus.com/metrics/feature/timeline/popularity/2660


Oh my, that's significant indeed!

Can we gradually roll out that change, so that we can catch unexpected breakage here early?
 

Having said that, the perceived risk is much lower than those numbers might indicate. One of the main uses for these two APIs is fingerprinting. Another *was* probing for Flash player support and version number, though since 2016 Blink has only advertised the flash plugin with explicit user opt-in. And now that Flash is completely removed, these use cases should correctly detect no flash support.

 

An additional use case may be attempting to detect PDF support, but given Mozilla's success with not reporting PDF support since Firefox 52, this is likely ok. In essence, returning empty seems to be the correct thing to do. For reference, as of Chrome 89, these are the returned values: navigator.plugins: Chrome PDF Plugin Chrome PDF Viewer Native Client navigator.mimetypes: application/pdf application/x-google-chrome-pdf application/x-nacl application/x-pnacl



Gecko: Shipped/Shipping (https://crbug.com/1164635) This is a request from Mozilla to follow suit.

Edge: No signal

WebKit: No signal

Can you ask the webkit folks if they'd follow?
 

Web developers: No signals


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

No

Tracking bug

https://crbug.com/1164635

Sample links


https://output.jsbin.com/nebaruc

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5741884322349056

This intent message was generated by Chrome Platform Status.

--

Philip Jägenstedt

unread,
Jan 18, 2021, 2:07:59 PMJan 18
to Yoav Weiss, Mason Freed, blink-dev
I just commented on the HTML issue about the behavior in Safari iOS. I think we can take the fact that they've already been shipping this behavior for years as a strong signal, and furthermore we should probably try to not expose the Plugin and MimeType interfaces to match their behavior. This has a minor extra benefit that it could be used (by very savvy developers) to distinguish between no plugins because none are installed, and plugin support being removed from the browser.

Daniel Bratell

unread,
Jan 19, 2021, 5:45:23 AMJan 19
to Philip Jägenstedt, Yoav Weiss, Mason Freed, blink-dev

I'd be ready to believe that even if 60% of page loads end up accessing these properties, very few actually care about the content of the lists. The problem is that "very few" of 60% might still be a substantial number.  I don't think so, but I also don't know how to be absolutely certain. A gradual approach might be suitable.

If we can remove the content of the lists in a way that allows the change to be reverted quickly (and hopefully temporarily), I'd be willing to approve that with no further data based on Firefox and Safari's success. And just to not forget about it... enterprise?

/Daniel

Eric Lawrence

unread,
Jan 19, 2021, 10:23:42 AMJan 19
to blink-dev, Daniel Bratell, Mason Freed, blink-dev, Philip Jägenstedt, yo...@yoav.ws
For Edge, this sounds like a good change to help mitigate fingerprinting and reduce confusion.

Edge currently returns the same information as Chrome does (modulo our PDF viewer is named "Microsoft Edge PDF Viewer").

These APIs /might've/ been useful for detecting whether Native Client was supported on a given browser, except that Edge never bothered to remove the item from the array despite not supporting Native Client. But it looks like NativeClient doesn't really work on the open web in Chrome anymore either (crbug.com/918374).

Mason Freed

unread,
Jan 19, 2021, 4:00:27 PMJan 19
to Daniel Bratell, Philip Jägenstedt, Yoav Weiss, blink-dev
Thanks for all of the comments here. See my responses inline...
On Mon, Jan 18, 2021 at 3:16 PM Yoav Weiss <yo...@yoav.ws> wrote:

Oh my, that's significant indeed!

Can we gradually roll out that change, so that we can catch unexpected breakage here early?
Yes, the usage is significant, and as Daniel pointed out, if even a fraction actually depends on this, there could be compat concerns. Due to the sheer amount of usage, it'll be very difficult to try to suss this out via HTTP Archive or manual searching of sites. Therefore, my plan was to roll this out in the early days of a fresh Canary cycle (e.g. right now, for M90) and let it "soak" for a few weeks in Canary/Dev, to see what bug reports pop up, and what types of usage patterns turn out to be troublesome. And then re-evaluate the rollout plan for this change, based on the results. Let me know if you think that counts as a "gradual roll out". I did add a Finch flag, both for use as a kill switch, but also so that we could potentially use it to run a small experiment on Beta/Stable, when the time comes. I do appreciate the concern over compat, and I share the concern. Should this turn out to be a breaking change, I will definitely adjust the roll out plan.
 

Can you ask the webkit folks if they'd follow?
 Yes, definitely. I'll reach out to webkit on this. From Philip's research, iOS Safari already returns empty.


On Tue, Jan 19, 2021 at 2:45 AM Daniel Bratell <brat...@gmail.com> wrote:

I'd be ready to believe that even if 60% of page loads end up accessing these properties, very few actually care about the content of the lists. The problem is that "very few" of 60% might still be a substantial number.  I don't think so, but I also don't know how to be absolutely certain. A gradual approach might be suitable.

If we can remove the content of the lists in a way that allows the change to be reverted quickly (and hopefully temporarily), I'd be willing to approve that with no further data based on Firefox and Safari's success. And just to not forget about it... enterprise?

Thanks for the comments. See above for more on the usage - generally I agree. I have added a Finch killswitch, which will allow the old behavior to be quickly restored. And I plan to closely monitor for bugs for a few weeks.

Thanks for the reminder about Enterprise. I'll reach out to the Enterprise group also.
 

/Daniel


On 2021-01-18 20:07, Philip Jägenstedt wrote:
I just commented on the HTML issue about the behavior in Safari iOS. I think we can take the fact that they've already been shipping this behavior for years as a strong signal, and furthermore we should probably try to not expose the Plugin and MimeType interfaces to match their behavior. This has a minor extra benefit that it could be used (by very savvy developers) to distinguish between no plugins because none are installed, and plugin support being removed from the browser.

Thanks for doing the research on iOS - I hadn't tested that. I only looked at Mac Safari, which does return non-empty arrays, only for the PDF viewer. I agree that this, combined with Firefox's currently-empty arrays, should be a good signal that this change is relatively safe. And I agree about the Plugin and MimeType interfaces. I'd like to tackle that after the "first stage" of emptying the PluginArray and MimeTypeArray arrays, if that's ok with you.

Thanks,
Mason
 
 

Mason Freed

unread,
Jan 19, 2021, 7:27:35 PMJan 19
to blink-dev, eri...@microsoft.com, Daniel Bratell, Mason Freed, blink-dev, Philip Jägenstedt, yo...@yoav.ws
On Tuesday, January 19, 2021 at 7:23:42 AM UTC-8 eri...@microsoft.com wrote:
For Edge, this sounds like a good change to help mitigate fingerprinting and reduce confusion.

Edge currently returns the same information as Chrome does (modulo our PDF viewer is named "Microsoft Edge PDF Viewer").

These APIs /might've/ been useful for detecting whether Native Client was supported on a given browser, except that Edge never bothered to remove the item from the array despite not supporting Native Client. But it looks like NativeClient doesn't really work on the open web in Chrome anymore either (crbug.com/918374).

Thanks for this feedback! I'm glad this sounds good from Edge's perspective. Also thanks for the details about how these APIs work today in Edge. More evidence that this change is likely safer than it looks.

Yoav Weiss

unread,
Jan 20, 2021, 12:48:36 AMJan 20
to Mason Freed, Daniel Bratell, Philip Jägenstedt, blink-dev
LGTM2 for the plan outlined above to slowly roll out to Canary/Dev with a kill switch that'd enable to roll this back in case of significant breakage.

Mike West

unread,
Jan 20, 2021, 3:03:24 AMJan 20
to Yoav Weiss, Mason Freed, Daniel Bratell, Philip Jägenstedt, blink-dev
LGTM3, with the same caveats, and another vote for looping in the enterprise team.

-mike


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

Philip Jägenstedt

unread,
Jan 20, 2021, 4:43:10 AMJan 20
to Mike West, Yoav Weiss, Mason Freed, Daniel Bratell, blink-dev
LGTM4, just to say I'm happy to see this cleanup is happening, and that we can do it in a way that both matches other browsers and with a plan to revert and adjust if we see breakage.

Mason Freed

unread,
Jan 20, 2021, 12:01:45 PMJan 20
to Philip Jägenstedt, Mike West, Yoav Weiss, Daniel Bratell, blink-dev
Thanks everyone!

Mike West

unread,
Jan 21, 2021, 8:17:08 AMJan 21
to Mason Freed, Philip Jägenstedt, Yoav Weiss, Daniel Bratell, blink-dev
As you likely noticed on the HTML issue, our friends at Apple had some feedback on their experience which points to continuing to list the PDF type as being useful for compatibility: https://github.com/whatwg/html/issues/6003#issuecomment-764119990. Can I assume that as that issue coalesces into a PR that y'all agree upon, you'll take that into account? :)

-mike

Mason Freed

unread,
Jan 21, 2021, 7:53:21 PMJan 21
to Mike West, Philip Jägenstedt, Yoav Weiss, Daniel Bratell, blink-dev
On Thu, Jan 21, 2021 at 5:17 AM Mike West <mk...@chromium.org> wrote:
As you likely noticed on the HTML issue, our friends at Apple had some feedback on their experience which points to continuing to list the PDF type as being useful for compatibility: https://github.com/whatwg/html/issues/6003#issuecomment-764119990. Can I assume that as that issue coalesces into a PR that y'all agree upon, you'll take that into account? :)

Yes, thanks - I saw the comment. I'll be on the lookout for PDF-related bug reports. If that turns out to still be an issue, we may need to just freeze the list with only the PDF viewer, rather than being able to completely remove Plugin and MimeType. That would still be a privacy win, I think.

Thanks,
Mason

Mason Freed

unread,
Feb 5, 2021, 2:34:04 PMFeb 5
to Mike West, Philip Jägenstedt, Yoav Weiss, Daniel Bratell, blink-dev
Quick check-in on the removal of navigator.plugins and navigator.mimeTypes. It has been over 2 weeks since the arrays were "emptied" in Chromium Canary/Dev, and only one issue has surfaced: some apps/extensions were doing feature detection of NaCl/PNaCl using navigator.mimeTypes. For that reason, this change was reverted for apps and extensions, but the arrays remain empty for the open web. I have not seen any other bug reports that appear to be related to this change. So... with cautious optimism, I'm leaving the arrays empty for now. I'll continue to monitor and report back here.

Mason Freed

unread,
Mar 23, 2021, 10:05:40 PMMar 23
to blink-dev, Mason Freed, Philip Jägenstedt, yo...@yoav.ws, Daniel Bratell, blink-dev, Mike West
Checking back in on this thread, as there have now (with M90 going to Beta) been a few reports of broken site behavior, particularly around PDF viewer detection. Several office suite products are broken by this change, as their printing features incorrectly assume there's no PDF viewer, and instead download the to-be-printed file. As a result, I've Finch-disabled this change, and will also be disabling in code. See more comments here, in case you have more feedback for me on the value of this change. For now, though, we won't be shipping this change.

Thanks,
Mason


-mike


Thanks everyone!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages