Criticisms of Internet Explorer

Internet Explorer is a web browser that is subjected to many criticisms. Most of the criticism concerns its security architecture and its degree of support of open standards.

Contents

Criticisms regarding security

Internet Explorer comes under heavy scrutiny from the computer security research community, in part due to its sheer ubiquity. Exploitation of Internet Explorer's security holes has earned IE the reputation as the least secure of the major browsers.

As of June 20, 2005, security advisory site Secunia counts 20 unpatched security flaws for Internet Explorer 6, many more and older than for any other browser, even in each individual criticality-level, although some of these flaws only affect Internet Explorer when running on certain versions of Windows or when running in conjunction with certain other applications.

Another advisory site SecurityFocus counts 27 unpatched security flaws for Internet Explorer 6 on Windows XP SP 2, but even many more and older on earlier versions of Windows.

See computer security for more details about the importance of unpatched known flaws.

On June 23, 2004, an attacker using compromised Microsoft IIS Web servers on major corporate sites used two previously-undiscovered security holes in IE to insert spam-sending software on an unknown number of end-user computers [1] [2] [3]. This malware became known as Download.ject and it caused users to infect their computers with a backdoor and key logger merely by viewing a web page. Infected sites included several financial sites.

Art Manion, a representative of the United States Computer Emergency Readiness Team (US-CERT) noted in a vulnerability report that the design of IE6 SP1 makes it difficult to secure. He stated that:

There are a number of significant vulnerabilities in technologies relating to the IE domain/zone security model, local file system (Local Machine Zone) trust, the Dynamic HTML (DHTML) document object model (in particular, proprietary DHTML features), the HTML Help system, MIME type determination, the graphical user interface (GUI), and ActiveX. … IE is integrated into Windows to such an extent that vulnerabilities in IE frequently provide an attacker significant access to the operating system.

Manion later clarified that most of these concerns were addressed in 2004 with the release of Windows XP Service Pack 2, and other browsers have now begun to suffer the same vulnerabilities he identified in the above CERT report. [4]

Note that Windows XP Service Pack 2 is not available for earlier versions of Windows, including Windows 9x, NT and 2000.

In addition, some security exploits associated with Internet Explorer are made possible through normal usage patterns of users of Microsoft Windows. For example, in Windows XP, it is the default system behavior to allow normal users to log into accounts with administrator privileges for everyday computer use. In this situation, an exploit which allows a cracker to run arbitrary code effectively gives away control of the entire computer. This would be the case for any browser which ran with unrestricted privileges. Because the everyday use of root accounts for normal users is rare on other operating systems, attacks which rely upon inappropriately restricted browser processes are most often targeted at Windows-based browsers. However, many programs on Windows do not work or work poorly without administrator privileges, so what are considered normal security practices on other operating systems are sometimes impractical to perform on Windows.

Many security analysts attribute IE's frequency of exploitation in part to its ubiquity, since its market dominance makes it the most obvious target. However, many critics argue that this is not the full story; the Apache HTTP Server has a much larger market share than Microsoft IIS, yet Apache has had fewer (and generally less serious) security vulnerabilities than IIS. Microsoft's Craig Mundie has admitted that Microsoft's products were "less secure than they could have been" because it was "designing with features in mind rather than security."

As a result of its many problems, some security experts, including Bruce Schneier [5] and open source advocate David A. Wheeler [6], recommend that users stop using Internet Explorer for normal browsing, and switch to a different browser instead. Several technology columnists have suggested the same [7] [8]. On July 6, 2004, US-CERT released an exploit report in which the last of seven workarounds was to use a different browser, especially when visiting untrusted sites. In December 2004, Pennsylvania State University issued an alert to students and staff telling them to drop IE and use an alternative.

Component Object Model

Many of IE's security issues are related to components based on Component Object Model (COM). The embedding of COM into the Internet Explorer via ActiveX or Browser Helper Objects (BHO) created a combination of functions that provided a gateway for computer virus, trojan and spyware infections.

These malware attacks mostly depend on ActiveX for their activation and propagation to other computers. Microsoft has recognized the problem with ActiveX since 1996 when Charles Fitzgerald, program manager of Microsoft's Java team said, "If you want security on the 'Net', unplug your computer. … We never made the claim up front that ActiveX is intrinsically secure."

ActiveX controls, once run, have all the users' privileges instead of the limited privileges granted by competing approaches (like Java and JavaScript); ActiveX controls are also non-standard and are not portable to non-Windows platforms. As pointed out by Professor Edward Felten of Princeton University:

ActiveX security relies entirely on human judgment. ActiveX programs come with digital signatures from the author of the program and anybody else who chooses to endorse the program. … The main danger in ActiveX is that you will make the wrong decision about whether to accept a program. … The most dangerous situation, though, is when the program is signed by someone you don't know anything about. You'd really like to see what this program does, but if you reject it you won't be able to see anything. … The only way to avoid this scenario is to refuse all programs, no matter how fun or interesting they sound, except programs that come from a few people you know well.

ActiveX security relies on security zones and digital signing, which are not as reliable as other measures like sandbox security model and same origin policy. It is explained in an O'Reilly book, "Malicious Mobile Code":

ActiveX's biggest problem is the way it incorrectly marks controls Safe for Scripting. Already used in several email worm attacks, these types of holes continue to appear. If Microsoft cannot correctly determine the safety and appropriateness of its own system controls, how can vendors be expected to? Following that problem is the growing use of unsigned code. The digital signing process is technical and expensive. Most ActiveX controls on the Web are unsigned. Many of those that are signed, are expired. I rarely come across a control that is signed and current. If ActiveX's security lives or dies on whether end-users correctly choose to trust or not trust unsigned controls to run, it appears doomed unless digital signing of code becomes widespread. If ActiveX controls become standardized across the world's web sites, as expected, we will surely see a rise in malicious code for ActiveX.

The security problems of ActiveX were first demonstrated in February 1997 by the Chaos Computer Club (CCC), who demonstrated an ActiveX control that could communicate with an installation of Intuit's Quicken financial software on a user's hard drive to automatically transfer money from a user's account to CCC's bank account.

The United States Department of Defense (DoD) defines ActiveX as a category 1 (maximum risk) mobile code technology, and strictly limits how ActiveX can be used in DoD systems.

Other experts stipulate that the dangers of ActiveX have been overstated and there are safeguards in place. Larry Seltzer of eWeek notes:

While there has been a striking lack of actual evidence that ActiveX is unsafe, there has been no shortage of baseless assertions and cheap shots against it. My favorite was the "Internet Exploder" incident in which Sun actually paid someone to write a malicious ActiveX control. I was there at JavaOne when they demonstrated it (I think it was 1997). The test system brought up all the warning dialogs about the program that you usually get and the Sun employee actually had the nerve to keep whacking on the enter key quickly so they would close as quickly as possible and didn't mention that there were any such warnings. Meanwhile, they also didn't mention that a signed Java applet could also perform dangerous privileged operations and would provide similar warnings. Most ActiveX criticism is simply uninformed, but this example was hypocritical and dishonest.

The forth-coming Microsoft AntiSpyware, which is currently in beta, monitors BHOs in Internet Explorer on Windows 2000, XP and Server 2003, and will warn the user before a new BHO is installed.

Patches

Critics have claimed that security fixes take too long to be released after discovery of the problems, and that the problems are not always completely fixed. After Microsoft released patches to close holes in its general operating system in February 2003, 200 days after their initial report (instead of 30-60 days), Marc Maifrett, Chief Hacking Officer of eEye Digital Security, said: "If it really took them that long technically to make (and test) the fix, then they have other problems. That's not a way to run a software company." The Register criticized Maifrett for publicizing a security hole leading to the creation of the Code Red worm, arguing that "had they not made such a grand public fuss over their .ida hole discovery and their SecureIIS product's ability to defeat it, it's a safe bet that Code Red would not have infected thousands of systems."

Microsoft attributes the perceived delays to rigorous testing. The testing matrix for Internet Explorer demonstrates the complexity and thoroughness of corporate testing procedures. The browser is released in 26 different languages on many different Windows platforms. Therefore, it is estimated that each patch is tested on at least 237 installations.

Although security patches continue to be released for a range of platforms, most patches were released for Windows XP only.

Spyware, adware and Windows XP SP2

Spyware and adware, like other malware, generally target Windows / Internet Explorer based systems. Older spyware attacks have largely been mitigated by security improvements in Windows XP SP2, but newer attacks against Internet Explorer allow the installation of spyware on SP2. Microsoft advises against installing SP2 on a system which is already infested with spyware, as it can cause the system to become unbootable:

Failure to clean up spyware and adware on your computer before installing SP2 can cause issues and in some cases make your computer difficult to restart. You may not even know that spyware or adware programs are installed on your system. And some spyware or adware programs may not cause serious issues with SP2, but it's a good idea to run spyware and adware removal programs before installing SP2.

Depending on the type of spyware installed, removing it in preparation for an SP2 upgrade can be as simple as running an anti-spyware tool, or in serious cases require manual editing of the Windows Registry. Nevertheless, security experts generally recommend installing Service Pack 2.

Criticisms regarding support of open standards

During the browser wars of the late 1990s, modifications of Internet Explorer and Netscape Navigator were focused on the addition of non-standard features. This is in contrast to more recent browsers which have been designed with web standards in mind. Since version 5, there have been no significant changes in IE's Trident rendering engine. As a result, as of 2005, IE lags behind in support for standards.

Although each version of IE has improved standards support, including the introduction of a "standards-compliant mode" in version 6, the core standards that are used to build web pages (HTML and CSS) are still implemented in an incomplete and incorrect fashion. For example, there is no support for the <abbr> element which is part of the HTML 4.01 standard, and there are bugs in the implementation of float-margins for the CSS1 standard. The Internet Explorer box model bug is one of the best-known bugs in Internet Explorer's implementation of CSS.

Because of its market dominance, some web developers only test their websites with Internet Explorer. Some developers also use non-standard extensions offered by Internet Explorer. This can cause pages to be rendered incorrectly in other browsers. In the worst case, it could block the users of other browsers from accessing the sites created by such developers. Critics feel that this is the execution of the final step of embrace, extend and extinguish (EEE): the extinguish stage.

Graphics standards

Image:IE PNG bug.png
The lack of support of PNG alpha channel prior to 7.0

The lack of support for PNG alpha channel results in a reduced usage of the PNG image format on web pages. Alpha channel is a feature that, although being an optional part of the specification, distinguishes PNG from other formats like GIF or JPEG. In Internet Explorer, the transparent part of the image will be displayed as gray, white or other colors, depending on the image editor in which the PNG image was created. Microsoft documented a workaround on its support website [9], and the IE developers are aware of the missing functionality, as evidenced by a posting on IE developer Dave Massey's weblog [10]. This issue will be fixed in the upcoming version 7. Another less known bug is that when the PNG file is either 4097 or 4098 bytes in size, the image will be ignored and only the picture placeholder image will appear [11].

Other than PNG, Internet Explorer also does not support progressive display of progressive JPEG [12]. Progressive JPEG divides the file into a series of scans. The user agent should display progressive JPEG from lower quality scans to higher quality scans during transmission of the file. The user should see a gradual improvement of the quality of the image. Similar interlacing problem happens on PNG, where the 2D interlaced PNG is rendered as 1D interlacing.

Interlacing or progressive display was quite useful in the past since many users (especially home users) were on dial-up access where the bandwidth is very limiting. However, in Internet Explorer the image was not rendered until the completion of download. Fortunately this problem is less significant now due to the introduction of Broadband Internet access.

XHTML

Internet Explorer's support of XHTML (the successor to the standard document markup language HTML) is incomplete, although no claim of any XHTML support was ever made. Rather, XHTML 1.0 was intentionally designed to be usable by HTML 4.0 user agents, like Internet Explorer, if certain document authoring guidelines for backward compatibility were followed. Furthermore, when accessing XHTML documents over a network, such support by non-XHTML-aware browsers is predicated on the documents being served with a MIME type of text/html. To the extent that these requirements are met, IE supports XHTML. XHTML has since matured, and it is now possible to author modular documents that cannot be rendered in a non-XHTML-aware browser like Internet Explorer. Furthermore, the use of the text/html MIME type is now deprecated in favor of application/xhtml+xml. Internet Explorer does not recognize this MIME type, so instead of rendering the page, a file download prompt is presented to the user. It is possible to force IE to show application/xhtml+xml pages as either HTML or generic XML, but this workaround involves the manual editing of Windows registry [13]. By forcing XHTML to be interpreted as HTML, it also removes the advantages of using an XML parser, like well-formedness checking. Despite the advent of application/xhtml+xml, many XHTML documents on the web are still served with the text/html type in order to make XHTML documents renderable in Internet Explorer. Some consider this practice harmful as it could result in proliferation of malformatted XHTML documents [14].

HTTP and MIME

Unlike other browsers, Internet Explorer does not obey MIME types specified in the MIME Content-Type header. For example, a document sent as text/plain containing HTML-like tags will be interpreted as a HTML document, while it was intended to be displayed as a plain text document. For this example, it is possible to change this behavior by manually editing the registry, a thing that most regular users will not / can not do.

Internet Explorer does not fully support HTTP/1.1 content negotiation, because the browser does not specify, in its requests, what MIME type and character encodings it can accept. Content negotiation is a technique whereby an HTTP server uses the browser's—ultimately, the user's—preferences for media (MIME) type, languages, character encoding, and transfer encoding (for example, compression) in order to determine the best representation of a resource to send to a user agent, when multiple representations are available. An example would be the negotiation of image format (such as SVG, PNG, or GIF), and document format (WML, XHTML, or HTML, for instance).

CSS

Some argue that CSS support in Internet Explorer is far less adequate than feature checklists suggest. While Internet Explorer recognizes the vast majority of CSS Level 1 features, it routinely misinterprets them in most surprising and unexpected ways. Therefore, Internet Explorer's support of CSS Level 1 should be considered partial and inadequate. Internet Explorer offers virtually no support for new features of CSS Level 2 (inline-block and vertical-align: middle being the notable exceptions), therefore its level of CSS Level 2 conformance is best described as "larval".

JavaScript and DOM

Microsoft have extended Netscape's original JavaScript specification to create an implementation called JScript, which is the default scripting language interpreted in Internet Explorer. Like Netscape's JavaScript implementation, JScript supports the full specification of ECMAScript, the only standardised scripting language on the Web.

What is more different is the Document Object Model (DOM) bound with JScript. While all browsers have their own implementation of DOM Level 0 (vendor-specific), Internet Explorer implemented only some of the W3C recommended DOM Levels (1, 2 and 3). In addition, before DOM Level 2 was finalized, IE implemented some proprietary extensions to DOM which are similar, but not identical, to those in DOM Level 2. Most of these proprietary extensions are not accepted by the W3C. As the corresponding (finalized) DOM Level 2 objects and methods are not implemented in Internet Explorer due to the slowdown of development since version 6, problems arise when trying to write scripts that work on any browser. Web developers often need to write extra code so that the scripts will work on both Internet Explorer and on browsers that correctly implement the W3C standards. This duplication increases development effort, results in code bloat, and makes code maintenance harder.

Plugin API

It did for a time support Netscape's NPAPI. Plugins that functioned in the Netscape browser also functioned in Internet Explorer, but the support was dropped in version 5.5 SP2 in favor of Micorosft's own proprietary ActiveX technology, which unnecessarily increased the workload of vendors of helper applications like QuickTime.

Unicode

Main article: Unicode and HTML

Internet Explorer supports the Unicode standard for multilingual text, and is therefore theoretically capable of displaying any character which is present in an installed font. In practice, Internet Explorer does not automatically choose fonts for blocks of mixed Unicode text. Characters can end up displayed as blank squares or question marks.

Web designers must guess which appropriate fonts may be present on users' computers, and manually specify them for every change of Unicode block. In contrast, most other browsers do this automatically.

Workarounds

To get around these problems, many web designers build websites compliant to W3C standards, and then implement workarounds or hacks to account for Internet Explorer's rendering inadequacies, or to hide advanced website features from IE. The CSS hacks are often very complicated, as they need to deal with different versions of IE on different platforms (mostly Windows and Mac). The hacks utilize not just Internet Explorer-specific features, but also some rendering-engine bugs that are well known. Some of the more common hacks:

One of the most popular IE hack collections is known as IE7 [15], written by Dean Edwards. It is an attempt to make Internet Explorer more compliant when it comes to web standards. In addition to the support of some CSS2 selectors, it also fixes some of the IE bugs. However, as many client-side scripts need to be loaded and run before displaying the page properly, there is a considerable amount of loading time needed for every single page.

Other criticisms

Over the versions, the download size of Internet Explorer has increased significantly. As of Internet Explorer 6 Service Pack 1 (including Outlook Express), the total download size for a typical installation was approximately 25 megabytes. The size varied between 11 (minimal install) and 75 MB (full install). This was much larger than that of some internet suites, for example (based on Windows installer) Opera 8.0 (3.6MB), and Mozilla Suite 1.7.8 (11MB).

A minor, yet significant, criticism is the use of the word Internet in the software name. Strictly speaking, Internet Explorer is a web browser designed for the World Wide Web, not the whole Internet (which also includes e-mail, Usenet, telnet, IRC, etc). Because of the misleading use of "Internet" to represent the "World Wide Web", many users without much understanding of the Internet may think that Internet Explorer is the only way to access the Internet.

Footnotes

  1. ^  PNG Files Do Not Show Transparency in Internet Explorer, February 13, 2005.
  2. ^  Transparent PNG Support, May 12, 2005.
  3. ^  Cannot View Some PNG Images, May 12, 2005.
  4. ^  PHP: imageinterlace, May 12, 2005.
  5. ^  Forcing IE to Show Application/xhtml+xml pages, May 12, 2005.
  6. ^  Sending XHTML as text/html Considered Harmful, February 13, 2005.
  7. ^  /IE7/, May 12, 2005.
  8. ^  Researchers warn of infectious Web sites, May 12, 2005.
  9. ^  Handler's Diary May 11th 2005, May 12, 2005.
  10. ^  An analysis of the Ilookup Trojan, May 12, 2005.
  11. ^  Safe Personal Computing, May 12, 2005.
  12. ^  Securing Microsoft Windows (for Home and Small Business Users), May 12, 2005.
  13. ^  How to Protect Yourself From Vandals, Viruses If You Use Windows, May 12, 2005.
  14. ^  Internet Explorer Is Too Dangerous to Keep Using, May 12, 2005.

See also

External links