Indistinguishable from Jesse

michaell also asked:

Good news about the [Mozilla Foundation] internship - any idea what you’ll be doing when you’re there?

I will be a Technical Contributor, Browser and Gecko Security. I haven't yet discussed with Chris Hofmann, Dan Veditz, etc. what I will be doing to make Firefox more secure.

michaell asked:

I know you’ve criticised the mozilla security process (that is, what happens in practice rather than the documented process) previously, but haven’t seen you say anything about it recently. Do you think things have improved? What concerns do you still have?

Dealing with vulnerabilities that are found

There are many problems with Mozilla's vulnerability-handling process:

• For bugs that are disclosed by the reporter, patches usually appear quickly, but fixed releases take too long.
• For bugs that are not disclosed by the reporter, patches and fixed releases take too long.
• Reporters of security holes sometimes don't get any response for a week, which may make them inclined to disclose the hole sooner.
• For bugs that are not disclosed by the reporter, fixes are checked into public CVS days, weeks, or months before the release. Anyone can look through Bonsai and identify which checkins correspond to security holes without looking at code. (Checkins with references to hidden bugs, branch checkins, and checkins with vague comments without bug numbers are likely to be security holes). They could then look at the source code changes and, in many cases, reconstruct an attack based on understanding the vulnerability in the old code. Mozilla's security group needs a secret CVS repository for security patches.
• Bugzilla, Mozilla's bug-tracking system, has holes that can lead to the disclosure of information about security-sensitive bugs. One such bug is itself marked as security-sensitive and has been for years even though multiple people have filed duplicates.

I posted an older version of this list in a comment on Asa's blog. Security researcher "mikx" knew about the CVS problem and it was one of the reasons he chose to disclose holes in Firefox before a fixed version was released.

Eliminating grandfathered vulnerabilities

I'm sad how long my Security tips for users document has to be. I believe that most of the vulnerabilities in Windows and Firefox mentioned there can be fixed with little impact on usability in non-attack cases. They could certainly be fixed with less impact on usability in non-attack cases than making all users read that document ;)

Getting users to keep Firefox updated

Firefox's update notification is too subtle, and updating requires too much bandwidth and effort. Plans for software update in Firefox 1.1 are moving in the right direction to fix these problems. One issue that will be hard to address is users not updating due to abandoned extensions.

Avoiding "missing security check" holes

There have been several fixes that eliminate the need for a class of security check. These fixes make it easier to write secure C++ and JavaScript code and make it unnecessary to sprinkle easy-to-miss security checks throughout Firefox. I hope to see more fixes like these in the future.

Avoiding holes in Firefox's security UI

Someone (maybe me) should keep a list of all the security UI in Firefox and ensure the necessary precautions are applied. For example, users should see clear, accurate information to help them make security decisions such as entering passwords, opening downloaded files, and granting elevated permissions to specific web sites.

One aspect of security UI that requires a lot of attention is dialogs where users make security decisions. In addition to everything above, security dialogs should have safe default actions, clear button labels, and protection against race-against-the-user attacks.

Firefox is doing better on the security-UI front than IE and Opera. IE's and Opera's "what do you want to do with this file" dialogs are still vulnerable to race-against-the-user attacks almost a year after I informed Microsoft and Opera Software. That means that if you're using IE or Opera, a web site can own you pretty easily.

Working with other browser vendors

The Mozilla security group has coordinated security fixes and PR with Opera Software when Firefox and Opera have shared vulnerabilities. This is a good thing.

Some Firefox users (I don't know how many) refuse to upgrade to new major versions because their favorite extensions break. Users who don't upgrade miss out on new features, new extensions, and security fixes. What can be done to reduce the number of extensions that break when a new version of Firefox is released? Some ideas:

• Make sure extension authors know when all the major changes for a release have happened, so they have plenty of time to test their extension against the trunk/alpha/beta and bump maxVersion. Ensuring that all major changes for Firefox 1.1 happen before Firefox 1.1 beta might be a good way to accomplish this.
• Ensure that mozilla.org has permission to distribute new versions of extensions listed on UMO that authors abandon.
• Make maxVersion optional (bug 251148).
• Let users override a specific extension's maxVersion through the Extension Manager UI.
• Broken XUL overlays should not break XUL windows with XML errors. Instead, they should disable the extension or make the overlay be ignored.
• Try to freeze interfaces that extensions use.

Changes since 1.2.1:

• Make the bookmarklet version continue to work when you reload the original page or go to another page on the same site. (Fix by Sebastián Marconi and me.)
• Make the "clicking anywhere focuses the textbox" feature work in IE. (Fix by Jeremy Vinding and me.)
• Fix most of the javascript.options.strict warnings. (Fixes by Jeremy Vinding and me.)

Updated shell, updated bookmarklet, diff for the curious

AutoLoginJ automatically submits login forms where Firefox has remembered the password. You can use Greasemonkey's included/excluded pages feature to make it work on all sites, all sites except ones you specify, or only sites you specify.

The "J" in the name distinguishes it from a competing script and an extension with a similar name.

To install a user script into Firefox, install Greasemonkey, restart Firefox, open the user script, and select "Install User Script..." from the Tools menu.

I made BugSort freeze Firefox less by making it only reposition 100 bugs at a time. For most uses, this makes the script appear faster, too. The script is now under the MPL, so it can be incorporated into Bugzilla.

June 17 - June 23: Hiking in Havasupai Canyon, a tributaty of the Grand Canyon. I will hike with my mom and brother, two 3rd cousins, and their parents.

June 30 - September 9 (approximate): Mozilla Foundation internship in Mountain View, California.

Before and after the Grand Canyon trip, I'll probably spend time at my parents' house near Los Angeles, California.

What I will do after this summer is up in the air. I might return to UCSD to continue the computer science PhD program, which I'm not enjoying much so far, or I might try to get a job at the Mozilla Foundation, Google, Yahoo!, etc.

Drag 43 Things lets you rearrange your 43 Things by dragging instead of by giving a new array index for each item. The script is based on Javascript drag-and-drop ordered lists by Simon Cozens.

To install a user script into Firefox, install Greasemonkey, restart Firefox, open the user script, and select "Install User Script..." from the Tools menu.