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.

Why Blocklisting is Hard

The most difficult part of the blocklist service has been deciding when to actually use it. Our policy outlines some general guidelines, but it’s not so simple when millions of users are involved because you also have to consider how you could potentially affect user experience. We have to weigh security and stability with user happiness.

In the past, being proactive with the service has been tough. Take, for example, the time we blocklisted a plugin and add-on as requested by Microsoft. Another example would be the blocking of a relatively hidden Java plugin or ancient versions of QuickTime.

In most cases we prevented an expected user interaction from being used. Whether it’s Flash on YouTube, QuickTime for movie previews or Java for applets — when users can’t do what they want to do, it’s a really negative experience. We don’t want to prevent users from doing what they want to do on the web. On the other hand, we don’t want users to be vulnerable to exploits caused by outdated plugins.

So while we were upset to know that what we did ruined the browsing experience for some people, we also knew that what we were trying to do was right and helped considerably more people than it hurt. I am proud of this — at least the idea that we are willing to do something unpopular because it’s the right thing to do. I do believe, however, that we can manage to keep users safe and happy simultaneously.

Keep people safe and happy? What a wonderful challenge.

Things We’ve Learned

Working on the blocklist, we’ve learned:

• Many people are not aware of which plugins they have installed on their system.
• People don’t like having their software disabled.
• For many users, it wasn’t clear what to do once their plugin or add-on was blocklisted.
• Out-of-date plugins can be a real and serious threat to user experience and security.
• Plugins are indeed an integral part of our everyday web experience.

What Can We Do About It?

The threat plugins pose to users will not go away, and we will continue to fight to keep users safe. We can fight smarter, though. The blocklist service will always be here, and we’ll use it when we need to. But increasing awareness about plugins and how to keep them up to date is a much more positive and proactive approach.

A few projects cover this initiative:

• Plugin Check is a web-based tool with cross-browser compatibility any web user can use to check their plugins against our plugin database. This helps users know what plugins they have installed and how to keep them up-to-date.
• Plugin Directory is an online interface for our plugin database that will be used as a portal for vendors and users to keep plugin data up to date. It’s currently in staging and about ready to launch.
• The Plugin Update Service is a Firefox project which adds plugins to the add-ons manager. Having an integrated experience consistent with add-on updates will make plugin updating easier for everyone.
• Out of Process Plugins (electrolysis) reduces the impact plugins have on the stability of Firefox. When your plugin crashes, Firefox won’t crash with it.

With these projects, I am confident we will offer a better experience for users; keeping the web happy and safe at the same time.

Get Involved

If you’d like to know more and get involved we’d love to hear from you:

• Read about how the blocklist works.
• Read about PFS2 and how this all started.
• See what’s in store for Firefox 4.
• Join us in IRC! We’re all in #webdev.

• 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.

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

• 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 Mozilla.com 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.

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