Benjamin Lerner

Conflicts of Interest: Interactions among Browser Extensions

Papers and Downloads

Motivation

Many systems are extensible: they offer users a way to expand the capabilities of the program beyond those built in. Some extensibility is limited in scope: for example, media players allow the installation of new codecs, but do not typically allow new extensions to, say, add support for internet radio if some rudimentary support did not already exist. Other systems are nothing but extensions: the emacs text editor and the Eclipse development environment are composed of (comparatively) small kernels and suites of packages that make the kernels useful. There is a price for this flexibility, though. The greater the power of extensions, the more likely independent extensions are incompatible with each other.

Designing a system for extensibility involves several coordinated decisions, such as the scope of extension, what hooks or extension points are visible, what interactions between extensions are possible, etc. Choosing poorly on any of these axes can cripple the extension system's popularity or usefulness. Choosing a poor programming model for the extension points may make debugging extensions very difficult, precisely when they break and debugging is needed.

The Firefox web browser is built on a very widely extensible platform. Extensions can hook practically anything, at any time, leading to a very flexible, powerful model. Moreover, extensions are easy to program, involving nothing fundamentally harder than programming a web page. This has led to wildly surging popularity, with over 10 thousand extensions downloaded over 2 billion times by over 100 million users. But when these extensions conflict with each other, diagnosing the problem is particularly difficult. Firefox is therefore an ideal testbed for extension conflict: it is highly visible, very powerful, and improving it would directly help millions of users.

Approach

An extension is a self-contained piece of code that inserts itself in various places in the browser in order to implement its feature. In other words, it is very much like aspect-oriented coding, which similarly weaves advice code into a mainline program. The fundamental difference here is that extensions are always written by people other than the browser developers, whereas typically aspects are written by the mainline authors. Our first effort, therefore, has been to add aspects to Javascript, so that we can rewrite extensions more declaratively, to state explicitly what they're hooking in the browser. This work has been done in Spur, a Microsoft Research JScript compiler.

Additional work is under way to explore other forms of extension hooks, such as how overlays inject new content into HTML, and characterize the kinds of conflicts those hooks entail. Knowing this, we can begin to develop static analyses that detect weaving violations or other semantic problems, and thereby detect when extensions conflict.

Contact

download vcard icon
Email (essential):
Location (likely):
Department of Computer Science, Office 309
Post (possible):
work Post-Doctoral Research Associate Brown University / Department of Computer Science / 115 Waterman Street, 4th floor / Providence, RI 02912-1910