Benjamin Lerner

Conflicts of Interest: Interactions among Browser Extensions

Papers and Downloads

• Detecting Conflicts Among Declarative UI Extensions, DLS 2012
• Modeling and Reasoning about DOM Events, WebApps 2012
• Designing for Extensibility and Planning for Conflict: Experiments in Web-Browser Design, Ph.D. dissertation, July 2011
• C3: An Experimental, Extensible, Reconfigurable Platform for HTML-based Applications, WebApps 2011
• Weaving Code Extensions into JavaScript, Industrial Affiliates Days, 2010
• Supporting Dynamic, Third-Party Code Customizations in JavaScript Using Aspects, OOPSLA 2010
• Language Support for Extensible Web Browsers, APLWACA 2010
• Full Disclosure: Advice for Web Extensions, Industrial Affiliates Days, 2009
• Conflicts of Interest: Approaches to Extensible System Design, generals exam, April 2009

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.