Does this site look plain?

This site uses advanced css techniques

Firefox -vs- IE Internet Explorer has had a long reputation for being insecure, and much of this criticism has historically been entirely deserved (though less so lately). One area of particular criticism has been IE's support for ActiveX.

Table of Contents

This is widely hailed as one of the worst features of IE, and the fact that no other major browser supports ActiveX is seen as an automatic plus in the security column for those other browsers.

This claim is literally true, but only in name: all useful browsers support multiple extension mechanisms, including those which allow for full code execution by the plugin via a DLL. Though there are differences (including ones that affect security), the similarities are far greater than the differences, and it's not entirely clear that IE is any worse at all in this respect.

In this paper we'll explore the extension mechanisms of two major browsers, Internet Explorer 6 and Firefox 2, and see that there's more in common that it seems. Though Firefox is a cross-platform product, our main focus is on the Windows implementation where it can be contrasted properly with IE.

We are considering IE6 on XP/SP2 — this is a mature platform — and we are not considering IE7: IE7 is superior from a security point of view, and we'd rather make our case with the more widely deployed (and criticized!) platform of IE6.

Internet Explorer

At its core, IE requires executable code for all meaningful extensions, and in this respect presents a more consistent (though more difficult to develop) mechanism. Though extensions are often identified simply as "ActiveX Controls", they can actually take multiple forms internally as they serve different purposes.

Browser Extensions
These are the largest of the bunch, and implement the widest ranging functionality, such as the Java runtime environment. These can provide support for new filetypes (say, a new music format), as well as other broad features.
Browser Help Objects
These extend the browser in more narrow ways, such as intercepting a URL as entered by the user and manipulating it in some way — this is how search assistants work (take user text, pass to some central server, and return an updated URL to actually use).
These have been abused by spyware to silently send a copy of every URL typed by a user a remote server, allowing tracking of browsing habits.
Because it integrates into the event model, it's somewhat easier to build a BHO than a full-blown extension, but it typically serves a more limited purpose.
These provide the familiar information bars at the top of many browser windows, such as the popular and helpful Google Toolbar. And it's been sadly noted that finding a user's browser with a half dozen toolbars is almost always a sure sign of a serious malware infection.

There is a somewhat blurry line between these various categories, mainly because they all share a common programming interface, but all of them bear executable code. Any can be used for good or nefarious purposes.


Firefox is a very popular Open Source browser with good cross-platform support, and it's widely viewed to be more secure than IE.

Firefox supports two broad categories of add-ins: extensions and plugins. They are related, but separate. We'll discuss both.


Extensions are used to produce an enormous variety of useful utilities that enhance the browsing experience. A whole industry has sprung up around these extensions, including some incredibly popular efforts such as Greasemonkey (for customizing pages you're viewing) and Web Developer (for supporting HTML/CSS coding).

Most Firefox extensions are written in XUL and Javascript. XML User Interface Language (XUL, pronounced "zool") is used for creating user interfaces, and the browser itself uses XUL to define how it behaves. XUL works hand in hand with Javascript (and HTML and CSS), and is sufficiently powerful to perform the great-bulk of add-in activities.

XUL, Javascript, HTML, and CSS are all fully sandboxed, which dramatically limits what they can do outside the browser. There are provisions for extensions to interact with the filesystem and other system objects, but they are limited.

But some tasks simply require more integration with the operating system than Javascript and XUL can provide, so some extensions include XPCOM Components.

XPCOM is the Cross-Platform Component Object Model, and it's designed to provide a modular software framework. It's provided in binary object form (a DLL for Windows, a shared object for *ix), and in this respect runs with full access to the underlying operating system.

When an XPCOM component is used, it's virtually always accompanied by other extension pieces (Javascript, XUL, HTML, CSS, images, etc.) in an .XPI installation bundle.

We'll touch on the installation mechanisms later.


Somewhat different from extensions are plugins, which assist with more specific media rendering rather than the broader functionality provided by Javascript or XPCOM.

Plugins are typically much larger efforts and support features recognized by anyone who's surfed the web for any amount of time:

These are always provided in binary formats (DLL or .so) rather than Javascript/XUL, and are rarely open sourced. Because they are executable, they can do anything a .EXE can do as the user running the browser. They do not usually include extension-like accessories (Javascript, XUL, or the like).

Plugins are usually associated with software running outside of the browser — such as the Adobe Acrobat reader — so the plugin are sometimes little more than "glue" linking the browser with the real application.

It appears that plugin installation is accomplished by the larger application installer dropping a DLL in the plugins\ directory, and it serves as the bridge between the browser and the application core - they are loaded at startup.

Comparing installation of add-ins

It's clear that add-ins aren't going to be useful until they're installed, and in the past this had been a weak point of IE: the drive-by install. When malware can install itself without clear notice and approval, then the user really has no hope of a safe and secure surfing experience.

Both browsers support installing of extensions from within the browser enviroment itself, plus running a .EXE with a traditional installer. We're only discussing the former, because the latter always involves an intentional act outside the scope of control of the browser.

Installation: Firefox

Firefox provides a consistent interface for installing extensions via a .XPI file: these are simply ZIP archives that expect to have an install.js Javascript file to drive the installation.

Examining one popular web-development extension, Aardvark, we can look inside the XPI with the standard Linux unzip program to see what's there (we've omitted 19 Mac OS-related files for brevity: XPI is a cross-platform installer), along with the prompt provided by Firefox when installing it: installing Aardvark

$ unzip -l aardvark-2.0-fx.xpi
Archive:  aardvark-2.0-fx.xpi
  Length     Date   Time    Name
 --------    ----   ----    ----
      270  12-14-06 17:22   chrome.manifest
        0  12-14-06 17:57   content/
     6148  12-14-06 17:52   content/.DS_Store
      560  08-04-06 18:05   content/aardvark.gif
    13596  12-14-06 23:05   content/aardvarkCommands.js
     4713  12-14-06 18:01   content/aardvarkDBox.js
     1929  07-26-06 16:29   content/aardvarkhelp.gif
    13452  12-14-06 23:49   content/aardvarkMain.js
     3872  12-12-06 21:45   content/aardvarkUtils.js
      222  07-26-06 17:59   content/closedbox.gif
     1314  12-14-06 17:31   content/firefoxOverlay.xul
        0  12-14-06 15:22   defaults/
        0  12-14-06 15:22   defaults/preferences/
      158  12-14-06 19:50   defaults/preferences/aardvark.js
      879  12-16-06 14:22   install.rdf
        0  12-14-06 15:22   locale/
        0  12-14-06 15:22   locale/en-US/
      225  12-14-06 17:53   locale/en-US/aardvark.dtd
      139  12-14-06 17:54   locale/en-US/
        0  12-14-06 17:48   skin/
     6148  12-14-06 17:48   skin/.DS_Store
      242  12-14-06 18:39   skin/overlay.css
      188  08-07-06 16:40   skin/toolbar-button.gif

Installation happens quickly, and after restaring the browser, the features of Aardvark are available (once started, hovering over a block-level element reveals the properties of that element).

No executable code is included in Aardvark.

Turning to a second example, Tab Effect, we see a very small XPI file (~40kbyte) that nevertheless contains an XPCOM component to supports its operation: Tab Effect install dialog

$ unzip -l tab_effect-1.1-fx.xpi
Archive:  tab_effect-1.1-fx.xpi
  Length     Date   Time    Name
 --------    ----   ----    ----
      113  01-02-07 06:33   chrome.manifest
        0  01-08-07 06:30   components/
      216  01-11-07 06:31   components/ITabEffect.idl
      167  01-11-07 06:31   components/ITabEffect.xpt
    94208  01-11-07 06:31   components/tab_effect_xpcom.dll
        0  01-09-07 08:31   content/
      306  01-08-07 04:20   content/browser.xul
      896  01-08-07 06:09   content/config.xul
      982  01-09-07 16:34   content/javascript.js
      814  01-09-07 07:19   install.rdf
 --------                   -------
    97702                   10 files

The installation process is identical, and no indication is given that this extension contains executable code.

Plugins, on the other hand, do not go through this mechanism, and it does not appear that Firefox is directly involved in the installation process at all. Instead, the application providing the plugin does all the work during its installation process, with the plugin being just one part of the process (dropping the DLL into the plugins\ directory).

We'll note that Firefox may well serve as the vehicle for installation (by downloading and running a .EXE or .MSI installer), but it's not generally aware that the installer is going to have any effect on Firefox. Instead, it's just providing a generic download-and-run service.

It appear that Firefox is entirely uninvolved/unaware of plugin installation until it restarts and finds the DLL in its plugins\ directory.

We have not found a way to disable a plugin save for going to the directory and moving or removing the DLL (as of Firefox

Installation: IE

IE gold bar Installation of IE addins is done either by ActiveX control (via the browser itself), or by running an executable installer (.EXE), which works outside the browswer environment. What's important is that all addins bear executable code.

IE6 in XP/SP2 introduced a much more restrictive (and consistent) environment environment for installing ActiveX controls, requiring usually two separate user actions to approve one. This starts with the "gold bar" that appears at the top of the browser window.

Many web pages that wish to install an ActiveX control include detailed instructions, as we can see here: though the highlighted gold bar at the top is provided by IE, the rest of the page is standard HTML hosted by the webserver. This example is clearly attempting to help the user install the control (for good or for bad).

In order to actually install the control, one must right-click the gold bar and select Install ActiveX Control, as illustrated on the web page providing the control.

But for most ActiveX controls, there's another step — the Security Warning confirmation. This dialog box provides the name of the control, the publisher, and links to more information.

confirm ActiveX

Only after clicking [Install] is the component given a chance to run.

There are exceptions to the security warning dialog box: a user can whitelist controls from particular vendors ("Always install software from Fun Web Products"), and they can be blacklisted as well.

We'll note that even for .EXE-based installers, a similar gold bar warning appears as well, making it difficult for software to make it onto the machine without notice.


Once an add-on has been installed (via whatever mechanism), all browsers provide for at least some level of management or maintenance from within the browser environment itself, though perhaps not comprehensively.

Here we visit the mechanisms by which a user can control the add-ins.

Management: Firefox

Managing Firefox Addons Firefox provides an nice manager via the Tools » Add-ons menu, and it shows all the extensions currently loaded, as well as the ability to uninstall or disable each one. Plugins from a previous upgrade that are no longer compatible are shown in their disabled state and allow for removal or upgrade.

A helpful link brings you to the central Mozilla site for all extensions, allowing for finding new and interesting add-ons.

This interface also provides actual interaction with the extension via an Options button (if supported by the extension itself). This is a convenient, centralized configuration mechanism.

It's not apparently, however, just what goes into this extension or whether it includes a code-bearing DLL or not.

In addition, plugins do not show up here: they are found only in the URL about:plugins, producing a page which looks like:

About Firefox Plugins

But this is a readonly display: actually removing the plugin cannot be done from within Firefox. Instead, one must navigate via Explorer and delete or move them manually. We found this very surprising.

Management: IE

Prior to XP Service Pack 2, IE provided no real way to find out which add-ins were loaded, and this made it easy for malware to hide and maddeningly difficult to track down.

But with XP/SP2, IE6 now provides a full-fledged management control panel via the Tools » Manage Add-ons... menu option, and it provides complete exposure to every possible kind of add-in.

About IE Addons

Unlike Firefox, this is a one-stop shop for addin management. We don't believe it's possible to extend IE without it showing up here, and it includes the name of the code-bearing DLL, a remarkably helpful feature when trying to figure out what that unknown DLL is used for.

In addition, all kinds of add-ins can be disabled from this control panel, including things like Acrobat, Quicktime, and Java. Firefox provides no mechanism to do this.

One minor nit: it doesn't seem possible to resize the management dialog box, which is never big enough, so we end up doing lots of scrolling around. Firefox's management box is resizable.

Conclusions and Summary

We take the position that code-bearing add-ons are more dangerous than those without an executable component, and this is a distinction we believe should be made more strongly.

We can make these general observations:

After researching this in some detail, we are surprised by the weaknesses of the Firefox model. Though ActiveX has been decried as the worst part of IE, and should be eliminated from the browser entirely, we fail to see how it's really that different in Firefox - both provide mechanisms to extend the browser in useful (and not useful) ways.

Prior versions of IE have been prone to "drive-by" installs, and we certainly believe that allowing the bad guy to install and run a DLL without user interaction is a security abomination. We understand that this has been more or less completely addressed by IE 6 in XP/SP2.

Unsophisticated users are much more likely to be victims of their own ignorance (purposely installing software that ends up being malware), and this can happen with any browser having an extension mechanism.

But a thoughtful and educated user is likely to be just as safe using either one, so one ought to choose his/her product based on features, not security.

First published: 2007/07/01