Rebuilding the Plugin Directory

Early snapshot of the Plugin Directory

Early snapshot of the Plugin Directory

Most web browsers, including Firefox, offer the ability to install third-party plugins. These plugins enhance your browser by enabling it to handle new kinds of content—i.e. video, audio, even 3-D games and whole application platforms.

Unfortunately, plugins can also introduce crashes and security vulnerabilities. And even worse: Since there’s no automatic update mechanism across plugins, it’s easy to install a one and forget it’s even there. Unless you return regularly to a plugin’s download page, you may never think to update it.

With this in mind, we launched a page a few months ago to detect outdated installations of the Adobe Flash plugin, encouraging Firefox users to download an update. Soon after, we expanded the effort by launching a general Plugin Check page to cover more plugins used with Firefox.

But, since it’s our mission to make the web a better place, we want to go even further: We want to expand this Plugin Check service to cover as many browsers and plugins as possible.

As it turns out, that’s a tall order: Competing browsers offer entirely different models of collecting information on installed plugins, and plugins themselves reveal inconsistent information from one to the next. This makes a common detection scheme across browsers and plugins somewhat challenging.

Additionally, there’s no single fresh source of information about plugins to check once the installed versions have been detected. For example, while the PluginDoc site at has existed for years, it tends to be out of date because it’s largely maintained manually by just a few people. And, if the information was up to date, there’s no web-based service to use for automated update checks.

So, to address these issues, the Webdev team has started work on building a new Plugin Directory. We’re in the very early stages yet, but we’re hoping to make progress on goals like the following:

  • Invite plugin vendors to contribute to our database, possibly even through submissions to a web-based API as part of a release process.
  • Invite users of varying levels of expertise to contribute to our plugin database, since we need a lot of help cataloging and tracking the plugins in the wild.
  • Provide a human-browseable directory to explore the plugin database.
  • Offer a web service enabling web pages and browsers to query our database for plugin details.
  • Improve plugin detection from web pages and within browsers

We can use help on all of the above as the project progresses, so stay tuned for more details.  In the meantime, you can peek in on the progress so far by visiting the project wiki page, where you can find notes, demos, and source code:

8 responses

  1. alanjstr wrote on :

    This should be combined with the existing Plugin Finder service.

  2. lorchard wrote on :

    This will hopefully replace the existing Plugin Finder Service, someday.

  3. Tony Mechelynck wrote on :

    OK, so I’m “a user of varying levels of expertise” 😉 using today
    Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100108 Lightning/1.0b2pre SeaMonkey/2.0.3pre
    – Build ID: 20100108002727

    Adobe Reader 9.1: /usr/lib/browser-plugins/
    Default Plugin: /usr/local/seamonkey/plugins/
    IcedTea Java Web Browser Plugin: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0/jre/lib/i386/
    Java(TM) Plug-in 1.6.0_10-b33: /usr/java/jre1.6.0_10/plugin/i386/ns7/
    NPAPI Plugins Wrapper 1.2.2: /usr/lib/nspluginwrapper/i386/linux/
    OpenSC Signer plugin: /usr/lib/browser-plugins/
    Shockwave Flash: /usr/lib/browser-plugins/
    Tcl Plugin 3.1.0: /usr/lib/browser-plugins/

    No idea how up-to-date any of them are (except of course the “default plugin” which is just as up-to-date as my browser since they are installed together).

  4. Dan wrote on :

    Great idea, good to see Mozilla continuing to improve the web experience for users of all browsers.

  5. Mark wrote on :

    FYI, the Plugin Check page indicates it is unable to detect the Flip4Map version number. However the version number is in the title of the plugin. So maybe that can be parsed out.

  6. Mark wrote on :

    Also, “Google Talk NPAPI Plugin” (on the mac) version number is not detected, though the version is specified in the description of the plugin. The only text says, “Version”. Perhaps this could also be parsed rather than detected.

  7. A321 wrote on :

    On windows, the version of adobe reader cannot be detected, but in the Tool->Add-Ons->plugins window the version number is nicely stated.. how come?

  8. lorchard wrote on :

    @A321: That’s the problem of detecting plugins in a web page. What you see in Tools > Add-Ons > Plugins is not the same information made available to JS in a web page, so things are a bit challenging.