Closed Bug 1169945 Opened 9 years ago Closed 9 years ago

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

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox41 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla41
Tracking Flags:
Tracking Status
firefox41 --- fixed

People

(Reporter: cpeterson, Assigned: cpeterson)

References

Details

Attachments

(1 file)

remove_plugins-enumerable_names.patch
19.90 KB, patch
benjamin
: review+
Details | Diff | Splinter Review 
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+
https://hg.mozilla.org/mozilla-central/rev/882f1779b4d8
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox41: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Blocks: 990808
Blocks: 1009117
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/
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.
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?
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.
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."
(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".
Great, thanks for the tip
@cpeterson, would you recommend a venue where we could request this setting be brought back, in at least a Boolean form? (Default value or "")
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
Thanks, I'll start a discussion there!
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)
(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)
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?
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.
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. :(
@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.
@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?
Here's how to view and manage site-specific permissions (at least in Firefox 56):

As Daniel mentioned in comment 15 you can open Page Info (he called it "door hangar") by clicking on the Lock or Globe icon.  It is just to the left of the site's web address.  Then click on the "Permissions" tab in the Page Info window.

Another way to open "Page Info" is right-click on an empty space in the web page you are viewing and select "View Page Info" from the shortcut menu that appears.

So browse to the website first, then go to Page Info -> Permissions.

However, there are issues with site-specific permissions.

Sometimes they are not saved or not persisted between sessions as noted in bug 1263209.
The cause seems to be an internal issue related to when sqlite3_config is called, tracked in bug 730495.
Permissions are stored in permissions.sql which is an SQLite database.
Bug 730495 has recently been marked as RESOLVED/FIXED and seems to be slated for the Firefox 58 release.

Another issue is that when a plugin is set to "Never Activate" as the default for all sites when that plugin does not show up in the site-specific Permissions tab, so it can't be adjusted to "Allow" for a specific site.
Last line of previous comment should have read: 
Another issue is that when a plugin is set to "Never Activate" as the default for all sites then that plugin does not show up in the site-specific Permissions tab, so it can't be adjusted to "Allow" for a specific site.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: