## Wednesday, May 11, 2005

### Firefox: critical bugs

It seems that less than 50 percent of the visitors of this blog come here with Microsoft Internet Explorer; most of them have Safari and especially various versions of Mozilla and Firefox.

This message is addressed especially to those with the idealist beliefs that Firefox is safer than MSIE. Two very critical security bugs have been found in Firefox:

Patches have not been created yet; see Mozilla's announcement. The users are recommended to turn off Javascript. The Reference Frame also recommends you to use MSIE if you can - until your Firefox is patched.

1. Hey Lubos, I see that OVV have put out a new version of their preprint. Am I correct in saying that the only change is in the title? And that you had something to do with that? :-)

2. The old joke runs a Microsoft speakerman giving an speech against Mozilla et friends:

"You know, these guys just release new and new versions of the software as they write it, waiting for the users to find the bugs and report back to them. On the other hand, we in Microsoft... er... hmm..., yes..., it is an amazing coincidence!."

3. No one writes bug free software. Frankly I think Microsoft is doing pretty good in producing software that contains as less bug as possible.

On the other hand scientific computing software are amoung the easiest to write. All these type of software takes some very specific inputs, carry out some very specific and well defined math operations, and output the calculation result. And there is no fancy Graphical User Interface requirement. At most you do is display a 3-D plot. Using industry standard, software product as easy as this type should be nearly 100% bug free.

Out of curiosity I had a look at the LIGO software to see how they did it.

What I can tell you is their code is completely horrible! That I do not want to have a second look at them. Absolutely messy! And it's a perfect recipe for introducing code bugs. It's written in such a terrible way that I guess the guys who wrote them are permanently safe on their positions. Because there is little hope some other people can come aboard and look at their code, and know what it does.

Not a single 'const" qualifier are ever used in any function call throughout the whole package, which contains a couple million lines of source code. A junior programmer could understand that by proper use of 'const' along, it would help identify and eliminate 90% of potential code bugs.

Tons of use of union's every where, a clear indication of the 1970's -ish programming style. Because of the type safety problem, which those folks clearly do not understand. All programmers in the industry know to avoid using union's where possible.

Not even the physics part is correct. Here is a file that lists all physics constants. Check it against the latest data from NIST. Many constants are off by a large margin. Noticeable the gravition constant, for example:

http://www.lsc-group.phys.uwm.edu/daswg/docs/technical/LALConstants.h

Quantoken

http://www.lsc-group.phys.uwm.edu/daswg/docs/technical/LALConstants.h

5. Dear F. Uckoff,

I asked Cumrun and it seems that the answer to your last question is more or less yes. ;-)

All the best
Lubos

6. Lubos:
Your computer is perfectly safe. As you are still running on analog modems, as you claimed, why would any hacker bother to attack your machine and turn it into a zombie?

Torbjorn said:
"By the way, Windows insecurity takes ever more serious forms.

An application program I recently developed in compiled Labview + Matlab + C on W2k/WXP to interface with a commercial QCM equipment for trace analysis has one main state that creates about 20 page faults per second.

The result is 100 % percent CPU loading, resulting in customer WXP laptops overheating and randomly shutdown in 1-2 hours.

I think I will get back to do physics research, that was an easier if not as well paid occupation!"

20 page faults per second is absolutely crappy software. But it nothing to do with security. You need to know a little bit hardware to be able to write code of good performance.

Quantoken

7. I asked Cumrun and it seems that the answer to your last question is more or less yes. ;-)

Well, I'm glad that you have such a positive influence on OVV! I think you should ask them to put your name on the paper.... :-)

What about the first question? Are there any other changes?

8. Yes, its crappy. Its not my crap however, as far as we can see. (Having several languages _is_ my crap, but it was forced to be a fast prototyping GUI (Labview) and fast prototyping analysis (Matlab).)

My point was that the Linux OS does very well with the software, and that the laptop itself should not overheat.

As for the hardware I have done everything from research on thin film processes to designing bipolars to VLSI process integration to designing embedded systems. So don't worry about me! ;-)

Lets worry about you instead. As in physics you are far off the reality track.

There is no such thing as '100 % bug free'; instead first write is typically 20 % bugs (1 bug every 5 lines), even when developing 'scientific computing software'.

It is hard to lower that to acceptable levels, much like trying to develop a VLSI, which may take 3-4 design rewrites.

But there is a common procedure to do this. One test against reality, something that you probably has a hard time to understand. This is presumably done with LIGO software.