Over the last few years, the Web has come a long way in providing web-native solutions to technical challenges that previously required authors to use external plugins. This has been and still is a vast undertaking, but there are a number of compelling reasons to ensure that authors have the tools they need to create the content they want, without relying on plugins. Chief among them are security and device limitations. Plugins have long been a major attack vector when it comes to browser exploits, and as more and more users access the web through mobile devices where plugins simply aren’t supported, web-native content becomes less and less the fallback solution, and more and more the primary one.
Statistics and where we get them
When users click “Install plugin…” in the Firefox UI, our Plugin Finder Service (PFS) tries to find a relevant plugin for the mime-type and operating system, and depending on what it finds, it’ll either offer to launch an installer or link to a manual install URL. This allows us examine which plugins users are trying to install, and whether or not we’re doing a good job of helping them. I should note that we don’t log IP addresses, nor referring URL, only mime-type, client OS, Firefox version, Firefox language, and some IP based geolocation information.
It appears this happens about 1.1 million times per day.
Counting unique mime-types seen over a 7 day period, reveals that the web still contains a surprising variety of plugin content; 3542 to be exact. Even after correcting obvious errors and aggregating certain mime-types into groups when more than one can identify a specific plugin (such as Java, for example), we’re left with 2378 different types. Thankfully, most of them have a very low showing, and with further error pruning it’s likely closer to 2000. Plugin Finder Service however, handles only 18 of those – and most only for certain OS’s.
Global top 20
These are the mime-types that users are trying to install plugins for, and even within the top 10 there are at least 3 surprises. Note: I use brackets to indicate that it’s a group of mime-types.
- [Flash] (64.57%)
- [Java] (9.59%)
- [Windows Media] (4.50%)
- application/x-director (3.97%)
- [QuickTime] (3.81%)
- application/octet-stream (3.34%)
- text/html (2.49%)
- application/x-vlc-plugin (0.81%)
- application/pdf (0.55%)
- text/plain (0.46%)
- application/vnd.unity (0.43%)
- application/qvod-plugin (0.37%)
- application/gas-ibh-abn (0.37%)
- [Zylom Games] (0.23%)
- [Silverlight] (0.20%)
- [Skype] (0.20%)
- video/divx (0.13%)
- audio/x-mpegurl (0.13%)
- application/x-hardwaredetection-plugin (0.13%)
- application/mozilla-wat-scriptable-plugin-11 (0.12%)
What can we learn from that list?
There are a few things we can say for sure just looking at that list.
- application/octet-stream, text/html and text/plain should not show up here – we’re clearly presenting the user with the UI at times when we shouldn’t. It appears that text/html is probably a result of embeds trying to load a resource that returns some sort of error page.
- There are clearly only a select few we really need to help users install. Either because authors are providing their own UI to install the relevant plugin, or because the plugin isn’t widely used enough to warrant attention.
Considering the rapid falloff in usage, what percentage of the requests do we actually successfully handle? I don’t have the exact numbers because the scrubbed version of the data I’ve been working with doesn’t contain OS information, and as mentioned earlier that influences how and whether we can help users install a plugin. A somewhat artificially inflated number then comes out to 86.3%, which is much better than I had feared.
Different markets have different habits, so looking at the global stats isn’t enough to gain insight into how the top 3 plugins usages were distributed across the globe. Here is a gradient map showing the percentage of PFS hits that were for Flash per country
I’ve generated some interactive maps for Flash, Java and Windows Media where you can get the actual numbers by hovering the desired country. Do note that for sufficiently small countries there is very little data, so those numbers should be taken with a grain of salt.
The missing plugin UI
Currently, when a user loads a page that includes a plugin they don’t have installed, we show an in-content overlay in its place (if it’s large enough), and a notification bar under the Awesome Bar. The notification bar in particular is really obtrusive, especially for people who either can’t or won’t install a specific plugin.
Both of these problems will be addressed by the work I’ve done to make our UI more reasonable, and removing PFS as a service. The work will replace the notification bar with a door hanger (like the password manager), which will only be open by default for Flash. For Java, Shockwave and QuickTime, only the door hanger anchor (the icon in the Awesome Bar) will be displayed. For all other plugin types, we will at most display the in-content UI – following the existing rules for trying to use the site’s fallback content, etc.
To ensure that people who can’t or won’t install Flash don’t keep getting a door hanger, it will include an option to not open it by default again, after which it will have the same behavior as it does for Java and the other aforementioned plugins.
In the current implementation, we quite often prompt the user to install a plugin, and after guiding them through an install wizard, tell them that we couldn’t help. With these changes, that ought not to happen anymore. We only ever offer to install plugins we already know we have some way of handling.
When a plugin author like Adobe updates their plugins, they usually file a bug ahead of time to update our PFS with the correct file hash and download location. However, if this process takes longer than expected, we might end up temporarily serving a plugin known to be insecure, or one that will fail the hash check after download – both not exactly ideal situations. After removing PFS as a service, we allow for the possibility of letting companies like Adobe to host their own installer information, making it much easier for them to push updates without delay. We still retain a system for blocking specific plugins even when the installer information is provided directly by a third party.
Hopefully, I (or someone else) gets to remove the wizard dialog, which seems just as out of place now as it did before. As a start, I think I’ll push for a change that will trigger it only when we have an actual installer to run, which is only Flash at the moment.