Closed ckerr closed 8 years ago
Thanks for the link. The bug summary states:
Remove unused plugins.enumerable_names whitelist that hides plugins from navigator.plugins enumeration
If my understanding is correct, I think this is bad news because it opens us once more to plugins-fingerprinting. Plugins and Fonts enumerations were the top two greatest fingerprinting threats used in the EFF's Panopticlick test. Mozilla even pointed out the need to reduce this threat in its response.
I've had plugins.enumerable_names=""
in about:config
for a few months and I've yet to run into a website that I cannot consume.
If Mozilla feels it has to allow enumeration, it would be a good idea to at least randomize the order in which the plugins are published, and to omit the minor version information. So instead of Flash 18.0.0.3
, just Flash 18
Thanks for the bug report @charlesk :+1: . I'll see if there is something I can do on the script injection front to try to deal with this .
I can confirm that on my instance of Firefox 41, the plugins.enumerable_names
setting doesn't do anything anymore. The Panopticlick test can once again fingerprint my plugins.
I dont know why, but there is a 2 year old firefox addon that actually still blocks plugin enumeration. Maybe the source code can be used to make this feature work in ras as well. (I must add that I stopped using this addon because it broke a lot of websites)
FF ESR 38 still supports it, for a quick workaround.
I have removed this preference from the addon since the next ESR will not be able to use it. If I find a workaround I will add it under the script injection section.
Object.defineProperty(navigator, "plugins", {value: []});
Source: https://bugzilla.mozilla.org/show_bug.cgi?id=757726#c151
@Mechazawa Nice find! @dillbyrne Would this work?
For plugins a site white list would be great since for example the gnome shell plugin is only used on their extensions website.
@Mechazawa Thanks :+1: . I have not had a chance to try out the code yet but I intend to submit 0.9.5.4 to addons.mozilla.org by the end of this week to get a full signed version on AMO. After that is done I will test this code and if it works I will add it and a whitelist option for it too.
@RoxKilly It looks like it should. I'll update this when I've had a chance to test it.
Long time user, first time poster.
Does the Mechazawa fix work and if so will it be in the next version?
I'm still using FF 40.2 specifically because plugin.enumerable_names setting was removed in FF 41.
Thank you dillbyrne for a brilliant and vital addon, couldn't imagine surfing the net without it.
When FF moves to WebExtenstions I will stick with older FF versions specifically so I can use this addon, hopefully the profiles can be kept current.
@sueridgepipe I built a small userscript so you can try it out
// ==UserScript==
// @name Disable plugin enum
// @author Mechazawa
// @namespace pluginenum
// @description Disables plugin enumeration
// @license WTFPl
// @version 1
// @include *
// @run-at document-start
// @updateURL https://raw.githubusercontent.com/Mechazawa/Firefox-plugin-enum-disable/master/DisablePluginEnum.user.js
// @grant none
// ==/UserScript==
Object.defineProperty(navigator, "plugins", {value: []});
How do I run this?
@sueridgepipe On Firefox:
Use script from clipboard
at the bottom of the new window (this button will show only if you copied the script to your clipboard in step 2) This will cause Greasemonkey to run the script on every page. To test, make sure you have a plugin installed such as Adobe Flash Player (not the same as extensions) and go to https://panopticlick.eff.org/. Run the test before and after you add the User script to Greasemonkey to see whether your plugins can still be detected.
I have just run my own test and I have the same result as @Mechazawa - effective protection. Below are the results of the panopticlick test on browser plugins:
Without the user script:
With the user script:
@dillbyrne please take notice of this. It should probably be a script injection option in RAS
Thanks RoxKilly.
I'm still on FF 40.2 with plugin_enuerable_names set to "" so this script is redundant on my system, but very useful when I eventually upgrade.
Agree with RoxKilly, this should also be integrated into RAS to replace the old plugin enumeration option.
wow nice job people! you can also do this via noscript's surrogates if you have noscript installed. just make these entries in about:config:
noscript.surrogate.noplugin.exceptions
= `
noscript.surrogate.noplugin.replacement=
Object.defineProperty(navigator, "plugins", {value: []});
noscript.surrogate.noplugin.sources=
@^https?://`
edit: more info @ https://hackademix.net/2011/09/29/script-surrogates-quick-reference/
How would I quickly enable/disable the noscript.surrogate trick? Problem is that some websites do not work when plugins cannot be detected. For plugins.enumerable.names I had created a PrefBar radio button.
You're right, some sites no longer work. I have the script installed as a Userscript (see my post from Jan 9 2016) instead of a NoScript surrogate. Disabling a userscript with Greasemonkey
is easy: when I come across a site that was broken, I click the Greasemonkey dropdown (in the browser toolbar), uncheck the script and refresh the page. When I'm done with that site, I recheck the script.
For a longstanding solution, you could select Manage User Script
from the Greasemonkey dropdown options, and add the broken site to the Excluded pages
section of the options for that script. From then on, the script will not run on that domain, but will still protect you everywhere else.
@danielcra u dont disable it. you add your sites to the exception list noscript.surrogate.noplugin.exception
I understand; that works for sites I visit regularly. But when I search the web, I often scan over sites at seconds intervals. Going into about:config just to have a quick look at some rubbish is not a workable solution.
Well the 1st way i mentioned is 2 clicks. Open a dropdown, and click to toggle the script on/off.
@RoxKilly Does Greasemonkey have any conflicts with NoScript?
@Wannabe-Programmer I don't know. I don't use NoScript.
Greasemonkey needs JS enabled.
@berrythesoftwarecodeprogrammar Hello,
jscher2000 or "Jefferson Scher" added mimeType protection see here: https://greasyfork.org/en/scripts/18256-hide-all-plugins If the link is down 🎱:
// ==UserScript== // @name Hide All Plugins // @description Shows empty navigator.plugins and navigator.mimeTypes collections to selected websites // @author Jefferson "jscher2000" Scher // @namespace JeffersonScher // @copyright Copyright 2016 Jefferson Scher // @license BSD 3-clause // @include http* // @Version 0.5 // @grant none // @run-at document-start // ==/UserScript== // See: dillbyrne/random-agent-spoofer#283 (comment) Object.defineProperty(navigator, "plugins", {value: []}); Object.defineProperty(navigator, "mimeTypes", {value: []});
I copied the mimeType value from his script and edited your @berrythesoftwarecodeprogrammar noscript surrogate to include mimeType:
noscript.surrogate.nomimeTypes.exceptions = noscript.surrogate.nomimeTypes.replacement = Object.defineProperty(navigator, "mimeTypes", {value: []}); noscript.surrogate.nomimeTypes.sources = @^https?://
noscript.surrogate.noplugin.exceptions = noscript.surrogate.noplugin.replacement = Object.defineProperty(navigator, "plugins", {value: []}); noscript.surrogate.noplugin.sources = @^https?://
The NoScript surrogate way is the only way to get exceptions to work, exceptions will not work with the UserScript. I have tried. This is useful for folks whom don't want to enable privacy.resistFingerprinting because I have read it has caused problems in the past. (Unsure if this is still the case, I am also unsure if it included hiding/spoofing mimeTypes as part of privacy.resistFingerprinting's feature.)
I have no idea if webextension userscript managers are capable of changing these specific values any more, I'm using the last XUL/XPCOM GreaseMonkey, it can apply stuff to pretty much anything in the browser, using Waterfox here, at least for now. I'm also not sure if NoScript's surrogates for these values will have any effect as a webextension in the future, but I thought I would post this anyway. 🔎 🌵 😀 😅
Edit: changed @include to "// @include http*" in userscript paste, if installing from greasyfork, you will need to change it as well.
This has changed because Firefox removed the "plugins.enumerable_names" feature in FF 41.
As https://bugzilla.mozilla.org/show_bug.cgi?id=1169945 says, "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."
Ideally RAS would circumvent this query/response so that plugin information can be hidden again.