But please remember: it’s still important to keep your plugins up-to-date. Out-of-date plugins can be a security risk.

In a previous blog, I talked about the blocklist service in Firefox and its role in keeping users informed and up-to-date with regards to plugins. It looks something like this:

As a follow-up to that post, I walked through the update process for Firefox. Here were my testing steps:

1. Edit my blocklist.xml files and preferences to blocklist the Flash filename on each platform.
2. Restart Firefox
3. Visit YouTube (or any page with Flash on it)
4. Follow the on-screen prompts until you reach our goal: a browser running an up-to-date version of Flash

Adobe and Mozilla both need to make this process easier for users. In summary, this is how it went:

• Windows: 9 steps, 2 unnecessary software downloads from Adobe
• Mac: 15 steps
• Linux: 6 steps, high likelihood of failure or conflict with package manager

Safe to say that there are many ways we can improve this process:

• Show specific warnings about which plugins are out of date
• Don’t have an intermediate step on the plugin checker
• Do not have the McAfee opt-out on the Flash download page
• Do not force people to download the XPI (Firefox could use an external installer + hash check like it does with PFS)
• Eliminate any steps you can — get it down to a one-click experience if possible

Protecting users from plugin crashes is a great thing, and I’m looking forward to seeing the plugin update experience becoming just as awesome.

• Groundwork for a plugin directory
• Cross browser plugin checking

The Backend

Les Orchard has created a backend to the plugin finder service. We’ve added another input to the call named ‘detection’ which will allow us more flexibility in how we match known releases to OS / Product / Version / Plugin / Plugin Version combos. More news at 11, but he’s built the core pieces for a self-service plugin release application.

The Frontend

We updated the JavaScript client to support ‘modern browsers’ as well as IE.

But IE 8 is a modern browser!

Hmm, well it doesn’t have a navigator.plugins object. Other popular and recently released desktop browsers *do* have this feature. Heck, even some phone’s browsers have it.

Breaking News: The platform preview of IE 9 has a working navigator.plugins object! So IE 9 fits the modern browser category… Congrats to the IE 9 team! We’ll make sure the page works by the time IE 9 ships, filed Bug#566003.

Cross Browser Flavors

Our plugin detection uses one of three strategies:

1. Strategy 1) Iterate the plugins objects and parse a version string out of the description or name
2. Strategy 2) Iterate the plugins objects and use the ‘version’ property
3. Strategy 3) Instantiate well-known plugins and test their version via the pinlady.net version detection library.

If your goal is to protect as many users from as many known plugin vulnerabilities as possible… Strategy 3 doesn’t scale. Strategies 1 and 2 are dynamic and (in the best case) plugin agnostic. As new plugins come onto the market, the plugin finder service has to be updated, but no new code has to be written and shipped.

This is why IE plugin detection is limited.

Strategy 2 is the cleanest… and only supported by Firefox 3.6+. We would be pleased as punch if other browser vendors would create a version property. The Plugin Check page and other pieces of code that do plugin detection, will become more accurate.

We’re really excited about supporting all browsers and that is what Strategy 1 buys us. When a vendor has put a useful version number in the description or name, then it’s possible for our page to help Safari, Opera, or Chrome users understand their plugin versions better.

Geeky Aside:

Fly in the ointment, even for Firefox 3.6+ we currently will use methods #1 and #2 depending on what’s best for detecting the most accurate version for the most popular plugins. Why is nothing every simple?

What can browser vendors do?

Please implement the navigator.plugins[x].version property. This exposes an explicit plugin version number from the vendor.

Why?

It will keep your users safer. This and other security tools can detect vulnerable versions easier and more accurately.

What can plugin vendors do?

At a minimum, please put your full version number in the plugin description field. Also make this as exact as possible, include the build number etc. 1.1.2.9282 is better than 1.1.2. Bonus points, expose your version numbers in the version property, even on Linux builds of your plugin.

Why?

• Keep your users safe
• Improve your lastest version uptake
• Keep users coming back to your distribution channel
• Reduce your support costs

What’s next?

We’ve built the plumbing and populated it with some popular plugins versions. Our next major release will be focused on building a self-service plugin release management app, so that vendors can populate the data for the backend API.

Why is this important to you?

• Crashes are the number one concern for Firefox users, and we are listening.
• At least 30% of all Firefox crashes are caused by third-party plugins.
• Many major security vulnerabilities exploit out of date plugins.

Why is this important to Mozilla?

Increasing awareness about plugins makes the web better, and that’s our mission.

• We want the web to be safer.
• We want the web to be less crashy.
• We want to help everyone — not just Firefox users — to address the plugin problem. (though admittedly it doesn’t fully work with all browsers yet, it will)

What did we do?

The plugin checker has three components:

• The Server: Plugin Finder Service (PFS2)
• The Javascript: Perfides
• The Web Page: mozilla.com

The end result is actually pretty simple — and that’s how it needs to be. Here’s your plugins, and here’s their statuses:

Putting it all together, we reach a workflow similar to the graph below. Our goal is to query a central database that contains plugin information and inform users about the status of their plugins. This was built so it could be used to support Firefox directly in the future.

What will happen next?

The three components above are a good start, but together we can do more.

• Integrate this experience with the Firefox client. Firefox will identify vulnerable plugins and help you update them.
• Create a self-service panel for vendors to update their plugin info as new releases come out.
• Create an open directory for all plugin information (sort of like Plugindoc but dynamic)
• Evangelize plugin detection via an embeddable widget — get it out on WordPress, etc.
• Integrate with our crash reporting system so we have a report card/dashboard for which plugins are most crashy

How can you help?

This entire project is open source. You can work on any of these components to help contribute to the effort:

• View the server code for PFS2
• View the client code for Perfides
• File a bug if you find one
• Tell us about plugins we don’t know about