Plugins: usage, distribution and future in Firefox

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

  1. [Flash] (64.57%)
  2. [Java] (9.59%)
  3. [Windows Media] (4.50%)
  4. application/x-director (3.97%)
  5. [QuickTime] (3.81%)
  6. application/octet-stream (3.34%)
  7. text/html (2.49%)
  8. application/x-vlc-plugin (0.81%)
  9. application/pdf (0.55%)
  10. text/plain (0.46%)
  11. application/vnd.unity (0.43%)
  12. application/qvod-plugin (0.37%)
  13. application/gas-ibh-abn (0.37%)
  14. [Zylom Games] (0.23%)
  15. [Silverlight] (0.20%)
  16. [Skype] (0.20%)
  17. video/divx (0.13%)
  18. audio/x-mpegurl (0.13%)
  19. application/x-hardwaredetection-plugin (0.13%)
  20. 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.

Plugin Distribution

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

flashDistributionI’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.

Plugin updates

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.

Next step(s)

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.

2 thoughts on “Plugins: usage, distribution and future in Firefox

  1. It’s interesting just how much Java/Silverlight varies from this source:
    Shockwave is really suprising to me.. and sad for lack of Linux support :(

    I would also love to see this data track referrers so that we can contact the top ones and see if the open web works better for them now.

    At a different scale I would like to see information about when you last used on the plugin screen in Firefox itself:
    I will go over to repair someones computer and find that they have a LOT of plugins installed. It would be very useful to know which are safe to uninstall.
    Something like:
    Flash; used on 128 sites in the last month, most visited on,
    Silverlight: never used
    Java: last used 6 month ago on site

    This would make it much easier to decide what plugins can go and make their browser that much more secure.

  2. The discrepancy between our numbers and theirs, is probably related to which kinds of sites tend to use them. Silverlight seems to me rarely used outside of services like Netflix, which does a very good job of providing fallback content that provides help installing it. In that case, it wouldn’t show up in our numbers, because PFS is never triggered.

    It’s my personal experience that Java is typically used on either very old or bank/government related sites, and they seem less likely to provide an appropriate fallback, thus triggering our PFS.

    I like your idea about telling the user about when plugins have been used and where, however I don’t think it’s possible for us to track referrers without breaking our data collection policy, even if it is well intentioned…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>