Browser patches yearn to be free
All web browsers have bugs, but when simply viewing a web page can infect your computer with malicious software, the speed with which bugs are found and fixed is critical. It may be the most important yardstick by which to measure any web browser.
For Windows users, the choice between Firefox and Internet Explorer isn't a contest at all. Microsoft is slow in fixing IE bugs, being locked into a once a month cycle. Not Firefox.
Mozilla released version 3.02 of Firefox on Tuesday. It had a bug. Happens all the time. What doesn't happen all the time is that the bug was fixed quickly and version 3.03 of Firefox was released on Friday.
Anyone interested in Defensive Computing doesn't want their bug fixes idling at the gate waiting for the one day a month when they are set free.
See a summary of all my Defensive Computing postings.
Michael Horowitz is an independent computer consultant and the author of several classes on Defensive Computing. He is a member of the CNET Blog Network, and is not an employee of CNET. Disclosure.






You know when the patches are due to be released, so you don't miss any and get hacked when a hacker reverse engineers the patch.
If you just release patches on random days, folks might get caught off guard and miss patching as quickly as they might want.
Also, third party patches are the most danergous patches, so its better to know when the genuine patch is coming out.
I never agreed with the whole ZERT thing, its just encouraging the bad guys to release third party patches which could be malware pretending to be a patch.
Never accept third party patches, even if they are from ZERT, it sets a bad precedence.
You say that forging a third party patch would be an excellent way for a hacker to introduce malware into multiple systems. I completely agree.
Then you say that a good defense against this is to have a single monthly patch day so that you know if the patch is genuine. Because hackers aren't capable of waiting to release a forged patch on an expected patch day? If anything, uniform patch days make end-users MORE susceptible to forged patches, because everyone is expecting the patch to be released and blindly downloads it (including, apparently, you). Downloading a patch simply because it was released on the right day of the month is possibly the worst way a person could determine if it is genuine.
"If you just release patches on random days, folks might get caught off guard and miss patching as quickly as they might want."
"Also, third party patches are the most danergous patches, so its better to know when the genuine patch is coming out."
But wait. The article is talking about Firefox. Users are notified automatically by Firefox when a patch is released and every time they open their browser after that until the patch is installed. How can you possibly miss patching the product? And Firefox patches aren't third party patches; they download directly from Mozilla.
So somehow it's better to wait 29 days for a patch that was created the day after the last release cycle?
The point n3td3v raised is valid though as bad guys do make malicious software appear to be a normal patch. The whole patching process for personal computers is brutally disgraceful and chaotic. But that's another topic.
Michael Horowitz
That should say: "The whole patching process for Windows based personal computers is brutally disgraceful and chaotic. "
The Mozilla download is NOT directly from the "Mozilla Project". I sincerely doubt that Mozilla has the resources, server farms, and infrastructure required to simultaneously serve up several million downloads in the span of a few days (which is what some posters here are supposing). It is instead being pushed down from several volunteer project sites. There have been Linux distributions which have had similar models - which also have had KNOWN break-ins with malicious code added to the code base.
Open Code does not make code more secure. "Volunteer" distribution does not make code more secure. Waiting for unpaid volunteers to fix bugs does not make code more secure. It's counter-logical. If anything, due to the evolving constant "patchiness" of open-source projects, there is a much greater chance that they get hijacked and abused. The projects tend to run their course over about a 5-6 year span, then interest wanes, and they get left abandoned on the side of the cyber-road. In the meantime, new products, new features, new projects evolve and invade the void which they leave behind. I don't know how many versions of Linux, for example, were supposed to be the "Windows killer". I mean, it's been around since 1990. It's still at somewhere around 2-3% (probably an optimistic number) of desktop OS's in the US. The only thing it killed was my patience.
-
by `WarpKat
September 27, 2008 8:54 PM PDT
- @n3td3v: so basically you're saying...let the user eat cake.
-
Reply to this comment
-
(8 Comments)We're talking about everyone who uses a computer, not just admins deploying patches on user workstations.
I actually hate it when Firefox updates when I'm doing something, but I totally understand why and I love the face that it's done as soon as possible.
Now, mind you - we're talking about the browser. Something MS can't seem to get right. Integrating it into Windows and making it the dominant browser by putting the "e" on the desktop for anyone to click on by DEFAULT was/is the WORST idea - EVER. Ask anyone. If they had gone the better route by saying, "Ok...let's use this browser instead and help further the development on it," we wouldn't be having this ongoing debate of IE vs. Standards vs. Security.
IE is a hole. A GAPING hole that needs to be patched whenever possible, like Mozilla does with Firefox.
How many people have infected themselves using Firefox? How many people have infected themselves using IE?
If MS can't/won't dish out the patches as often as possible instead of once a month, then they should contract with reputable companies willing to do so in a more timely fashion.
Late to patch = early to infection.
Early to patch = virtually no chance of infection.