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

[Mason Freed]

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

navigator, plugins

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]

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]

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

navigator, plugins

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]

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.

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

[Daniel Bratell]

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

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

[Eric Lawrence]

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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjOgfxsotpc7As9FwUWfVYkhWPU2MBkiQ64%3DJbm8xo%2B8g%40mail.gmail.com.

[Philip Jägenstedt]

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]

Thanks everyone!

[Mike West]

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]

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]

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]

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.

[Mason Freed]

Ok, I'm back on this thread/I2S to request another approval. I've updated the chromestatus accordingly, but the new proposal is to return a fixed, hard-coded list of plugins and mimetypes, corresponding to commonly-used PDF viewers. The problem with the original attempt (which completely emptied both navigator.plugins and navigator.mimeTypes) was that several large sites searched the list of plugins to determine if a PDF viewer was supported. After several discussions with the HTML spec community, we decided to agree (across browsers) on a fixed list of plugin names that would allow the previously-broken sites to continue working, while still reducing the fingerprinting surface available through this API. Additionally, a new API, navigator.pdfViewerEnabled, can be used to more easily check whether a PDF viewer is available and enabled in a given UA.

In the same way that I approached the "emptying" of these arrays before, I plan to land this change just after the branch point of M93 (so starting in Canary M94), to give maximum soak time in Canary/Dev/Beta. There is a Finch flag that can be used to field-disable this feature if problems eventually materialize in Stable.

Let me know your thoughts/concerns.

Thanks,

Mason

-mike

Thanks everyone!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike West]

Hey Mason, thanks for bringing this back to the list!

I'm supportive of the direction y'all have landed on, but I don't see explicit support in the PR from our cross-vendor colleagues. You reference a spec triage meeting in your last comment: are there minutes recording folks' support? Getting a clear indication that other vendors will align with this change would be ideal.

-mike

[Philip Jägenstedt]

Mason can correct me if there's more discussion, but I believe https://github.com/whatwg/html/issues/6003#issuecomment-805389170 and following comments is the cross-vendor discussion on how to hard code a list of PDF plugins. Ryosuke (Apple) suggested it, and Anne (Mozilla) was also supportive and closely involved.

It would be great to get https://github.com/whatwg/html/pull/6738 merged, is that now just blocked on getting a final look from other vendors?

[Domenic Denicola]

From: Philip Jägenstedt <foo...@chromium.org>

> It would be great to get https://github.com/whatwg/html/pull/6738 merged, is that now just blocked on getting a final look from other vendors?

I think we can go ahead and merge it, as it implements the consensus you mentioned. It would indeed be ideal if other vendors had time to give a full review of the written-up spec, but it's probably better to merge it sooner rather than later, to replace the current not-very-web-compatible empty-lists spec.

[Mason Freed]

Thanks for the comments. This has definitely been an actively-discussed change, with both WebKit and Gecko participating and suggesting directions to go. There has not been a final "yes we definitely agree" from WebKit, but as I mentioned in my comment, I do believe Gecko agrees explicitly with this direction. And it looks like Domenic is working on getting the PR merged as we speak.

Thanks,

Mason

[Mason Freed]

Friendly ping on this I2S thread. Any other questions? The spec landed early last week, and I believe the other questions asked here have been answered. Let me know if there's anything else you'd like to see before approving it. I'd ideally like to get as much "bake time" as possible in M94 Canary/Dev, in case there are still compat issues.

Thanks,

Mason

[Chris Harrelson]

Sounds good to me. My LGTM1 still stands.

--

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%3DNeDjyi-C8ERR9_kuOoEYU2WRQAUTPvq0_9szKS0XSOb729g%40mail.gmail.com.

[Daniel Bratell]

LGTM2 on the modified plan.

/Daniel

[Philip Jägenstedt]

LGTM3, hope it works out!

[Mason Freed]

Thanks everyone!