Closed Bug 952914 Opened 6 years ago Closed 3 years ago
.enumerable _whitelist _URLs to allow enumeration on a few trusted sites
A. is the RFE B. and C. are other ideas (below). See: "disallow enumeration of navigator.plugins" https://bugzilla.mozilla.org/show_bug.cgi?id=757726 This is the code that cloaks plugins, see  below, in 28+. This breaks the 'plugincheck' web site. "Fix plugincheck to not use plugin enumeration" https://bugzilla.mozilla.org/show_bug.cgi?id=938885 This is the bug to 'do the plugincheck without using the enumeration', i.e. to 'fix plugincheck web site'. The US version of 'plugincheck' is at https://www.mozilla.org/en-US/plugincheck/ I am very happy that Mozilla devs are making this change - to disallow enumeration of Plugins. In 28+ the default for the preference "plugins.enumerable_names" is "Java,Nexus Personal,QuickTime,Shockwave". So these plugins are 'still enumerable' by any site. In https://bugzilla.mozilla.org/show_bug.cgi?id=757726#c105 Chris Peterson (:cpeterson) wrote: > * Renamed "plugin.enumerableNames" pref to "plugins.enumerable_names" > * Added special pref value '*' to disable all plugin hiding So if you, via "about:config", change the "plugins.enumerable_names" preference to "*" all sites (including 'plugincheck') can still use enumeration of ALL plugins. Once you have been to the site that YOU want to 'allow enumeration' you can then either 'set it back to default' (right click the line and choose "Reset") or you can browse all sites with 'no enumeration allowed' by choosing the empty string "". I expect that it will take quite a long time for sites to change. It might help if Aurora users browsed with more restricted settings to find sites that have not adapted while still allowing, via a whitelist, access to important (from the user's point of view) sites. I have been inspired by the preference "security.ssl.treat_unsafe_negotiation_as_broken"  which was used by users to 'find sites that we wanted to use securely' and then inform the site Administrators of our desire for them to evaluate RFC 5746 and to mitigate the Renegotiation issue. I ask you to consider a preference that would allow users to specify sites that the users trust, a whitelist, that will allow 'more enumeration than the default'. Preference name: plugins.enumerable_whitelist_URLs Preference values: string URL in pairs, using "#" as a separator between the 'preference for the site' and the URL the preference applies to. Use "##" as separator between the pairs. I'm using # and ## as example separators just to make this RFE easier to understand. Suppose: 1. You want 'plugincheck' to be able to enumerate all plugins. "*" # "https://www.mozilla.org/%LOCALE%/plugincheck/" 2. You want 'example.com' to enumerate 'Shockwave Flash' "Shockwave" # "https://www.example.com" 3. You want 'my slow to adapt Bank' to enumerate Java and Shockwave. "Java,Shockwave" # "https://www.my_slow_to_adapt_bank.com" 4. Set the default, i.e. all the rest of the web, to be 'no plugin enumeration'. In this Example, the "prefs.js" would contain user_pref("plugins.enumerable_names", ""); /* NONE are allowed (the default for 28+ is "Java,Nexus Personal,QuickTime,Shockwave") */ user_pref("plugins.enumerable_whitelist_URLs", "*" # "https://www.mozilla.org/%LOCALE%/plugincheck/" ## "Shockwave" # "https://www.example.com" ## "Java,Shockwave" # https://www.my_slow_to_adapt_bank.com"); Two other ideas: B. Allow Nightly, Aurora and Beta to default to user_pref("plugins.enumerable_names", "Java,Nexus Personal,QuickTime,Shockwave"); BUT change the Preference to "*" on the Release version (18 March 2014) to user_pref("plugins.enumerable_names", "*"); So, the code ships but the 'cloaking is off' (and "Reset" also sets the Preference back to "*"). If you go for option B then make it easy to discover good documentation for this preference and WHY Mozilla are making this change. C. Use "FPDetective" (see ) to search for sites that enumerate plugins. My choice would be 'try option B first' (i.e. don't make the 'whitelist preference' "plugins.enumerable_whitelist_URLs" but do engage with Beta users). DJ-Leith References:  Background Cloaking plugin names to limit browser fingerprinting in Firefox http://cpeterso.com/blog/02013/11/cloaking-plugins-to-limit-browser-fingerprinting/ By Chris Peterson A good introduction to this recent change. Fingerprinting https://wiki.mozilla.org/Fingerprinting Panopticlick tests your browser to see how unique it is based on the information it will share with sites it visits. https://panopticlick.eff.org Fingerprintig is possibly wider than we thought - recent research: Top websites secretly track your device fingerprint http://www.kuleuven.be/english/news/several-top-websites-use-device-fingerprinting-to-secretly-track-users 11 October 2013  PDF of the above research, presented at CCS'13, 4-8 November 2013, Berlin, Germany. "FPDetective: Dusting the Web for Fingerprinters" http://www.cosic.esat.kuleuven.be/publications/article-2334.pdf  Security:Renegotiation https://wiki.mozilla.org/Security:Renegotiation SSL Server Test https://www.ssllabs.com/ssltest/index.html
Severity: normal → enhancement
Component: General → Plug-ins
Product: Firefox → Core
hi DJ: thanks for the suggestions. My patch in bug 952602 would implement your suggestion B: disable plugin name cloaking for Release (and the "late Beta", the last few weeks before Beta is uplifted to Release). As you point out, plugin name cloaking can break some websites, so we will likely need some more test time before this feature is released widely.
> hi DJ: thanks for the suggestions. You are very welcome. It is a pleasure to be able to give a small amount back to all of you at Mozilla. I browse using Firefox. I have been using NoScript (since September 2008) and RequestPolicy (since March 2009) on all my profiles. FYI, if you wish to see more about my use of Firefox see the link in "plugincheck not working in Aurora 28, ONLY Shockwave Flash 'reported on', others are missed" https://bugzilla.mozilla.org/show_bug.cgi?id=951360 pointing to the NoScript Forums at informaction.com On Topic In my view, the key to getting the code 'switched on' is in effective advocacy / web evangelism. I imagine that patch, in bug 952602, which 'disables the cloaking' may well have to be applied to release Firefox 29, 30 etc if web site Administrators are slow to change their 'plugin detection code'. Can I suggest that when bug 938885 lands, and the 'plugincheck web site is now checking plugins without enumerating them', that the advocates blog about this. Please can someone consider updating the Fingerprinting wiki https://wiki.mozilla.org/Fingerprinting to reflect the code changes, the blogs: I'm thinking of both Chris Peterson's blog and the 'proposed blog about the changes to plugincheck' (and possibly also the recent research cited in comment 0). In my (limited) experience with advocating the Renegotiation issue (RFC 5746) I found that having A. an authoritative wiki: > Security:Renegotiation > https://wiki.mozilla.org/Security:Renegotiation B. a live 'test site' to demonstrate the issue: > SSL Server Test > https://www.ssllabs.com/ssltest/index.html helped the Administrators understand and then take action. It would be good to have > easy to discover good documentation for this preference and WHY Mozilla are making this change. I did not find Chris Peterson's very helpful blog post until after I had filed bug 951360. Since then I have also found "Site Compatibility for Firefox 28" https://developer.mozilla.org/en-US/Firefox/Releases/28/Site_Compatibility Perhaps 'links to good documentation' could be posted in the wiki and/or one of the bugs: e.g. bug 757726 or bug 934107 ? DJ-Leith
Thanks for the suggestions, DJ-Leith. I will update the Fingerprinting wiki and investigate Firefox 28 Site Compatibility release notes.
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.