The default bug view has changed. See this FAQ.

Remove unused plugins.enumerable_names whitelist that hides plugins from navigator.plugins enumeration

RESOLVED FIXED in Firefox 41

Status

()

Core
Plug-ins
RESOLVED FIXED
2 years ago
9 months ago

People

(Reporter: cpeterson, Assigned: cpeterson)

Tracking

unspecified
mozilla41
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox41 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
Created attachment 8613243 [details] [diff] [review]
remove_plugins-enumerable_names.patch

Bug 757726 hid most plugins from navigator.plugins enumeration to reduce fingerprinting. Plugin detection scripts could ask for a plugin or MIME type by name, but they couldn't get a list of all installed plugins. Unfortunately, the feature had to be disabled because it broke pretty much all plugin detection scripts because they naively search for the desired plugin using an O(n) loop instead of a O(1) query.

This patch removes the disabled code because it is unlikely we could ever re-enable it. In addition to removing the obsolete navigator.plugin tests for detecting hidden plugins, it adds tests for detecting click-to-play and disabled plugins.
Attachment #8613243 - Flags: review?(benjamin)
Attachment #8613243 - Flags: review?(benjamin) → review+

Comment 1

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/882f1779b4d8
https://hg.mozilla.org/mozilla-central/rev/882f1779b4d8
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox41: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
(Assignee)

Updated

2 years ago
Blocks: 990808
(Assignee)

Updated

2 years ago
Blocks: 1009117

Comment 3

2 years ago
Why would you remove this setting?

I can speak for at least ~2,181 daily active users who thought it made Firefox better.
https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-plugins-mimety/
Comment hidden (abuse)

Comment 5

a year ago
Can we get this amended, please?  At least make it optional, configurable behaviour.  This is a retrograde step for privacy.  According to https://panopticlick.eff.org, my browser is now unique in the entire of their sample of close to 6 million tests, whereas it used to be a couple of orders of magnitude less.

Comment 6

a year ago
Well said, sisyphus!

Chris Peterson, if your concern is that privacy conscious users to can enable an obscure config flag, and it will break what you call "naively" coded websites, then that begs the question. What is your goal? Are you trying to coddle Firefox users and/or naive web developers, or are you taking an anti-privacy stance?

Personally, I've switched to Chrome at this point. Privacy was pretty much the only reason I used Firefox, and maybe I was being naive to assume that would remain a priority of Mozilla's?
(Assignee)

Comment 7

a year ago
I care about both user privacy and making sure websites they care about work correctly.

The plugins.enumerable_names whitelist was incomplete fingerprinting protection and broke a lot of websites.
The whitelist breaks on nearly all websites that depend on a plugin not exposed in the plugins.enumerable_names pref. Please refer to the tech evangelism bugs related to the whitelist for examples of sites that were broken, contacted by Mozilla, and still have not fixed their plugin detection. For every website reported, there are likely 100x more broken but not reported.

But the big hole is that any plugins enabled but not whitelisted are still visible to tracking websites because they can query navigator.plugins using a long list of known plugin names. A better solution is to configure your plugins to "Never Activate" by default and them allow individual plugins on on the websites that use them. That will protect you from both plugin fingerprinting and plugin vulnerability exploits on random websites or ad networks. Bug 1186948 could make per-site enumeration opt-in easier by hiding click-to-play ("Ask to Activate") plugins from websites enumerating navigator.plugins until the user clicks the click-to-play button.

Comment 8

a year ago
Thanks for the response, @cpeterson. I understand your point of view better now. You were removing the feature, largely because the whitelisting aspect didn't work as intended. From my perspective though, I had only ever set the value to "". This blocked enumeration altogether. Used like this, the functionality was actually great!

You're right that sites would be able to query for specific plugin names, regardless. The truth is though, that raises the skill bar and the cost to privacy violators. There's a short term cost of course, for upgrading to use that feature. And then a long term cost, for keeping the list of plugins updated.

I still think a simplified version of this setting, that acted as a Boolean essentially, would be great. Speaking personally, prior to your change, setting the value to "" did break a few naively developed sites, and it didn't bother me at all. The sites it broke tended to be poorly developed, and designed, in a lot of senses. Would it be possible to make a new config setting, that just acted as a Boolean version of plugins.enumerable_names = "" || default?

Setting plugins to "Never Activate" hides the footprint effectively. Though, I'm not seeing an option to enable them per site, while they are set to "Never Activate."
(Assignee)

Comment 9

a year ago
(In reply to ChrisAntaki from comment #8)
> Setting plugins to "Never Activate" hides the footprint effectively. Though,
> I'm not seeing an option to enable them per site, while they are set to
> "Never Activate."

To configure per-site plugin permissions, open the site's "Page Info" dialog using CTRL+I or CMD+I. Click to the dialog's "Permissions" tab and change the plugin from "Use Default" (which would be "Never Activate") to "Allow".

Comment 10

a year ago
Great, thanks for the tip

Comment 11

a year ago
@cpeterson, would you recommend a venue where we could request this setting be brought back, in at least a Boolean form? (Default value or "")
(Assignee)

Comment 12

a year ago
I'm not the Mozilla module owner for making decisions about NPAPI plugins. The best place would be to start a discussion on mozilla.dev.tech.plugins mailing list:

https://groups.google.com/forum/#!forum/mozilla.dev.tech.plugins

Comment 13

a year ago
Thanks, I'll start a discussion there!

Comment 14

a year ago
Here's a new discussion on the mozilla.dev.tech.plugins mailing list:

"Helping ensure privacy + security"
https://groups.google.com/forum/#!topic/mozilla.dev.tech.plugins/_PsjN5SvZlo
(In reply to Chris Peterson [:cpeterson] from comment #9)
> To configure per-site plugin permissions, open the site's "Page Info" dialog
> using CTRL+I or CMD+I. Click to the dialog's "Permissions" tab and change
> the plugin from "Use Default" (which would be "Never Activate") to "Allow".

We added a nifty "Permissions" section to the door hanger that drops down from the lock or globe icon, but we missed the opportunity to expose the default permissions. I get that usability dictates only showing the non-default settings on the initial panel, but we could have a ">" button like the "Secure Connection" section does that opens a sub-panel with all the known permissions. Or at the very least pops up the Page Info dialog open to the Permissions tab so people can find it easily.
(In reply to Daniel Veditz [:dveditz] from comment #15)
> (In reply to Chris Peterson [:cpeterson] from comment #9)
> > To configure per-site plugin permissions, open the site's "Page Info" dialog
> > using CTRL+I or CMD+I. Click to the dialog's "Permissions" tab and change
> > the plugin from "Use Default" (which would be "Never Activate") to "Allow".
> 
> We added a nifty "Permissions" section to the door hanger that drops down
> from the lock or globe icon, but we missed the opportunity to expose the
> default permissions. I get that usability dictates only showing the
> non-default settings on the initial panel, but we could have a ">" button
> like the "Secure Connection" section does that opens a sub-panel with all
> the known permissions. Or at the very least pops up the Page Info dialog
> open to the Permissions tab so people can find it easily.

I think that is planned in the Permissions revamp.  Aislinn, are we still planning to have a subpanel for Permissions that shows even the default permissions?
Flags: needinfo?(agrigas)

Comment 17

a year ago
(In reply to Tanvi Vyas [:tanvi] from comment #16)
> (In reply to Daniel Veditz [:dveditz] from comment #15)
> > (In reply to Chris Peterson [:cpeterson] from comment #9)
> > > To configure per-site plugin permissions, open the site's "Page Info" dialog
> > > using CTRL+I or CMD+I. Click to the dialog's "Permissions" tab and change
> > > the plugin from "Use Default" (which would be "Never Activate") to "Allow".
> > 
> > We added a nifty "Permissions" section to the door hanger that drops down
> > from the lock or globe icon, but we missed the opportunity to expose the
> > default permissions. I get that usability dictates only showing the
> > non-default settings on the initial panel, but we could have a ">" button
> > like the "Secure Connection" section does that opens a sub-panel with all
> > the known permissions. Or at the very least pops up the Page Info dialog
> > open to the Permissions tab so people can find it easily.
> 
> I think that is planned in the Permissions revamp.  Aislinn, are we still
> planning to have a subpanel for Permissions that shows even the default
> permissions?

No, we do not show the default we show only non-default. The main panel is the only panel we have for permissions:
https://invis.io/H23WZEK35

If a user wants to change a plug-in permission after it is initially set, they can click the X next to it and they should be asked again when the site requests use of it. The button options in the notification can are currently 'Don't allow' 'Allow' (with a check box saying Always remember).
Flags: needinfo?(agrigas)

Comment 18

9 months ago
Hello, has a more modern way of managing plugins on a per-site basis evolved? I recently upgraded to Firefox 47.0.1, noticed plugin.enumerable_names is gone, and found myself here. But I can't seem to use either of the suggestions I've seen for reducing fingerprint entropy from plugins:

1) In comment 7 of this bug it was advised to set all plugins to "Never Activate" and then manually turn them on for trusted pages. But the Page Info > Permissions dialog doesn't allow me to toggle individual plugins when they're set to "Never Activate." Such an option isn't there.

2) At https://groups.google.com/d/msg/mozilla.dev.tech.plugins/_PsjN5SvZlo/NYyxELgaBwAJ Chris suggested using about:permissions, but when I go there, Firefox says "The address isn't valid." I assume that feature has been removed?

Is there another way to do this now, or is there simply no defense?

Comment 19

9 months ago
In response to #2, it looks like now users have to visit "about:addons", and click the Plugins tab in the left sidebar. For Chrome, users would visit "chrome://plugins/" instead.
(Assignee)

Comment 20

9 months ago
Enumerable, which plugins do you use besides Flash or Silverlight? Bug 1186948 takes a new approach: it will hide Flash from navigator.plugins when it is click-to-play until the user clicks to allow Flash for the current site. Support for NPAPI plugins other than Flash will be removed in Firefox 52 next year.

I'm not sure when or why the about:permissions page was removed. :(

Comment 21

9 months ago
@ChrisAntaki I don't see anywhere in about:addons that would let me activate or de-activate (or enumerate or not) the plugins on a site by site basis. If I go there and set the plugins to Never Activate, per earlier suggestion, I don't see any way to toggle that from site to site. If I set the plugins to Always Ask, they're still enumerable by any website whether I allow that site to use the plugin or not.

@cpeterson In addition to Flash and Silverlight I have the following plugins

Citrix Online Web Deployment Plugin
iTunes Application Detector 1.0.1.1 (disabled)
Java(TM) Platform SE 8 U91
OpenH264 Video Codec provided by Cisco Systems, Inc.
Primetime Content Decryption Module provided by Adobe Systems, Incorporated
VLC Web Plugin
Widevine Content Decryption Module provided by Google Inc.

They all show up in on EFF Panopticon and on amiunique.org and the list of plugins is how both of those derive my unique fingerprint.

Comment 22

9 months ago
@cpeterson:
> I'm not sure when or why the about:permissions page was removed. :(

Maybe someone at Mozilla deemed it "unused", and then removed it?
You need to log in before you can comment on or make changes to this bug.