Follow-up on the 'Firefox v3.5 fiasco'

(Follow up to: The Firefox 3.5 fiasco)

I'd like to inform the audience that the people over at NSS, the sub-system which is responsible for the disk-trashing behavior of Firefox 3.5 (and the accompanying delays on startup) on some systems, has worked on a fix for this which appears to be scheduled for FF 3.5.1. You can read the discussion by starting here (which lands in the middle of the bug comments, but the comments above the one linked are basicly bickering comments over what to do to the symptoms instead of really fixing it at the root)

It's good to know that the NSS folks finally listen in and will use CryptGenRandom when available (it's a windows subsystem method) and will only revert to disk-based entropy collecting when CryptGenRandom isn't believed to be as solid as it is on 'modern' OS-es like Windows XP and up. I still think that MS has patched Win2k's kernel code enough to make CryptGenRandom (which is essential for the TCP stack as well) solid enough, but it's their call (IMHO, people should make choices based on evidence based arguments, but as Win2K is rather old and no longer supported by MS anyway, it's not such a big deal)

Let's see whether this patch will turn out to be as good as it looks today. I'm glad Mozilla is keen on fixing this pronto, as FF 3.0 is scheduled to be non-supported software starting in January 2010.

So what can be learn from all of this as a developer? In my opinion, the true lesson to learn here is that no-one is perfect and that it's key to keep listening to what our users experience when using the software we wrote, so problems can be solved better and choke points can be dealt with. It's all too easy to simply close the eyes and ignore problems reported by perhaps a minority of the users by cooking up excuses for not dealing with them, but that's not the solution: the problems won't go away by ignoring them, the vocal minority might actually be representing a big non-vocal group or worse: a big non-vocal groups of ex-users. That's not to say that every problem ever reported by a user should immediately be fixed: unless you have unlimited time and resources, it's practically not doable to achieve that, but we should at least try and investigate whether these reports might cover bigger problems, might affect bigger groups than a sole individual.

8 Comments

  • Going through the comments on your other post about this, it strikes me that what we really need is a fix for the "It works for me so it's not really a problem" bug.

    Too bad that that's not a software bug, it's a human bug.

    Bryan

  • I find it reassuring the open-source methods employed by the folks at Mozilla Foundation and all the other external contributors (like Frans, for instance) are able to detect and correct problems like this in such a short time. It's open-source working as predicted. The source-code is exposed and no bug can hide itself (or be hidden by its owner).

    While I noticed the startup delay myself on the Windows system I use at the office, I blamed it on the anti-malware suite that I have to run for the delay. I just scheduled FF35 to start on login and, since it takes about 3 minutes for my Windows box to be usable any way, I continued my morning routine of logging in and getting a coffee. Perhaps the fact I seldom use IE (and thus have almost empty temp files folders) also made the delay less noticeable.

    As I said elsewhere, we are quite lucky. Were this a problem in IE or Oracle Applications, we would have to wait until some developer were assigned the bug and a fix to be scheduled for some future release that could or could not come this year.

    Release early and frequently should be a mantra for the whole industry, not only among FLOSS folks.

  • Windows 2000 is still supported by MS, until 2014. Probably not to the extent required to improve major security subsystems though.

  • Isn't it the purpose of opens source to be able to fix things yourself?

  • nevermind, just reread the original post:

    "NSS is open source, but it's not something you can fix yourself, unless you compile the browser as well."

  • @Michael: in theory, yes, but in practise it doesn't work that way, simply because for example the NSS dlls are signed, so the hosting app knows they're genuine. If I compile one myself, I can't sign them with the mozilla certificate so the hosting app (firefox) won't run them, or I have to compile firefox as well.

    As the fix is pretty simple (the code is already there, but due to bad goto statements it's not called and the filesystem entropy gatherer is doing that regardless if there's need for it or not) IMHO it should be done by the maintainers, so everyone profits.

    Yesterday I think I found a bug in the patch they produced, I haven't heard back yet from them.

  • Firefox 3.5.1 is out.

    @FransBouma: did you comment in the bug regarding the bug you found?

  • @Jose: yes I commented there, but no I didn't found the bug, I just reported about it. :)

Comments have been disabled for this content.