A Bad Month for Firefox 195
marty writes "Februrary is not a good month for Mozilla developers. Infoworld reports about the efforts of Polish researcher Michael Zalewski, who apparently kept finding new vulnerabilities in the popular browser on a daily basis through the month, first postponing the 2.0.0.2 update, and then finding a remotely exploitable flaw in it immediately after its release."
Re:What's worse? (Score:5, Interesting)
Some people like the press it gets for finding them too.
That being said, some projects react bad to bugs. GCC is an example of a group who react well to them. I've had several PR's fixed because of a simple ICE or asm dump I sent in. Whereas in the Linux camp, bug fixing is a royal right only a few can have. When I wanted to add device IDs for Intel NICs to the 2.6.18.2 [iirc] kernel I submitted a patch which added them. It was refused saying that they would be added in the next major release cycle. Even after I told them that they could trivially be added to the next point release they still refused. Oddly enough the maintainer, a Gentoo developer, added them to the gentoo brand of the kernel anyways. Go co-operation!
I dunno, for me it's a sense of responsibility. If I'm going to release software that can potentially cause problems for others, I make sure I respond to valid reports as soon as possible. I don't look at it as a negative experience because for me the alternative is to stop sharing the code alltogether.
Tom
Re:How is this bad? (Score:3, Interesting)
It's quite hard to tell for the user if they're fixing many bugs because they have a high attention to security or if their code is a stinking pile of shit. Ideally, not a single bug should get through to the end user but they do, in that sense every bug that needs fixing is an imperfection in the development process. The users don't have any omniscent metric of which browser is the most secure and bugfree. So, the user is trying to figure out some sort of substitute metric. The most typical one used is to assume that "number of bugs fixed" is proportional to "number of bugs to fix". Of course, that's not true because "number of bugs to fix" is "public bugs and to be fixed" + "bugs to be silently fixed" + "bugs that aren't found yet", possibly because noone's looking.
To take the typical slashdot meme:
IE fixes a dozen bugs: "Whaaaaaaaaaa! IE is such a pile of steaming shit"
FF fixes a dozen bugs: "Yeeeeeeeeeey! FF is showing their attention to security"
Perhaps you "know" this to be the truth, but there's no facts to back you up. If on the other hand you can point to "There has consistently been fewer bugs to fix in Firefox compared to IE" along with "There has consistantly been fewer actual exploits in Firefox compared to IE" (ie, we're not just ignoring the problem) then you'll have a much better case. Of course that would require honestly in numbers, plus all the FUD about market share == target and so on, but one thing remains certain. If there weren't any bugs to fix, that'd be the best both technically and for PR.
Hard to reproduce (Score:3, Interesting)
If anyone can reproduce it consistently, and has a 1.8 debug branch build, it would be great if he could try and give a useful stacktrace in the bug.
Re:Bad month ends up with a good product. (Score:3, Interesting)
I like and use Firefox too, but I don't think security is a good reason to like Firefox. The great plugins are what puts it head+shoulders above anything else, imho. And with NoScript, AdBlock, etc, it makes it much easier to avoid malicious sites.
Anyway, It's not right to be so complacent, when a hole is found in MS software it's terrible, but when holes are found day after day in Firefox it's progress. It's the same with Apple and MS; the double standards some posters have can make
Re:What's worse? (Score:5, Interesting)
My complaint isn't that they weren't added, it's that the maintainer refused to add them to the vanilla kernel [e.g. at kernel.org] and instead horded them for Gentoo-sources [even though I run gentoo I still feel this is wrong]. Eventually at the next major release they were added. So it's not that the device IDs were wrong or caused problems. It's that the developer didn't want to share them with the rest of the Linux crowd.
Or more to the point: the maintainer knew they would never be accepted into the stable branch kernel until, at the very least, they were tested in the dev branch first.
The maintainer doesn't have the final say. It's the stable team that decides in the end and they have only gotten more strict now that there are shorter dev cycles. Also, I didn't say that they did cause problems I said they could in theory cause problems and there is no way to know for sure until the new ids have been well tested. The change was quite probably safe but I'm astounded your whining that they would not throw improperly tested code right into the stable branch. I've seen simple device ID additions cause crashes. I've had them crash MY system. It's rare but it happens. That's why I update my servers with the stable branch and run my personal stuff on the more cutting edge devel kernels.
You should ask Jean-Luc Cooke about his experience trying to replace the horrible /dev/random device with one based on Fortuna. He got the same royal decreed from Ted T'so about "who owns the kernel" and who doesn't. In the end, Jean-Luc just gave up and withdrew the patches.
/dev/random has to be as hard to predict as possible. You claim it's horrible but there are whole papers on how to random generate numbers and even seasoned kernel devs have had patches refused patches because they weren't able to justify them properly.
The kernel is, for the most part, a horribly written, and poorly maintain piece of code. The maintainers are selfish ego-hording losers and have to really learn there is more people willing to contribute then just them.
Translation: They didn't let me do what I want to they are a bunch of jerks
There are people who dedicate themselves to teaching new people how to add patches to the kernel. The whole kernel newbies project and the kernel janitors project exist to provide developers who new to kernel programming an easy way to learn their way around and get patches accepted. There have been hundreds of patches in the past few months that were accepted from people who were previously unknown to kernel programming. So it really is open to others but only people willing to follow the rules. Those rules are there for a reason.
Re:Bottom line (Score:3, Interesting)
(insert devil's advocate)
But for how much longer? the more positive attention fox draws from the unwashed masses, the more negative attention will turn in that direction from malware developers. If you go from 5% marketshare to 25% marketshare - your percentage of people looking for and finding bugs for good would drop through the floor. Think of it like this - Maybe one out of every ten of my FFX using friends actually do any app-dev work. Is that accurate? Maybe 10% of all users? If more 'regular people' started using FFX, ditching IE, you think you're still going to have 10%? Safari and FFx are safe for now, because they're not being targeted by hundreds/thousands/millions.
Compare against the best. (Score:3, Interesting)
Maybe Firefox 2 is faster than Firefox 1.5. But compared to Opera, Konqueror and Safari, it's still quite slow and extremely bloated. Apparently it's also quite insecure, too.
KDE 4 is getting very close to being released. It's native support for Windows will bring Konqueror to a whole new audience, thus drastically changing the Windows browser landscape. Unless the Firefox developers really get their asses in gear, which apparently isn't happening, Konqueror will come along and smite Firefox.
If the beta released today is any indication of what the final KDE 4 release will be like, then Firefox had better watch out. This new version of Konqueror already has the speed. It has the stability. It has extremely low memory usage (but still higher than Opera). I don't know if Firefox will be able to compete unless a massive rewrite is undertaken. But if they do wish to remain competitive, they'd better get going.
just rude (Score:4, Interesting)
Most Critical Firefox Flaw Remains Unzapped (Score:2, Interesting)
Interesting read at http://securitywatch.eweek.com/open_source/all_th
Re:Compare against the best. (Score:4, Interesting)
Nowadays if some page's slow to load I think "slow page" instead of "slow browser".
OTOH I use *lots* of tabs and there are major differences in memory consumption. On my PC Opera needs about 250-350MB of RAM for 100 tabs, Konqueror 400 and Firefox between 800 and 1.5GB.
Re:Bad month, but... (Score:3, Interesting)
Yes, the codebase for Seamonkey will be slightly behind that for Firefox. I see that as a good thing, as it weeds out most of the x.0 type bugs, and makes Seamonkey a more mature product.
Regards,
--
*Art