As noted on our security blog, we’ve just pushed out a major update to the plugin check page and service.
The two core ideas are:
- 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:
- Strategy 1) Iterate the plugins objects and parse a version string out of the description or name
- Strategy 2) Iterate the plugins objects and use the ‘version’ property
- 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.
Redvine wrote on :
sabret00the wrote on :
Fred Wenzel wrote on :