Firefox Blocklisting: the quest for Safe and Happy

Mike Morgan

5 responses

Firefox has a blocklist service that protects users from malicious or faulty plugins and extensions. We’ve used this sparingly in the past but due to the success and popularity of Firefox we’ve seen more and more activity on the blocklist than ever before.

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:

5 responses

  1. Dan wrote on :

    And the dialog that pops up needs improving. The Cancel button is unclear – does it cancel the blocking or just cancel the restart?

  2. Fred Wenzel wrote on :

    I love the idea of a plugin update service, because often, people wouldn’t even need to be so upset about a blocklisted version: They’d just need to update to the latest version of that particular plugin. Making that easier would perhaps even remove any disruption to the user whatsoever: If you don’t have a vulnerable plugin version, you won’t notice it being blocklisted.

  3. Michael Lefevre wrote on :

    “For many users, it wasn’t clear what to do once their plugin or add-on was blocklisted.”

    I’m sure all these other projects are great (I must admit I haven’t read the details yet), but I don’t see any of them addressing this issue, in the event that a plugin is blocklisted (which you acknowledge will continue to happen).

    With the Java blocklisting, I don’t think the problem was that the information about what to do did not exist, the problem was that Firefox UI links to a blocklist page with no context, which in turn sends people directly into bugzilla.

    It may be that you just didn’t mention it, but it would seem that simple changes to the current UI (or even just changes to the web page it currently points to) could make a huge improvement to the experience.

    (Also, I’m getting a 403 error on the Plugin update service link)

  4. David Tenser wrote on :

    This reminds me of the book Nudge, which is arguing that it’s better to positively encourage people to make a change than to force the change upon them. The example here would be to tell the user what’s going on and offer a choice, rather than force-block a plugin.

    For example, if there is a vulnerability in the version of QuickTime the user is running, instead of just blocking it, we could 1) inform about the vulnerability and what this means, and 2) allow the user to choose if he/she wants to remain vulnerable or disable the current plugin. In other words, put the user in control, but nudge him/her to do the right thing.

    Of course, whenever possible, we should just upgrade the plugin, but the above example assumes there’s no secure version out yet.

    Thanks for a very well-written blog post!

  5. Ken Saunders wrote on :

    My understanding is that security is Mozilla’s top priority and I count on that so I have no problems at all with Mozilla disabling anything that could compromise my data.
    Does anyone remember losing everything when they used IE? For me it was more than once. If Microsoft did (or would do) what Mozilla does, then millions (perhaps billions) of dollars and thousands of hours would have been saved.

    Now I’m as much of an advocate for personal choice and control as the next person, but I think that Mozilla taking a “Not on my watch” attitude/approach is totally acceptable. I’d rather a few users be pissed off than false statements being spread like “My identity was stolen thanks to Firefox”, or, “My system was hacked and taken over because I used Firefox”.

    First and foremost though, and like Mike said, awareness should be the first step.
    How often do users even bother to view the Plugins pane in the Add-ons Manager anyway?
    If there is a vulnerable plugin, there should be a clear and strong alert that requires user interaction to close/disable the alert or to get info on what to do about it.
    In the Plugins pane, stronger visualizations should be used too.
    The green check mark is cool, but there should be icons and colors used for Vulnerable plugins too (like a red triangle with an exclamation mark), and they would be more noticeable and add more of a sense of urgency if they were under the Plugin’s title.

    I think that users identify needed or required actions with icons more than they do button colors, but both wouldn’t be a bad idea.

    In any event, thanks to Mozilla for looking out for us all.