New PluginCheck Page Needs Your Help

Following up on the Flash Detection on the What’s New page, we are developing an upgrade to the Plugin Finder Service (PFS2).

We could use your help! Please hit our testing server’s Plugin Check. We will be able to capture information about plugins and help fill-out the PFS2 database. See an issue? Look through current bugs and leave feedback in Bugzilla.

Screenshot of plugin detection

Screenshot of plugin detection

If you’re a Plugin Vendor, please put the version of your plugin into the name or description field of your plugin. For example, since they don’t expose this information, the following very popular plugins cannot have their minor versions accurately detected in Firefox with JavaScript alone:

  • Adobe Acrobat
  • Windows Media Player Plug-in
  • RealPlayer (on Mac only, Windows exposes version information)

Some plugins don’t expose a good version number in the description, but can be detected by instantiating the plugin. We’re using Eric Gerds’ PluginDetect for this type of plugin.

On the other hand, kudos go to Microsoft’s Silverlight team for the following information: name=”Silverlight Plug-In” description=”3.0.40818.0″. That’s exactly what we need to identify when a Plugin has fallen out of date.  If a vulnerability is discovered and published against 3.0.40818.0, we can alert the user to pick up the newest version.

It’s very fast and easy for us to detect your release version, when the proper information is provided by the plugin. Doing so is a win for you and your users. We’ll be encouraging Firefox users to keep their plugins updated to the latest and greatest. This means better distribution and lower support costs for you. We’re contacting many vendors right now to make this happen.

Firefox 3.6 is going to be adding enhancements to the way Plugin information is exposed to JavaScript. We’re looking forward to how this will simplify this task.

Interested in the code under development? Check out PFS2 server, PFS2 client and of course where it will eventually live.

Update 10/3 @12:50 PDT: Thanks to everyone who has filed bugs! Additionally, here is the list of Plugin states, copy, and links. This is going to change, based on your feedback, but I think it will help the discussion.

Status Copy Button Link
Unknown Plugin N/A we don’t display anything N/A N/A
Current You’re Safe Learn More Vendor URL
Old or Unknown Release Potentially Vulnerable Update Vendor URL
Old with Known Exploit Update Now Vulnerable Vendor URL
Current with Known Exploit Vulnerable No Fix Disable Now #disable-now

I think the consensus is that the copy for Current and Old send the wrong message.

33 responses

  1. Arc wrote on :

    The “PFS2 server” link is broken, also the SSL certificate for the testing page is for the wrong domain.

    By the by, out of curiosity I tested in some other browsers and Chromium, as expected, showed nothing in the list on the other hand testing in Opera it said I had DivX 6.0 installed. I only have Flash 10 installed.

  2. Jesse Ruderman wrote on :

    It’s unfortunate that we’re saying “potentially vulnerable; you should update” when in fact we can’t tell what version is installed.

  3. rich wrote on :

    when i try to access the site, all i get is the following message: uses an invalid security certificate.

    The certificate is only valid for *

    (Error code: ssl_error_bad_cert_domain)

  4. Michael Lefevre wrote on :

    “Since they don’t expose this information, the following very popular plugins cannot have their minor versions accurately detected in Firefox”

    I presume seeing as you’ve mentioned it here, there is no point in filing a bug on that (or is there one that I didn’t see?). But as Jesse already said, if the page cannot tell whether the plugin is up to date or not, then it seems obvious that people should not be instructed to update.

    Also, for current plugins, the “Learn more” label for the links is wrong – those links don’t tell you anything useful, they just offer you a download (which would be pointless).

  5. alanjstr wrote on :

    Well, I got a warning about an insecure SSL cert when I visited. Then I had to tell NoScript to allow googleapis. Beyond that, it did detect my plugins just fine.

  6. Wil Clouser wrote on :

    I agree with both comments above. Also, I’m told to update this plugin:

    DivX® Web Player version

    but when clicked the Update button does nothing and the has no href.

  7. Dan wrote on :

    Pssst your plugin check page’s server has an invalid SSL cert for that domain.

    And yeah I agree with Jesse; right now it looks like it’s saying “you’re out of date”, when it really should say “Not detectable, please check this link to see if you’re up to date” or something.

    Also the page seems to work fine in Chrome FYI.

  8. pd wrote on :

    Why is this a separate page instead of built into the Add-ons manager? Would that be too consistent!?

  9. fsync wrote on :

    “This Connection is Untrusted” when I try to hit the test server. This just means you haven’t gotten a separate cert for that server, right?

    Technical Details: uses an invalid security certificate.

    The certificate is only valid for *

    (Error code: ssl_error_bad_cert_domain)

  10. pd wrote on :

    the Plugin Check page has an invalid https certificate. Firefox blocks it unless user’s manually add an exception.

    Not the best way to ask for help but an oversight I’m sure 🙂

  11. morgamic wrote on :

    Thanks all, it’s a stage site w/ a self-signed cert. Certainly wouldn’t launch something in production with a self-signed cert.

    @pd – Yes, the plan for 3.6 is to use some of the underlying check code and the server-side components to integrate with the client. Left with the option to wait until then versus creating a web version of the detection library, we opted to go with this web campaign — especially given the # of crashes coming from plugins combined with the recent increase in security concerns surrounding plugins.

  12. morgamic wrote on :

    @Jesse – agree, we have talked about collapsing the status and action columns, removing the header, and changing the messaging for unknown plugins (plugins the server does not recognize). “potentially vulnerable” is misleading and we’ll likely scratch that as a state.

  13. morgamic wrote on :

    @Arc – is the PFS2 link; fixed in the post — thanks.

    @clouserw – Missing href is likely missing plugin data in the pfs2 database or it’s a bug. Will look into it.

  14. Justin Dolske wrote on :

    I’d also echo Jesse’s concern… Ideally we should just say something like “safe, but newer version available.” If we just don’t know (vendor vague about versions/security?) then at least explain the situation.

    I think it would also be very helpful to have short names for common plugins… EG “Windows Media Plater Dynamic Link Library” –> “Windows Media Player”, “RealPlayer blah blah blah” –> “RealPlayer”. I don’t think the vendor-supplied description is very useful either (but feel free to put our own strings there, the general format is ok).

    I’d also nuke the column headers (“Plugin Details” / “Status” / “Action”) and vulnerability count. The format is self-explanatory, and you’re going see the big red buttons long before the tiny “x of y plugins vulnerable” text. Actually, I’d just replace that stuff with a single-line summary saying “Everything’s A-OK!” of “You’re insecure, please update immediately”. Perhaps this phrasing should also be explicit about the fact that it’s a dynamic page that’s scanned your installed plugins, lest someone think it’s just a static/generic list for downloading plugins?

    The page doesn’t seem to work in Safari (didn’t check IE), seems like this would be a good resource for any browser.

    “Checking with Mozilla HQ to check your plugins” is a little redundant and repeats itself. 🙂

    Anyway, fantastic overall! Can’t wait for this to be life, it’s clearly a good thing for web security. Kudos!

  15. Justin Dolske wrote on :

    One other random thought — we’re finding that a lot of Firefox crashes are due to buggy 3rd part software, including plugins. Might want to think about how that affects this page (a specific version may be perfectly safe, but very buggy).

  16. jmdesp wrote on :

    The cert is *not* self-signed, it’s issued by equifax. The problem seems to be that doesn’t match *, probably would be all right.

  17. David Illsley wrote on :

    On Snow Leopard, I’m getting a warning about QuickTime Plug-in 7.6.3 being potentially vulnerable, but I can’t install QuickTime 7.6.4 because I have QuickTime X installed. What’s the right thing to do? I can’t see a QuickTime X plugin, but presumably QuickTime files won’t work without a plugin?

  18. Ken Saunders wrote on :

    Nice work. QuickTime was out of date so thanks to the Firefox team for the cool new toy.

    Perhaps other than a Firefox user not knowing that a Firefox plugin is out of date, they just don’t want to install a whole new media player (plus the other crap that is being pushed) that they never use just to update a plugin that they rarely to never use. It’s a major hassle, but I know that I have to update the plugin. Most wouldn’t bother. Can’t I just update the browser plugin?

    I’m considering just uninstalling QuickTime altogether. I already avoid using it on the Internet and have used it on my system less than 5 times since January when I got this PC and installed it. After all, what am I really missing by not viewing content formatted for QuickTime only anyway?

    I’m tired of carrying around a janitor’s set of keys everywhere I go on the Internet because of the use of so many different formats.
    It makes Mozilla’s mission mine too.

  19. Nickolay Ponomarev wrote on :

    This is great! Some comments:

    1) “Instead of closing the browser after each Plugin installation, complete all recommended updates and then restart your browser.” – This is not how at least Flash installation works – they make you close the browser during installation. So this is just confusing.

    2) The page restarts plugin detection when you go to another page, then click “back”. This makes it feel slow.

    3) I don’t understand what’s about the plugins that are not in the DB(?). I have many more plugins than Flash and QuickTime, yet the page only displays those two (and not, say, googletalkbrowserplugin.plugin). The unknown plug-ins may be insecure or even unwanted by the user. I think it makes sense to list them in a separate section, perhaps suggesting to disable them if the user doesn’t know where they came from.

  20. ozten wrote on :

    @Justin – This is a good point. Part of the goal is to keep users plugins updated. We hoping newer versions of plugins will be less crashy, but of course this won’t always be true. For the most commonly installed plugins we can work with vendors to fix specific crash cases on their current release, by having more of our users staying up to date. I don’t think we can make a quality call version by version though… Security trumps crashiness.

    @David – We hide unknown plugins, that is why we don’t show QuickTime X. For inter-plugin dependencies and how to upgrade, you’ll have to make that call.

    We are collecting the unknowns, researching them, and adding them to the database. We’ll get QuickTime X in there soon.

  21. B.J. Herbison wrote on :

    1) The “potentially vulnerable” should give more information as to why the statement is made.

    2) As noted above, this should be in the add-on manager. Notify users when a new version is available like with extensions.

    3) There should be a “remove plugin” option, or at least instructions on how to remove. (Disable would happen for free if it was part of the add-on manager.)

  22. Gen Kanai wrote on :

    I’m really glad we are doing this and hope it can be placed as prominently as the Flash plugin update reminder.

    Most of the feedback I was going to give has been mentioned- my only request is that if we know for sure that a plugin is indeed out-of-date, we should be very clear that the user should update- i.e. more red icons, bold, “Strongly Recommends Updating”, “potential vulnerability” kind of language, etc.

  23. Kurt (supernova_00) wrote on :

    When clicking the update button, the page should open in a new tab so the plug-in check page stays open for users to keep updating their plugins and not potentially forget that more plugins needed updated.

  24. ozten wrote on :

    @B.J.Herbison and @Gen Kanai – I’ll update the post with the different states a plugin can be in.

  25. James John Malcolm wrote on :

    Very nice, even works in Seamonkey 2(b2).

    It probably would be good to
    1) Include/link to it in about:plugins
    2) Translate it!

  26. Justin Dolske wrote on :

    @ozten – To be clear, I was talking about the case where the user has version X of a plugin installed, which is known to be crashy but isn’t actually insecure. We really really want them to upgrade to version Y; it’s just not a security/vulnerability issue.

  27. ozten wrote on :

    @Justin – Good point, sorry I missed it. Adding another status “crashy” would be possible without much change to the system. Old and crashy – “This version is known to crash Firefox, please update” Update Now. Latest and crashy – “Known to cause Firefox crashes, no fix available” Disable Now. If a “crashy” release became vulnerable, then vulnerable would trump crashy and the status code would be updated to vulnerable.

  28. Dan wrote on :

    Great idea. I only have 2 plugins here on Linux and both are up to date. Many of the Windows machines I use though have out-of-date plugins (not for lack of trying in some cases though. I’ve seen so many people ignore Adobe’s Flash updater that runs at startup…)

    I hope that this page can also be used for some interesting metrics. Every time someone visits the page, record their Firefox version, their OS and what plugins they had installed. We could then get some great insights into the percentage of visitors that have a certain plugin, and how many of those have an up-to-date version of it. Plot a graph against time for each plugin, and if it’s an upwards trend, hooray!

  29. ozten wrote on :

    We’ve captured some of the feedback here and rolled it into these changes:

  30. Fabian wrote on :

    You should check navigator.plugins[i].filename against libtotem-* The browser plugins of Totem just have fake names in case a Website checks for one of those plugins. It’s not necessary to check if they are up-to-date.

    I have the following installed:
    VLC Multimedia Plugin (compatible Totem 2.26.3)

    Windows Media Player Plug-in 10 (compatible; Totem)

    DivX® Web Player
    Version:; 1.4 version of the real plugin wasn’t released at all

    QuickTime Plug-in 7.2.0

  31. crashx wrote on :

    Is there any way to acces the site with firefox? All I get is that certificate-error (sec error unknow issuer), with no box for adding an exception. How can I manually add one?

  32. Shaun wrote on :

    Everything seems to be working in Ubuntu. You should have an option to elicit translations from bilingual users.

  33. J. Couprie wrote on :

    As Crashx I have same error (of course in the French version) when using “Plugin Check”.
    “ utilise un certificat de sécurité invalide.

    Le certificat n’est pas sûr car l’autorité délivrant le certificat est inconnue.

    (Code d’erreur : sec_error_unknown_issuer)”.
    A valid certificate should not need so long time !
    This page report an acrobat reader that I have uninstalled and replaced by Foxit reader is it just an example or does it test my plugins ?
    Where can I find the list of my installed plugins ? Tools does not give it !