The diary and photos of Chris Beach. I'm into windsurfing, coding, badminton, drawing and composing music using computers and synths.

Let's start with a quote:
"I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours" Stephen Roberts


email: password:
Sign in with Google

resilience of rendering engines in internet explorer vs firefox and opera

There's bad markup all over the net. Unlike program code, which is strictly compiled or interpreted, HTML webpages are merely parsed by a browser to extract content. Until recently this hasn't been a problem. The market dominating browser, Internet Explorer has a very resilient and flexible parser that will deal with most crap that the web can throw at it. However, several new bespoke rendering engines have become popular on the net including Gecko (Mozilla, Phoenix/Firebird/Firefox) and KHTML (Konqueror, Safari). These rendering engines, for better or worse, have stricter, less versatile parsers, which means they will fail to render certain sites as the designer intended. For example, browsing www.asda.com in Firefox currently shows no shopping aisle options and is therefore unusable. The Odeon website shows nothing but a background image in Firefox. But the problems get more serious than simple rendering inconsistency:

I was interested to read a BugTraq submission by Michael Zalewski that compares the resilience of various browsers against bad markup. He has written a program which fires pieces of malformed HTML at various browsers, with no human intervention (except in the case of a browser crash). Michael sums up the results:

All browsers but Microsoft Internet Explorer kept crashing on a regular basis due to NULL pointer references, memory corruption, buffer overflows, sometimes memory exhaustion; taking several minutes on average to encounter a tag they couldn't parse.
It appears that the overall quality of code, and more importantly, the amount of QA, on various browsers touted as "secure", is not up to par with MSIE; the type of a test I performed requires no human interaction and involves nearly no effort. Only MSIE appears to be able to consistently handle malformed input well, suggesting this is the only program that underwent rudimentary security QA testing with a similar fuzz utility.
BugTraq Submission by Michael Zalewski

This may come as a surprise to people who have read the recent media hype about Firefox, which is touted as a more secure and robust alternative to Internet Explorer. However, the IE test manager offers an explanation:

I cannot speak for the other browsers talked about in this report, but I can speak to the IE portion of this report. It is no accident that IE is responding this way to the tests that were run against it because we intentionally take a number of steps to make IE resilient.

At the end of the product cycle for Windows 2000 and as part of the Secure Windows Initiative, Microsoft developed a set of tools called Prefix and Prefast to do dynamic source code inspection, which helps scour the source code for bad code and bad coding practices such as null pointer dereferences. These tools help us find obscure crashing code paths that manual code inspection may miss.
IEBlog entry by Scott Stearns, IE test manager

Microsoft have made Prefix and Prefast publically available. Perhaps Mozilla would consider swallowing its pride and running them on Firefox?

written by Chris Beach
28/10/04 6:23pm
(9 years, 6 months ago)
comment 3 comments

photoadd photo

 7 links
more journal entries from tech journal