990808 - Add more plugins to our navigator.plugins enumeration whitelist (plugins.enumerable_names pref)

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Chris Peterson [:cpeterson]]

Bug 952602 added #ifdef EARLY_BETA_OR_EARLIER to disable bug 757726's plugin enumeration cloaking before release. If we would like to remove the #ifdef and actually ship this feature, we will probably need to whitelist enumeration of plugins for known broken websites. Currently, the list of broken sites using plugins that are not already whitelisted is:

 * ACE Stream plugin for torrent video site (bug 965493)
 * Garmin plugin for uploading GPS device data (bug 972052)

We should also consider whitelisting enumeration of all plugins that Chrome supports to avoid cases where a plugin website is broken in Firefox but works correctly in Chrome. The list of Chrome's supported plugins:

https://support.google.com/chrome/answer/142064

 * Adobe Flash Player (already whitelisted)
 * Adobe Reader
 * Java (already whitelisted)
 * Windows Media Player
 * Real Player
 * QuickTime (already whitelisted)
 * Microsoft Silverlight

Comment 1

[Chris Peterson [:cpeterson]]

Attachment: plugin-enumeration-whitelist.patch

This plugin "cloaking" feature landed in Nightly 28 (bug 757726) in November 2013 and rode the trains to Beta 28, where we held it for additional testing. To my surprise, we only received a few bug reports about broken plugin sites.

This patch:

1. Removes #ifdef EARLY_BETA_OR_EARLIER from the navigator.plugins enumeration cloaking so this feature will actually ride the trains to release with Firefox 31 (or 32). Firefox 31 will be the next ESR and live until late 2015, so I'd prefer to enable this feature that release to restrict plugin enumeration for all Firefox users in 2014.

2. Adds more plugin names to the enumeration whitelist to fix known broken sites:

 * Garmin Communicator, GPS device sync (bug 972052)
 * ACE Stream, torrent video player (bug 965493)

3. Adds the plugin names supported by Chrome so if/when we break a plugin site, it is a site that would not work with Chrome. This avoids the risk of Firefox users switching to Chrome because of sites using broken plugin detection.

 * Adobe Acrobat (includes Adobe Reader)
 * Microsoft Silverlight
 * RealPlayer
 * Windows Media Player

Comment 2

[Chris Peterson [:cpeterson]]

Comment on attachment 8411635 [details] [diff] [review]
plugin-enumeration-whitelist.patch

Adding johns as a second reviewer because this is could be a risky change to Firefox's plugin compatibility.

Comment 3

[Benjamin Smedberg]

Comment on attachment 8411635 [details] [diff] [review]
plugin-enumeration-whitelist.patch

I don't think this is expansive enough without further vendor input. See details from bug 990069 and 990067 for the Lync and Skype plugins.

Comment 4

[Chris Peterson [:cpeterson]]

Comment on attachment 8411635 [details] [diff] [review]
plugin-enumeration-whitelist.patch

Perhaps we should auto-whitelist enumeration of plugins that are in our click-to-play whitelist?

btw, I have been watching the click-to-play whitelist bugs and emailing each reporter about the plugin enumeration changes, including the reporter for the Lync and Skype plugins.

Comment 5

[Manfred Kellermann]

Please add "Authorware" (Authorware Web Player 2004 Plugin, Adobe) to the navigator.plugins enumeration whitelist! 
We are in the process of converting our software to Flash/Html5 and need some time doing this!

Comment 6

[Georg Fritzsche [:gfritzsche]]

This is not the right bug to file plugin whitelist applications for exceptions from click-to-play.
The process is outlined in [1], which contains a link to the template for filing whitelist bugs.

[1] https://wiki.mozilla.org/Plugins/Firefox_Whitelist

Comment 7

[Georg Fritzsche [:gfritzsche]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #6)
> This is not the right bug to file plugin whitelist applications for
> exceptions from click-to-play.

I'm assuming that you are probably interested in the click-to-play whitelist as you talk about converting to Flash/HTML5 - is that correct?

Comment 8

[Manfred Kellermann]

 >I'm assuming that you are probably interested in the click-to-play whitelist as you talk about converting to   Flash/HTML5 - is that correct?

Yes exactly, I don't want the Authorware Plugin to be added to the Firefox plugin whitelist, I only want it to be added to the plugins enumeration list (click-to-play whitelist)!

Comment 9

[Georg Fritzsche [:gfritzsche]]

(In reply to Manfred Kellermann from comment #8)
> Yes exactly, I don't want the Authorware Plugin to be added to the Firefox
> plugin whitelist, I only want it to be added to the plugins enumeration list
> (click-to-play whitelist)!

I don't understand:
Do you want for your plugin to to not get click-to-play prompts etc.?
Or do you want it to be in navigator.plugins so that you can find it when e.g. going through navigator using a for-loop (which this bug is about)?

Comment 10

[Manfred Kellermann]

It would be sufficient if the Authorware plugin would appear in the variable "plugins.eumerable_names" (navigator.plugins), so that the javascript can find it using a loop. Click-to-play or not doesn't matter.

FYI: Our modules are distributed over D, A, CH, and we no longer have access to the files and therefore can not change the javascript plugin detection. Until we have ported all modules to Flash/HTML5, it will still take some time and it would be nice if the modules would keep running in Firefox.

Comment 11

[Georg Fritzsche [:gfritzsche]]

(In reply to Manfred Kellermann from comment #10)
> It would be sufficient if the Authorware plugin would appear in the variable
> "plugins.eumerable_names" (navigator.plugins), so that the javascript can
> find it using a loop. Click-to-play or not doesn't matter.

Ah, thanks for the clarification! I was getting confused by the mention of the HTML5-transition.

Comment 12

[Chris Peterson [:cpeterson]]

(In reply to Manfred Kellermann from comment #10)
> It would be sufficient if the Authorware plugin would appear in the variable
> "plugins.eumerable_names" (navigator.plugins), so that the javascript can
> find it using a loop. Click-to-play or not doesn't matter.

Manfred: I filed bug 1009117 for the Authorware issue you reported. Can you please copy/paste the information about Adobe's Authorware plugin from Firefox's about:plugins page into bug 1009117? I will need that information to add Authorware to our plugins.enumerable_names whitelist.

Comment 13

[Chris Peterson [:cpeterson]]

The plugins.enumerable_names feature was removed in bug 1169945.