We hate crashes. When Firefox crashes, we try to get you back on your feet as quickly as possible, but we’d much rather you not crash in the first place. In Firefox 3.6, we are changing the way that some third party software hooks into Firefox which should eliminate a good chunk of those crashes without sacrificing our extensibility in any way. In the process, we’ll also be giving you greater control over the code that runs in your browser.

Background

Firefox is built around the idea of extensibility – it’s part of our soul. Users can install extensions that modify the way their browser looks, the way it works, or the things it’s capable of doing. Our add-ons community is an amazing part of the Mozilla ecosystem, one we work hard to grow and improve.

In addition to the standard mechanism for extending the browser via add-ons and plugins, though, there has historically been another way to do it. Third-party applications installed on your machine would sometimes try extend Firefox by just adding their own code directly to the “components” directory, where much of Firefox’s own code is stored.

There are no special abilities that come from doing things this way, but there are some significant disadvantages. For one thing, components installed in this way aren’t user-visible, meaning that users can’t manage them through the add-ons manager, or disable them if they’re encountering difficulties. What’s worse, components dropped blindly into Firefox in this way don’t carry version information with them, which means that when users upgrade Firefox and these components become incompatible, there’s no way to tell Firefox to disable them. This can lead to all kinds of unfortunate behaviour: lost functionality, performance woes, and outright crashing – often immediately on startup.

In Firefox 3.6 (including upcoming beta refreshes), we’re closing this door. Third party applications can still extend Firefox via add-ons and plugins the way they always could, but the components directory will be for Firefox only.

What Does This Mean For Me?

If you’re a Firefox user, this should be 100% positive. You don’t have to change anything, your regular add-ons should continue to work properly – you just might notice fewer crashes or odd bugs. If you do notice that something has stopped working, particularly a third party addition to Firefox, you might want to contact the producer of that addition to ensure they know about the change.

If you’re a Firefox component developer, this shouldn’t be a big change, either. If you’re already packaging your additions as an XPI, installed as an add-on it’s business as usual. If you have been dropping components directly, though, you’ll need to change to an XPI-based approach. Our migration document on the Mozilla Developer Connection outlines the changes you’ll need to make, and should be pretty straightforward. The good news is that once you’ve done this, your add-on will actually be visible to users and will support proper version information so that our shared users are guaranteed a more positive experience.

If you haven’t downloaded the new Firefox beta yet, and want to give it a spin, you can find a copy here.

Johnathan Nightingale
Human Shield

In it, he discusses the current state of affairs, the series of events that got us to this point, as well as the steps we, and Microsoft, are taking to get the situation resolved.

Today, we’re bringing the rest of the story. Our web team has just pushed the full plugin check page live, checking the status of more than 15 popular plugins, with more still in the works. Visitors to the page can see which plugins they have installed and, for any that are outdated, follow an easy link to the update site.

In the upcoming release of Firefox 3.6, we’ll also include built-in support for helping users keep up to date. When you visit a page with Firefox 3.6, we’ll use this same service to let you know if any of the plugins used on the site have updates available.

We’ve got a pretty strong list of plugins and versions already but we’ll continue to maintain and grow it based on our conversations with plugin authors and our users. If you want more information, or are interested in helping out, check out the web team’s post. Did the plugin check uncover any surprises for you?

Johnathan Nightingale
Human Shield

]]> http://blog.mozilla.com/security/2009/10/13/mozilla-plugin-check-now-live/feed/ 16 http://blog.mozilla.com/security/2008/12/10/leaving-mozilla/ http://blog.mozilla.com/security/2008/12/10/leaving-mozilla/#comments Wed, 10 Dec 2008 19:15:12 +0000 Window Snyder http://blog.mozilla.com/security/?p=48 I will be leaving Mozilla at the end of the year.  I am sad to be leaving, but I am excited to go work on something I have always been passionate about.  I wish I could tell you about it now, but that will have to wait for a while.

You will still get Mozilla security information here. Johnathan Nightingale, Lucas Adamski, Brandon Sterne and Mike Shaver will all be posting on the Mozilla security blog to keep users informed about security issues and announcements.  I leave you in their very capable hands and wish them the best of luck.

The Mozilla community is an incredible group of dedicated people who are really making a difference in how we experience the Internet.  The contribution you make to the world is tremendous.  I am honored to have been a small part of it for these last few years.

Thank you,
Window

Window Snyder
window@dec.net

Below is a summary of the project goals, and the xls of the model is posted at http://securosis.com/publications/MozillaProject2.xls.  The same content as a set of .csvs is available here: http://securosis.com/publications/MozillaProject.zip [Update] There also a copy for OpenOffice: http://securosis.com/publications/MozillaProject2.ods

This is a preliminary version and we are currently looking for feedback. The final version will be a far more descriptive document, but for now we are using a spreadsheet to refine the approach. Feel free to download it, rip it apart, and post your comments. This is an open project and process.  Eventually we will release this to the community at large with the hope that other organizations can adapt it to their own needs.

We would love to get your opinions on this, and if you are not comfortable commenting here you can mail Rich directly at rmogull@securosis.com.  When we have reviewed the feedback, we will post here with findings and continue the effort with your help.

Project Mission:
To develop a metrics based model to track the relative security of Firefox, evaluate the effectiveness of security efforts within the development and testing process, and measure the window of exposure of Firefox users to security vulnerabilities.

Secondary mission:
To develop an open base model that can be standardized and expanded upon for other software development efforts to achieve the same goals.

Detailed goals:
1. Track security trends in the development of Firefox.
2. Measure the effectiveness of various tools, stages and techniques of secure development.
3. Measure the exposure window when new vulnerabilities are discovered- the time to get x% of the user base protected. Will include sub-metrics to measure the efficiency of the process, from initial response, through patch generation, through user base updated.  Correlate by severity of vulnerability.

This issue was patched in only six (or 6.25 according to John O’Duinn) days. When a vendor ships security fixes quickly, it lowers the incentive for attackers to spend time developing and deploying an exploit for that issue. The window of opportunity for attackers is reduced and so is the potential to compromise users. So thanks you guys, for helping destroy the economics of malicious exploit development.

http://www.mozilla.org/security/announce/2007/mfsa2007-28.html

Well, whatever he meant, his statement has taken on a life of its own. Robert posted on his blog, and a bunch of news articles picked it up as a challenge.

This is the official Mozilla word: This is not our policy. We do not think security is a game, nor do we issue challenges or ultimatums. We are proud of our track record of quickly releasing critical security patches, often in days. We work hard to ship fixes as fast as possible because it keeps people safe. We hope these comments do not overshadow the tremendous efforts of the Mozilla community to keep the Internet secure.

This is the tool we discussed in our presentation, the first in a series of security tools that we intend to make publicly available.

https://bugzilla.mozilla.org/show_bug.cgi?id=jsfunfuzz

The responsible sharing of security tools is an important way to contribute to the overall health of the web. We worked with Microsoft, Apple, and Opera to reduce the possibility that this tool might adversely affect users of those browsers. All of these browser vendors reviewed the tool and let us know that they were okay with the release.

You can also catch up with me Wednesday afternoon on the Future of Information Security panel or Thursday afternoon on the Ethics Challenge panel.

After you roll in from all the parties on Wednesday night, stop by Royal 55, Augustus Tower in Caesar’s Palace to have milk and cookies with Mozilla. It’s a super chill pajama party with some of the people who make Firefox. Pajamas not required. Stop by on your way to bed. We’ll be there 11pm to 2am and possibly later.