See bug 934107 and bug 757726. For each plugin that the plugincheck knows the current versions of, it should query the specific plugin by name. Iterating over all names won't work anymore. See bug 934107 for code examples.

Plugins whose names include a version number (e.g. "QuickTime Plug-in 7.7.3") can't be queried by names because plugincheck wouldn't know which particular plugin version (past, present, or future!) is installed. For those plugins, the best approach is to query by MIME type name and then check the MIME type object's enabledPlugin property. See bug 934107 comment 3 for an example.

For any plugin it's best to query by MIME type and then double-check that you have the right plugin using the name or other data.

Pmac is pinging espressive to find out which team should take this one.

:espressive do you know if this is an issue with our code, or with the 3rd party plugin check JS?

Spoke to pmac briefly on IRC regarding this. I will look into this and report back ASAP. Just for interest sake, is this a bug we are currently experiencing or, is this something we will run into soon if we do not change the logic? Thanks!

(In reply to Schalk Neethling [:espressive] from comment #5) > Just for interest sake, is this a bug we are currently > experiencing or, is this something we will run into soon if we do not change > the logic? This problem currently affects Nightly 28 because navigator.plugins[] enumeration only reveals Java, QuickTime, Flash, Shockwave, and "Nexus Personal" BankID (a Swedish banking plugin that Plugin Check does not know about).

(In reply to Chris Peterson (:cpeterson) from comment #6) > This problem currently affects Nightly 28 It's up to Aurora 28 at this point and will hit beta Firefox in February (assuming no backout).

See the verbose, currently unconfirmed, bug report "plugincheck not working in Aurora 28, ONLY Shockwave Flash 'reported on', others are missed" https://bugzilla.mozilla.org/show_bug.cgi?id=951360 as a possible example of this. Can I suggest having an "about:config" preference that allows 28+ to specify web sites that are allowed to 'test for plugins'. Example, for GB, the existing https://www.mozilla.org/en-GB/plugincheck/ Example, for testing the "plugincheck" https://www-demo3.allizom.org/b/en-US/plugincheck/

pmac, espressive: ping

Wenzel, why'd you move this back into www.mozilla.org/Legacy? This is a bug with the current Plugincheck JS, and afaik those belong in plugins.mozilla.org(which definitely does need a component rename at this point). This is definitely not a legacy php issue at all, though.

The bug is in the Javascript of the HTML page, not on a server PHP script

Note that this bug fix will require some server side work to make the list of known plugin names and versions available to the JavaScript client.

Could you please point to the relevant source? apparently: http://mozorg.cdn.mozilla.net/media/js/plugincheck-min.js https://github.com/ozten/Perfidies-of-the-Web And server?

(In reply to Andrei Hajdukewycz [:sancus] from comment #12) > Wenzel, why'd you move this back into www.mozilla.org/Legacy? This is a bug > with the current Plugincheck JS, and afaik those belong in > plugins.mozilla.org(which definitely does need a component rename at this > point). If this is the code in question: https://github.com/mozilla/bedrock/blob/master/media/js/plugincheck/check-plugins.js then how is this not a bedrock bug? > This is definitely not a legacy php issue at all, though. Sorry about that. Will you put it into the right subcategory?

From the server side, this should simply return some XML or JSON with the information about all known plugins: display name, technical plugin name, mimetype, icon, download URL, and versions: vulnerable and latest. The rest can happen in JS in the browser. Should be simple to implement, because it's *less* logic on the server.

(In reply to Ben Bucksch (:BenB) from comment #13) > The bug is in the Javascript of the HTML page, not on a server PHP script Agreed. It should therefore be in the www.mozilla.org product. plugins.mozilla.org is just the service that the JS queries for the latest plugin info.

Pmac: is this something for our team to fix? should we add it to the kanban board?

:jbertsch It's been maintained by :espressive. We could possibly take it on, but I know very little about the JS that needs to be fixed.

Thanks, Pmac. Sancus suggested adding a plugincheck component to our www.mozilla.org product for sorting bugs like this.

Sorry for the confusion. This bug requires both client and server side changes, so perhaps two separate bugs should be filed to block this tracking bug? 1. SERVER CHANGES: The server needs to publish the list of known plugins' plugin name, display name, version numbers, URL to plugin install page, and possibly a plugin MIME types. The list could be JSON, XML, CSV or whatever, but JSON would be a JS-friendly good choice. A human-readable list is available here: https://plugins.mozilla.org/en-us Some plugin names include a version number that changes with every release (e.g. "QuickTime Plug-in 7.7.3"), which the client can't use to query navigator.plugins["QuickTime Plug-in 7.7.3"]. If the user might have an old "QuickTime Plug-in 6.0" installed, the plugin won't be found even though it needs to be updated. For those plugins, the published list should include a MIME type that is unique to that plugin so the client JS can find the plugin using navigator.mimeTypes["video/quicktime"].enabledPlugin which is the same Plugin object returned by navigator.plugins["QuickTime Plug-in 7.7.3"]. Example plugin info for a server list: Plugin Name: "Shockwave Flash" i.e. navigator.plugins["Shockwave Flash"].name Display Name: "Adobe Flash Player" i.e. the name displayed to the user on the Plugin Check page Version Number: "11.9.900.170" i.e. navigator.plugins["Shockwave Flash"].version MIME Type: "application/x-shockwave-flash" (though MIME Type is not really needed for this plugin because the Plugin Name "Shockwave Flash" is the same across all version.) Installer URL: <some adobe.com URL> Plugin Name: "QuickTime Plug-in 7.7.3" i.e. navigator.plugins["QuickTime Plug-in 7.7.3"].name Display Name: "Apple QuickTime" i.e. the name displayed to the user on the Plugin Check page Version Number: "7.7.3" i.e. navigator.plugins["QuickTime Plug-in 7.7.3"].version MIME Type: "video/quicktime" Installer URL: <some apple.com URL> However, since plugins other than QuickTime might handle the "video/quicktime" MIME type (e.g. the VLC media player plugin), the client should verify that the plugin returned by navigator.mimeTypes["video/quicktime"] matches the list entry's plugin name. Unfortunately, the plugin names won't match exactly for outdated plugins. This is the "QuickTime Plug-in 6.0" != "QuickTime Plug-in 7.7.3" problem that forced us to use this MIME type workaround in the first place! There are a number of workarounds for fuzzy comparisons of these plugin names, but one option is that the client could use some heuristic to remove any characters that look "versiony" (e.g. numbers 0-9, dots, commas, parens (), and whitespace). For example, plugin name "QuickTime Plug-in 7.7.3" would become "QuickTimePlug-in" and "Adobe Acrobat NPAPI Plug-in, Version 11.0.02" would become "AdobeAcrobatNPAPIPlug-inVersion". 2. CLIENT CHANGES: The client JS needs to replace enumeration of navigator.plugins (because it will no longer return all installed plugins!). Instead, the client should download the server's plugin list, then enumerate the list and query navigator.plugins or navigator.mimeTypes for each plugin. Client pseudocode: function stringWithoutVersionyChars(str) { return str.replace(/[0-9(),. ]/g, ""); } for pluginInfo in serverList { var plugin = navigator.plugins[pluginInfo.pluginName]; if (!plugin) { var mimeType = navigator.mimeTypes[pluginInfo.mimeType]; if (!mimeType) { continue; // plugin not installed } plugin = mimeType.enabledPlugin; if (!plugin) { continue; // plugin installed, but not enabled! } if (stringWithoutVersionyChars(plugin.name) !== stringWithoutVersionyChars(pluginInfo.name)) { continue; // found a plugin, but not the one we were expecting! } } if (plugin.version >= pluginInfo.version) { continue; // plugin is up to date! } alert("FIXME: Your " + pluginInfo.displayName + " plugin is out of date! To update, please visit " + pluginInfo.installerURL); }

> the plugin names won't match exactly for outdated plugins We can just use (first step) mimetype and (second step) name substrings, like your browser whitelisting code does. Substrings can catch any versions without complicated heuristic. The mimetype match is exact and avoids false matches.

(In reply to Ben Bucksch (:BenB) from comment #23) > The mimetype match is exact and avoids false matches. Multiple plugins can handle the same MIME types, so we need to carefully select a MIME type that is unique to a particular plugin. For example, the "video/mpeg" MIME type can be handled by Apple's QuickTime, GNOME's Totem, and VLC plugins. And even the "application/x-vlc-plugin" MIME type is not unique because it can be handled by GNOME's Totem or VLC. :)

Yes, that's what I meant with: > We can just use (first step) mimetype and (second step) name substrings I.e. your algo in comment 22, but replacing: if (stringWithoutVersionyChars(plugin.name) !== stringWithoutVersionyChars(pluginInfo.name)) { continue; } with: if (plugin.name.indexOf(pluginInfo.nameSubstring) == -1) { continue; }

(In reply to Chris Peterson (:cpeterson) from comment #22) > Sorry for the confusion. This bug requires both client and server side > changes, so perhaps two separate bugs should be filed to block this tracking > bug? Just checking in here - has a separate bug been filed for the server side changes that are required here? (I'm not sure who works on this).

Alex: I haven't opened a separate bug for the necessary server side changes. I assumed that whoever worked on this bug would either be familiar with both Plugin Check's client and server code or that they would know developers who work on the other client/server side.

espressive can handle the front end of this, he worked on this last.

We're a few weeks into Beta 28 now - is this one of your top priorities for the coming week or two? What happens (user impact) if this is not resolved before we ship FF28?

We plan to ship the plugin hiding feature in Firefox 29, not 28. This feature is #ifdef EARLY_BETA_OR_EARLIER in Beta 28, so it should shut off automatically before Firefox 28 is released. VarCat is tracking bug 952602 as a reminder to verify that the feature actually gets disabled.

(In reply to Lukas Blakk [:lsblakk] from comment #29) > We're a few weeks into Beta 28 now - is this one of your top priorities for > the coming week or two? What happens (user impact) if this is not resolved > before we ship FF28? This is my *top* priority and will be done before end of week next week i.e. 28 February

For status see https://bugzilla.mozilla.org/show_bug.cgi?id=956905

FF28 is now out and our plugin broke. We have never used enumeration, so this should not have affected us. Based on this comment https://bugzilla.mozilla.org/show_bug.cgi?id=938885#c23, I investigated case sensitivity. It seems that FF28 has internally converted the mime type to all lowercase, and is listed as such in the Add-ons Manager. So navigator.mimeTypes['application/x-MyPlugin'] works in FF prior to 28, but 28 requires navigator.mimeTypes['application/x-myplugin']. Is this intentional or a bug?

(In reply to Bruce Cartland from comment #33) BTW: I'm testing this on Windows Server 2008 R2 Standard SP1. And, yes, to preempt the comment, we probably should have used the form 'my-plugin). Nonetheless, this seems a significant change in behavior.

Bruce: Thanks for reporting this problem. Such a change would not be intentional! When you say "our plugin broke", do you mean when your plugin is embedded in a web page or that your plugin no longer shows up on Mozilla's Plugin Check web page at http://www.mozilla.org/plugincheck? Is your plugin available to the public? Unfortunately, I can't reproduce the bug. I see the same case-sensitive behavior on Firefox 24 (ESR), 27, 28, and 31. If I enter the following commends in Firefox's Web Console, navigator.mimeTypes['application/x-shockwave-flash'] returns the Flash Player's "[object MimeType]" but navigator.mimeTypes['application/x-shockwave-Flash'] (with capitalized "Flash") returns "undefined". I have only tested Mac OS X, so maybe this bug is specific to Windows?

(In reply to Chris Peterson (:cpeterson) from comment #35) > Unfortunately, I can't reproduce the bug. I see the same case-sensitive > behavior on Firefox 24 (ESR), 27, 28, and 31. If I enter the following > commends in Firefox's Web Console, > navigator.mimeTypes['application/x-shockwave-flash'] returns the Flash > Player's "[object MimeType]" but > navigator.mimeTypes['application/x-shockwave-Flash'] (with capitalized > "Flash") returns "undefined". I have only tested Mac OS X, so maybe this bug > is specific to Windows? I guess that's because Flash Player will register lower-cased MIME types from the start. We will need a test plug-in having an upper-cased MIME type to reproduce the issue.

Looks like the case sensitivity issue is fallout from bug 206659, not this bug.

I file bug 985859 for the case sensitivity issue.

(In reply to Masatoshi Kimura [:emk] from comment #36) > I guess that's because Flash Player will register lower-cased MIME types > from the start. We will need a test plug-in having an upper-cased MIME type > to reproduce the issue. Our "second test plugin" in the tree has a cased mimetype.

Shalk, Chris, do you think you will be able to fix this bug for 29? We are in the middle of the beta cycle now. Thanks

I don't the status of Shalk's rewrite of Plugin Check, but I plan to disable the plugin detection change in Beta 29 (bug 952602).

I landed a patch to #ifdef EARLY_BETA_OR_EARLIER the plugin detection changes across all channels, so Plugin Check will continue to work correctly in Release and late Beta for the foreseeable future. https://hg.mozilla.org/releases/mozilla-aurora/rev/6fd2d495a0ca https://hg.mozilla.org/releases/mozilla-beta/rev/c94fa9907075

So, here is what has happened over the last week or so. Last week I was away at a work week and work on plugincheck stopped for this period of time. One positive from this though is that plugincheck was discussed in length during the work week and the challenges, problems and requirements has been clearly outlined as well as, driving home the critical path this is on and, the high value plugin check provides to end users. Something else that happened over the last week is, and this is something I have noticed every time there is a focus on plugincheck, bugs have been crawling out of the woodwork regarding the current live plugincheck. Now, some of this affects the new plugincheck as well but, I believe getting the new plugin check out there for Fx 29+ is more important that continuously going back and reworking things across two 'code basis' because of new/resurrected bug reports making themselves known on bugzilla. With this is mind, I have opened two trackers. One to track work towards getting the new plugincheck out the door in time for the Fx 29 release and the other, to track general bugs/feature requests against the plugincheck service. https://bugzilla.mozilla.org/show_bug.cgi?id=990856 https://bugzilla.mozilla.org/show_bug.cgi?id=990857 To my mind, the new plugincheck should be P1 and everything else P2-. Focus should be to get a version of the new plugincheck released that has feature parity with the current plugincheck, bugs and all. After launch of the initial version of plugincheck.next there can be a unified focus on fixing bugs and adding features to this service and we can stop having to pref off the plugin enumeration bug which is a definite win. I am going to be adding bugs to both the above trackers and invite everyone to do the same, with the knowledge that, bugs/features logged against https://bugzilla.mozilla.org/show_bug.cgi?id=990856 (pc.next) needs to be a blocker for release or else, it will better fit under https://bugzilla.mozilla.org/show_bug.cgi?id=990857

Schalk: with my code changes in comment 42, the current plugincheck site will continue to work correctly with the current and future Firefox release and "late Beta" channels. Only the Nightly, Aurora, and "early Beta" channels will be affected by the plugin enumeration changes. So you do *not* need to rush the new plugincheck service to avoid Firefox 29 breaking the world. But it sounds like you have other good reasons, like to avoid maintaining two plugincheck codebases. :)

Well, Schalk, I am a bit concerned by the number of bugs you opened for 29. We just released 29 beta 4 (yesterday). After beta 8 (April 14th), we will only be accepting critical bug fixes... So, that leave us with a short period of developments + devs. With Chris's change, don't you think we should either plan this change for 30? Thanks

Please note that If the new plugincheck service means string changes on the plugincheck page onwww.mozilla.org, we need those to land into the template asap as we have this page for almost all of our locales. ideally though, I would prefer that any l10n impact on non-Australis prominent pages happen after 29 if possible as we already have a lot on our plate for this release. Thanks

(In reply to Sylvestre Ledru [:sylvestre] from comment #45) > Well, Schalk, I am a bit concerned by the number of bugs you opened for 29. > We just released 29 beta 4 (yesterday). After beta 8 (April 14th), we will > only be accepting critical bug fixes... So, that leave us with a short > period of developments + devs. (In reply to Pascal Chevrel:pascalc from comment #46) > Please note that If the new plugincheck service means string changes on the > plugincheck page onwww.mozilla.org, we need those to land into the template > asap as we have this page for almost all of our locales. ideally though, I So, just to clarify if someone perhaps missed it. The work with regards to plugincheck and the plugincheck service (plugins.m.o) does not in fact touch Firefox' internals or the browser itself and is all self contained outside the browser. The reason the bug indicates Fx 29, is simply because I would personally prefer to have the 'new' plugincheck ready and deployed by the time Firefox 29 is released but, at least with cpeterson change, if for whatever reason we miss this, plugincheck will continue to work.

OK. Thanks for the explanation. I won't track it then.

Sent pull request: https://github.com/ossreleasefeed/Perfidies-of-the-Web/pull/3

As per my comment 35, I can't reproduce Bruce Cartland's plugin problem.

Once this PR lands, it will close this bug: https://github.com/mozilla/bedrock/pull/1997

(In reply to Chris Peterson (:cpeterson) from comment #50) > As per my comment 35, I can't reproduce Bruce Cartland's plugin problem. This is in production \o/ feel free to flip the bits to turn of navigator.plugins enumeration.

Please reopen. Plugincheck is still using enumeration. The closing of this bug might have conveyed that "Fix plugincheck to not use plugin enumeration" had happened, it has not. See bug 956905 comment # 148 onwards. From May 2014: Release (and older version of Firefox) has been using enumeration and the 'dynamic URLs'. Beta + (as I write Fx 35, Fx 36 and Fx 37) uses the 'JSON List' (from bug 956905). In particular I was, using Aurora, able to set "plugins.enumerable_names" set to "" (empty string - i.e. do NOT enumerate ANY plugin) A Plugincheck test then assessed all of the Plugins that were installed THAT WERE ALSO IN THE 'JSON List'. Those plugins that were not included in the 'JSON List' became 'not reported on at all'. That is, they were NOT "unknown". This test was to prove that the 'Plugincheck Website' was working WITHOUT plugin enumeration - the goal of this bug. Using Release I had to set "plugins.enumerable_names" set to "*" (enumerate all plugins) to get any Plugincheck report. This had been 'normal and expected' since bug 757726 "disallow enumeration of navigator.plugins" landed in Fx 28. Release has had "plugins.enumerable_names" set to "*" as the default. My impression, in May 2014, was that the overall aim was to 'get everything working using the JSON List' and then ONLY use the 'JSON List' (and stop plugin enumeration when doing a Plugincheck, stop using the 'dynamic URLs'). My impression, in recent weeks, is that 'development is stalled because Mozilla do not have enough people to complete this'. Since 2014-11-24 (bug 1020133 comment # 85) I have had to allow enumeration (i.e. set "plugins.enumerable_names" set to "*") on ALL versions of Firefox in order to get a report. Or, for example, if I only wanted to report on Flash set "plugins.enumerable_names" to "Shockwave" So, the 'Plugincheck Website' is STILL using enumeration (NOW for ALL versions of Firefox). It is also still using the 'dynamic URLs' for Release and older. These 'dynamic URLs' have the form > https://plugins.mozilla.org/pfs/v2?appID= ... ... They do seem, to me, to be 'part of the "Plugin Finder Service" that is due to be retired! See bug 956905 comment # 149 - it would be good to CONFIRM That the PFS is NOT needed for Plugincheck - I have doubts about this. On Beta + the 'JSON List' is the 'communication channel' between the 'Plugincheck Database' and the 'Plugincheck Website'. Changing the data in the 'Plugincheck Database', which is a 'normal and expected event' when plugins are found to be "vulnerable" can lead to the 'Plugincheck Website' NOT using the fresh data for DAYS. Sometimes the 'JSON List' gets the fresh data to the 'Plugincheck Website' in TWO days. We have seen the 'dynamic URLs' taking SIX days to get the fresh data to the 'Plugincheck Website'. See Bug 1117195 "After updating the Plugincheck Database the Plugincheck Website should use the new data within Minutes NOT Days". DJ-Leith

:espressive, is more work to be done here, as comment #53 indicates, or is there another open bug tracking the remaining work to eliminate plugin enumeration in plugincheck?

(In reply to Josh Mize [:jgmize] from comment #54) > :espressive, is more work to be done here, as comment #53 indicates, or is > there another open bug tracking the remaining work to eliminate plugin > enumeration in plugincheck? I have been of this project for the last 2-3 months. It has however back on my list of projects for this quarter and a lot of the focus will be to remove the need for enumeration in Firefox.

Please reopen - again (I think the closing, on 2015-04-09, was accidental). Plugincheck is still using enumeration. The closing of this bug might have conveyed that "Fix plugincheck to not use plugin enumeration" had happened, it has not. From comment # 53: > Since 2014-11-24 (bug 1020133 comment # 85) > I have had to allow enumeration (i.e. set "plugins.enumerable_names" set to "*") > on ALL versions of Firefox in order to get a report. > Or, for example, if I only wanted to report on Flash > set "plugins.enumerable_names" to "Shockwave" This definitive test still shows that you have to allow enumeration of your plugins for the 'Plugincheck Service' to report on your plugins. DJ-Leith

DJ, It is indeed extremely weird that you have found this to be the case. Unless you have tested this before it actually went live, which I doubt as I only closed this after or, you have an older version stuck in cache or, even more unlikely, we only enabled it for en-US, there is no way you should still need to enable that. Other than the call to navigator.plugins.refresh() (which we actually might not need anymore), there is nothing using that for plugin detection and everything is done via navigator.mimTypes as can be seen here: https://github.com/mozilla/bedrock/blob/master/media/js/plugincheck/lib/plugincheck.js#L229

mimTypes? I of course mean mimeTypes :)

From comment # 57: > ... we only enabled it for en-US ... Minor point in passing, the en-GB Plugincheck is redirecting to en-US, and has been since late March 2015. See bug 1153448 "L10N Plugincheck, locale missing, en-GB has become en-US" Back to the main point, from comment # 56: > Please reopen - again (I think the closing, on 2015-04-09, was accidental). > > Plugincheck is still using enumeration. You doubt this but have you tested? I did all tests, in April 2015, on the en-US version of Plugincheck: https://www.mozilla.org/en-US/plugincheck STR Windows 7 64bit OS, Firefox 37 Release (32bit), en-GB. 1. Fresh profile. Do not add ANY Addons. As the Plugins are 'machine wide' I have several that I can test. 2. Start Firefox, get first run etc. 3. Close Firefox. Repeat 2 and 3 several times (to finish 'first run / fresh Firefox profile'). I did steps 1-3 today to eliminate any of my Addons from confounding the tests. All my 'normal tests', previously reported in Bugzilla, have been on 'test Profiles that have been in use for months'. 4. Visit https://www.mozilla.org/en-US/plugincheck The way a 'User is expected to do this' is: in "about:addons", at the top of the "Plugins" Tab. If you 'click the link' "Check to see if your plugins are up to date". The will be redirected to: https://www.mozilla.org/en-US/plugincheck/?utm_source=firefox-browser&utm_medium=firefox-browser&utm_campaign=plugincheck-update All your plugins will be tested and reported on BECAUSE all your plugins are being enumerated. 5. In "about:config" search for "plugins" and modify "plugins.enumerable_names" from the default "*" which means 'enumerate all plugins' to "Shockwave" which means 'test my Flash plugin' in this context. 6. Do another Plugincheck. ONLY Flash will be 'tested and reported on'. 7. Modify "plugins.enumerable_names" to "" (empty string). 8. Do another Plugincheck. Now, because NO plugins are being enumerated, NO tests are done and NO 'results are shown'. I have been, since May 2014, documenting this as a test of 'Plugincheck without ANY enumeration'. From May 2014, using 'Aurora and the JSON List' (NOT the PFS v2 [AKA 'dynamic URLs'] – that were used in the 'Plugincheck for Firefox Release', from May 2014 onwards) I was able to do 'Plugincheck without ANY enumeration'. This STOPPED WORKING, as I said in comment # 53, on 2014-11-24. I reported this change on 2014-11-25. See bug 1101613 comment # 3 where I said: > 2. Have to enumerate plugins to get ANY result. > > Previously, since May 2014, I have deliberately tested > 'new Plugincheck - uses the JSON List' with > "plugins.enumerable_names" set to "" (empty string) - NO enumeration. > ALL Plugins, in the JSON List, were reported. > There were NO "unknown" reports. > As you know, I think the "unknown" report is very useful. > > Now, since bug 1020133 comment # 85 > I have had to have set > "plugins.enumerable_names" to "*" (all plugins are enumerated at Plugincheck) > to get ANY version of Firefox (I have spoofed UAs from Fx 31 through to Fx 36) to > 'see a result' on LIVE. > > So, to see the screenshot > "Fx-33-1-1-Google-Earth-NOW-UNKNOWN-2014-11-25.png", attached to this comment, > I had to set "plugins.enumerable_names" to "*". > > If I set "plugins.enumerable_names" to "shockwave" only Flash is reported > (expected if 'enumeration is required at Plugincheck'). > > This was the point I was trying to make in bug 1102198 comment # 3: > the attached screenshot illustrates that comment too. There is a typo in the above quote: "Shockwave" has to be capitalised. So, I agree with Schalk when he said, in comment # 55 > ... and a lot of the focus will be to remove the need for enumeration in Firefox. that, in my words, "enumeration of plugins is still REQUIRED to do a Plugincheck". The goal of this bug is "Fix plugincheck to not use plugin enumeration". While looking back to November 2014 I see a Bedrock pull request mentioned in bug 1102198 (one of the bugs quoted just above). On STAGE I had to use enumeration, for the first time since May 2014, on 2014-10-20. This might be a place to start looking for the 'need for enumeration', and the change I noticed on 2014-11-25 on the LIVE Plugincheck. Looking to the future, my personal point of view is: IDEAL "Fix plugincheck to not use plugin enumeration", this bug. 2nd Choice 'Use a whitelist' - for sites where the User allows plugin enumeration. Bugs have been proposed for this including: Bug 966030 "Implement navigator.mozAppDetails and expose the property on white-listed domains" Proposed, by Kohei Yoshino, on 2014-01-30. Bug 952914 "RFE: plugins.enumerable_whitelist_URLs to allow enumeration on a few trusted sites" Proposed, by DJ-Leith, on 2013-12-23. 3rd Choice Report "unknown" plugins providing the User allows plugin enumeration. This is what we have had since 2014-11-24. I personally browse with "plugins.enumerable_names" set to "" and I sometimes change this to "Shockwave" (for some sites). For a 'Plugincheck test' I change it to "*" and then reset it back to "". 4th Choice Don't report "unknown" plugins, only report if the plugin is in the 'JSON List'. 3rd Choice is MUCH better than this. DJ-Leith

Quick question. I know plugin enumeration is not currently turned off but, there is a config option I can set to spoof that it is. What is that setting again?

The plugin enumeration restriction (feature and prefs) was removed in bug 1169945. It broke too many websites. The theoretical benefit to reduce plugin fingerprinting did not outweigh the website breakage and the time to reach out to all the broken websites. :( You can resolve this bug as WONTFIX, if you like.

Oh heck, I was not aware of this ;( Ok, will close it for now, but if this comes up again, please feel free to reopen.