C3: An Experimental, Extensible, Reconfigurable Platform for HTML-basedApplications

Benjamin S. Lerner Brian BurgUniversity of Washington

Herman Venter Wolfram SchulteMicrosoft Research

AbstractThe common conception of a (client-side) web applica-tion is some collection of HTML, CSS and JavaScript(JS) that is hosted within a web browser and that interactswith the user in some non-trivial ways. The commonconception of a web browser is a monolithic programthat can render HTML, execute JS, and gives the user aportal to navigate the web. Both of these are misconcep-tions: nothing inherently confines webapps to a browser’spage-navigation idiom, and browsers can do far morethan merely render content. Indeed, browsers and webapps are converging in functionality, but their underlyingtechnologies are so far largely distinct.

We present C3, an implementation of theHTML/CSS/JS platform designed for web-clientresearch and experimentation. C3’s typesafe, modulararchitecture lowers the barrier to webapp and browserresearch. Additionally, C3 explores the role of extensibil-ity throughout the web platform for customization andresearch efforts, by introducing novel extension pointsand generalizing existing ones. We discuss and evaluateC3’s design choices for flexibility, and provide examplesof various extensions that we and others have built.

1 Introduction

We spend vast amounts of time using web browsers: ca-sual users view them as portals to the web, while powerusers enjoy them as flexible, sophisticated tools withcountless uses. Researchers of all stripes view browsersand the web itself as systems worthy of study: browsersare a common thread for web-related research in fieldssuch as HCI, security, information retrieval, sociology,software engineering, and systems research. Yet today’sproduction-quality browsers are all monolithic, complexsystems that do not lend themselves to easy experimenta-tion. Instead, researchers often must modify the sourcecode of the browsers—usually tightly-optimized, obscure,

and sprawling C/C++ code—and this requirement of deepdomain knowledge poses a high barrier to entry, correct-ness, and adoption of research results.

Of course, this is a simplified depiction: browsers arenot entirely monolithic. Modern web browsers, suchas Internet Explorer, Firefox or Chrome, support exten-sions, pieces of code—usually a mix of HTML, CSS andJavaScript (JS)—that are written by third-party develop-ers and downloaded by end users, that build on top of thebrowser and customize it dynamically at runtime.1 Todate, such customizations focus primarily on modifyingthe user interfaces of browsers. (Browsers also supportplug-ins, binary components that provide functionality,such as playing new multimedia file types, not otherwiseavailable from the base browser. Unlike extensions, plug-ins cannot interact directly with each other or extend eachother further.)

Extensions are widely popular among both users anddevelopers: millions of Firefox users have downloadedthousands of different extensions over two billion times2.Some research projects have used extensions to imple-ment their ideas. But because current extension mecha-nisms have limited power and flexibility, many researchprojects still must resort to patching browser sources:

1. XML3D [14] defines new HTML tags and rendersthem with a 3D ray-tracing engine—but neitherHTML nor the layout algorithm are extensible.

2. Maverick [12] permits writing device drivers in JSand connecting the devices (e.g., webcams, USBthumb drives, GPUs, etc.) to web pages—but JScannot send raw USB packets to the USB root hub.

3. RePriv [5] experiments with new ways to securelyexpose and interact with private browsing informa-

1Opera supports widgets, which do not interact with the browser orcontent, and Safari recently added small but slowly-growing support forextensions in a manner similar to Chrome. We ignore these browsers inthe following discussions.

2https://addons.mozilla.org/en-US/statistics/

1

tion (e.g. topics inferred from browsing history) viareference-monitored APIs—but neither plug-ins norJS extensions can guarantee the integrity or securityof the mined data as it flows through the browser.

These projects incur development and maintenance costswell above the inherent complexity of their added func-tionality. Moreover, patching browser sources makesit difficult to update the projects for new versions ofthe browsers. This overhead obscures the fact that suchresearch projects are essentially extensions to the web-browsing experience, and would be much simpler to real-ize on a flexible platform with more powerful extensionmechanisms. Though existing extension points in main-stream browsers vary widely in both design and power,none can support the research projects described above.

1.1 The extensible future of web browsersWeb browsers have evolved from their beginnings as meredocument viewers into web-application runtime platforms.Applications such as Outlook Web Access or GoogleDocuments are sophisticated programs written in HTML,CSS and JS that use the browser only for rendering andexecution and ignore everything else browsers provide(bookmarks, navigation, tab management, etc.). Projectslike Mozilla Prism3 strip away all the browser “chrome”while reusing the underlying HTML/CSS/JS implementa-tion (in this case, Gecko), letting webapps run like nativeapps, outside of the typical browser. Taken to an extreme,“traditional” applications such as Firefox or Thunderbirdare written using Gecko’s HTML/CSS/JS engine, andclearly are not themselves hosted within a browser.

While browsers and web apps are growing closer,they are still mostly separate with no possibility oftight, customizable integration between them. Bloggingclients such as WordPress, instant messaging clients suchas Gchat, and collaborative document editors such asMozilla Skywriter are three disjoint web applications, alldesigned to create and share content. An author might beusing all three simultaneously, and searching for relevantweb resources to include as she writes. Yet the only wayto do so is to “escape the system”, copying and pastingweb content via the operating system.

1.2 ContributionsThe time has come to reconsider browser architectureswith a focus on extensibility. We present C3: a reconfig-urable, extensible implementation of HTML, CSS andJS designed for web client research and experimentation.C3 is written entirely in C# and takes advantage of .Net’slibraries and type-safety. Similar to Firefox building atop

3http://prism.mozillalabs.com/

Gecko, we have built a prototype browser atop C3, usingonly HTML, CSS and JS.

By reconfigurable, we mean that each of the modulesin our browser—Document Object Model (DOM) imple-mentation, HTML parser, JS engine, etc.—is loosely cou-pled by narrow, typesafe interfaces and can be replacedwith alternate implementations compiled separately fromC3 itself. By extensible, we mean that the default imple-mentations of the modules support run-time extensionsthat can be systematically introduced to

1. extend the syntax and implementation of HTML

2. transform the DOM when being parsed from HTML

3. extend the UI of the running browser

4. extend the environment for executing JS, and

5. transform and modify running JS code.

Compared to existing browsers, C3 introduces novel ex-tension points (1) and (5), and generalizes existing exten-sion points (2)–(4). These extension points are treated inorder in Section 3. We discuss their functionality and theirsecurity implications with respect to the same-origin pol-icy [13]. We also provide examples of various extensionsthat we and others have built.

The rest of the paper is structured as follows. Sec-tion 2 gives an overview of C3’s architecture and high-lights the software engineering choices made to furtherour modularity and extensibility design goals. Section 3presents the design rationale for our extension points anddiscusses their implementation. Section 4 evaluates theperformance, expressiveness, and security implicationsof our extension points. Section 5 describes future work.Section 6 concludes.

2 C3 architecture and design choices

As a research platform, C3’s explicit design goals arearchitectural modularity and flexibility where possible,instead of raw performance. Supporting the various ex-tension mechanisms above requires hooks at many levelsof the system. These goals are realized through carefuldesign and implementation choices. Since many require-ments of an HTML platform are standardized, aspects ofour architecture are necessarily similar to other HTMLimplementations. C3 lacks some of the features present inmature implementations, but contains all of the essentialarchitectural details of an HTML platform.

C3’s clean-slate implementation presented an opportu-nity to leverage modern software engineering tools andpractices. Using a managed language such as C# sidestepsthe headaches of memory management, buffer overruns,and many of the common vulnerabilities in production

2

Event loop

DOM implementation

Node, Element, . . .

Default down-load manager

JS Engine

Browser executable

UI WinFormsrenderer

Layout

ILayoutListener

IRenderer

IHtmlParserHtmlParser

CssParserICssParser

IDownloadManager

AssemblyClassInterfaceCommunicationImplementationThreads

Figure 1: C3’s modular architecture

browsers. Using a higher-level language better preservesabstractions and simplifies many implementation details.Code Contracts [4] are used throughout C3 to ensureimplementation-level invariants and safety properties—something that is not feasible in existing browsers.

Below, we sketch C3’s module-level architecture, andelaborate on several core design choices and resultingcustomization opportunities. We also highlight featuresthat enable the extension points examined in Section 3.

2.1 Pieces of an HTML platform

The primary task of any web platform is to parse, ren-der, and display an HTML document. For interactivity,web applications additionally require the managing ofevents such as user input, network connections, and scriptevaluation. Many of these sub-tasks are independent; Fig-ure 1 shows C3’s module-level decomposition of thesetasks. The HTML parser converts a text stream into anobject tree, while the CSS parser recognizes stylesheets.The JS engine dispatches and executes event handlers.The DOM implementation implements the API of DOMnodes, and implements bindings to expose these methodsto JS scripts. The download manager handles actual net-work communication and interactions with any on-diskcache. The layout engine computes the visual structureand appearance of a DOM tree given current CSS styles.The renderer displays a computed layout. The browser’sUI displays the output of the renderer on the screen, androutes user input to the DOM.

2.2 Modularity

Unlike many modern browsers, C3’s design embracesloose coupling between browser components. For ex-ample, it is trivial to replace the HTML parser, renderer

frontend, or JS engine without modifying the DOM im-plementation or layout algorithm. To make such drop-inreplacements feasible, C3 shares no data structures be-tween modules when possible (i.e., each module is heap-disjoint). This design decision also simplifies threadingdisciplines, and is further discussed in Section 2.7.

Simple implementation-agnostic interfaces describe theoperations of the DOM implementation, HTML parser,CSS parser, JS engine, layout engine, and front-end ren-derer modules. Each module is implemented as a separate.Net assembly, which prevents modules from breaking ab-stractions and makes swapping implementations simple.Parsers could be replaced with parallel [8] or speculative4

versions; layout might be replaced with a parallel [11] orincrementalizing version, and so on. The default moduleimplementations are intended as straightforward, unopti-mized reference implementations. This permits easy per-module evaluations of alternate implementation choices.

2.3 DOM implementation

The DOM API is a large set of interfaces, methods andproperties for interacting with a document tree. We high-light two key design choices in our implementation: whatthe object graph for the tree looks like, and the bindingsof these interfaces to C# classes. Our choices aim tominimize overhead and “boilerplate” coding burdens forextension authors.

Object trees: The DOM APIs are used throughout thebrowser: by the HTML parser (Section 2.4) to constructthe document tree, by JS scripts to manipulate that tree’sstructure and query its properties, and by the layout engineto traverse and render the tree efficiently. These clientsuse distinct but overlapping subsets of the APIs, whichmeans they must be exposed both to JS and to C#, whichin turn leads to the first design choice.

One natural choice is to maintain a tree of “imple-mentation” objects in the C# heap separate from a setof “wrapper” objects in the JS heap5 containing point-ers to their C# counterparts: the JS objects are a “view”of the underlying C# “model”. The JS objects containstubs for all the DOM APIs, while the C# objects containimplementations and additional helper routines. This de-sign incurs the overheads of extra pointer dereferences(from the JS APIs to the C# helpers) and of keepingthe wrappers synchronized with the implementation tree.However, it permits specializing both representations fortheir respective usages, and the extra indirection enables

4http://hsivonen.iki.fi/speculative-html5-parsing/5Expert readers will recognize that “objects in the JS heap” are

implemented by C# “backing” objects; we are distinguishing these fromC# objects that do not “back” any JS object.

3

multiple views of the model: This is essentially the tech-nical basis of Chrome extensions’ “isolated worlds” [1],where the indirection is used to ensure security proper-ties about extensions’ JS access to the DOM. Firefoxalso uses the split to improve JS memory locality with“compartments” [15].

By contrast, C3 instead uses a single tree of objectsvisible to both languages, with each DOM node being aC# subclass of an ordinary JS object, and each DOM APIbeing a standard C# method that is exposed to JS. This de-sign choice avoids both overheads mentioned above. Fur-ther, Spur [3], the tracing JS engine currently used by C3,can trace from JS into DOM code for better optimizationopportunities. To date, no other DOM implementation/JSengine pair can support this optimization.

DOM language bindings: The second design choicestems from our choice for the first: how to represent DOMobjects such that their properties are callable from bothC# and JS. This representation must be open: extensionssuch as XML3D must be able to define new types ofDOM nodes that are instantiable from the parser (seeSection 3.1) and capable of supplying new DOM APIs toboth languages as well. Therefore any new DOM classesmust subclass our C# DOM class hierarchy easily, andbe able to use the same mechanisms as the built-in DOMclasses. Our chosen approach is a thin marshaling layeraround a C# implementation, as follows:

• All Spur JS objects are instances of C# classes de-riving from ObjectInstance. Our DOM class hi-erarchy derives from this too, and so DOM objectsare JS objects, as above.

• All JS objects are essentially property bags, orkey/value dictionaries, and “native” objects (e.g.Math, Date) may contain properties that are im-plemented by the JS runtime and have access toruntime-internal state. All DOM objects are native,and their properties (the DOM APIs) access the in-ternal representation of the document.

• The JS dictionary is represented within Spur as aTypeObject field of each ObjectInstance. To ex-pose a native method on a JS object, the implemen-tation simply adds a property to the TypeObject

mapping the (JS) name to the (C#) function thatimplements it.6 This means that a single C# functioncan be called from both languages, and need not beimplemented twice.

The ObjectInstance and TypeObject classes are pub-lic Spur APIs, and so our DOM implementation is readilyextensible by new node types.

6Technically, to a C# function that unwraps the JS values intostrongly-typed C# values, then calls a second C# function with them.

2.4 The HTML parser

The HTML parser is concerned with transforming HTMLsource into a DOM tree, just as a standard compiler’sparser turns source into an AST. Extensible compilers’parsers can recognize supersets of their original languagevia extensions; similarly, C3’s default HTML parser sup-ports extensions that add new HTML tags (which are im-plemented by new C# DOM classes as described above;see also Section 3.1).

An extensible HTML parser has only two dependen-cies: a means for constructing a new node given a tagname, and a factory method for creating a new node andinserting it into a tree. This interface is far simpler thanthat of any DOM node, and so exists as the separateINode interface. The parser has no hard dependency ona specific DOM implementation, and a minimal imple-mentation of the INode interface can be used to test theparser independently of the DOM implementation. Thedefault parser implementation is given a DOM node fac-tory that can construct INodes for the built-in HTML tagnames. Extending the parser via this factory is discussedin Section 3.1.

2.5 Computing visual structure

The layout engine takes a document and its stylesheets,and produces as output a layout tree, an intermediate datastructure that contains sufficient information to displaya visual representation of the document. The rendererthen consults the layout tree to draw the document in aplatform- or toolkit-specific manner.

Computing a layout tree requires three steps: first,DOM nodes are attributed with style information accord-ing to any present stylesheets; second, the layout tree’sstructure is determined; and third, nodes of the layout treeare annotated with concrete styles (placement and sizing,fonts and colors, etc.) for the renderer to use. Each ofthese steps admits a naıve reference implementation, butboth more efficient and more extensible algorithms arepossible. We focus on the former here; layout extensibil-ity is revisited in Section 3.3.

Assigning node styles The algorithm that decoratesDOM nodes with CSS styles does not depend on anyother parts of layout computation. Despite the top-downimplementation suggested by the name “cascading stylesheets”, several efficient strategies exist, including recentand ongoing research in parallel approaches [11].

Our default style “cascading” algorithm is self-contained, single-threaded and straightforward. It deco-rates each DOM node with an immutable calculated styleobject, which is then passed to the related layout tree

4

node during construction. This immutable style sufficesthereafter in determining visual appearance.

Determining layout tree structure The layout tree isgenerated from the DOM tree in a single traversal. Thetwo trees are approximately the same shape; the layouttree may omit nodes for invisible DOM elements (e.g.〈script/〉), and may insert “synthetic” nodes to simplifylater layout invariants. For consistency, this transforma-tion must be serialized between DOM mutations, and soruns on the DOM thread (see Section 2.7). The layout treemust preserve a mapping between DOM elements andthe layout nodes they engender, so that mouse movement(which occurs in the renderer’s world of screen pixels andlayout tree nodes) can be routed to the correct target node(i.e. a DOM element). A naıve pointer-based solutionruns afoul of an important design decision: C3’s archi-tectural goals of modularity require that the layout andDOM trees share no pointers. Instead, all DOM nodesare given unique numeric ids, which are preserved by theDOM-to-layout tree transformation. Mouse targeting cannow be defined in terms of these ids while preservingpointer-isolation of the DOM from layout.

Solving layout constraints The essence of any layoutalgorithm is to solve constraints governing the placementand appearance of document elements. In HTML, theseconstraints are irregular and informally specified (if atall). Consequently the constraints are typically solvedby a manual, multi-pass algorithm over the layout tree,rather than a generic constraint-solver [11]. The manualalgorithms found in production HTML platforms are oftentightly optimized to eliminate some passes for efficiency.

C3’s architecture admits such optimized approaches,too; our reference implementation keeps the steps separatefor clarity and ease of experimentation. Indeed, becausethe layout tree interface does not assume a particularimplementation strategy, several layout algorithm variantshave been explored in C3 with minimal modifications tothe layout algorithm or components dependent on thecomputed layout tree.

2.6 Accommodating Privileged UIBoth Firefox and Chrome implement some (or all) oftheir user interface (e.g. address bar, tabs, etc.) in declar-ative markup, rather than hard-coded native controls. Inboth cases this gives the browsers increased flexibility; italso enables Firefox’s extension ecosystem. The markupused by these browsers is trusted, and can access inter-nal APIs not available to web content. To distinguishthe two, trusted UI files are accessed via a differentURL scheme: e.g., Firefox’s main UI is loaded usingchrome://browser/content/browser.xul.

We chose to implement our prototype browser’s UI inHTML for two reasons. First, we wanted to experimentwith writing sophisticated applications entirely within theHTML/CSS/JS platform and experience first-hand whatchallenges arose. Even in our prototype, such experi-ence led to the two security-related changes describedbelow. Secondly, having our UI in HTML opens thedoor to the extensions described in Section 3; the en-tirety of a C3-based application is available for extension.Like Firefox, our browser’s UI is available at a privi-leged URL: launching C3 with a command-line argumentof chrome://browser/tabbrowser.html will displaythe browser UI. Launching it with the URL of any web-site will display that site without any surrounding browserchrome. Currently, we only permit HTML file resourcesbundled within the C3 assembly itself to be given privi-leged chrome:// URLs.

Designing this prototype exposed deliberate limitationsin HTML when examining the navigation history of childwindows (popups or 〈iframe/〉s): the APIs restrict accessto same-origin sites only, and are write-only. A parentwindow cannot see what site a child is on unless it is fromthe same origin as the parent, and can never see what sitesa child has visited. A browser must avoid both of theserestrictions so that it can implement the address bar.

Rather than change API visibility, C3 extends the DOMAPI in two ways. First, it gives privileged pages (i.e.,from chrome:// URLs) a new childnavigated noti-fication when their children are navigated, just beforethe onbeforeunload events that the children alreadyreceive. Second, it treats chrome:// URLs as trustedorigins that always pass same-origin checks. The trusted-origin mechanism and the custom navigation event sufficeto implement our browser UI.

2.7 Threading architecture

One important point of flexibility is the mapping betweenthreads and the HTML platform components describedabove. We do not impose any threading discipline be-yond necessary serialization required by HTML and DOMstandards. This is made possible by our decision to pre-vent data races by design: in our architecture, data iseither immutable, or it is not shared amongst multiplecomponents. Thus, it is possible to choose any thread-ing discipline within a single component; a single threadcould be shared among all components for debugging, orseveral threads could be used within each component toimplement worker queues.

Below, we describe the default allocation of threadsamong components, as well as key concurrency concernsfor each component.

5

2.7.1 The DOM/JS thread(s)

The DOM event dispatch loop and JS execution aresingle-threaded within a set of related web pages7. “Sep-arate” pages that are unrelated8 can run entirely paral-lel with each other. Thus, sessions with several tabs orwindows open simultaneously use multiple DOM eventdispatch loops.

In C3, each distinct event loop consists of two threads:a mutator to run script and a watchdog to abort run-awayscripts. Our system maintains the invariant that all mu-tator threads are heap-disjoint: JS code executing in atask on one event loop can only access the DOM nodes ofdocuments sharing that event loop. This invariant, com-bined with the single-threaded execution model of JS(from the script’s point of view), means all DOM nodesand synchronous DOM operations can be lock-free. (Op-erations involving local storage are asynchronous andmust be protected by the storage mutex.) When a windowor 〈iframe/〉 is navigated, the relevant event loop maychange. An event loop manager is responsible for main-taining the mappings between windows and event loopsto preserve the disjoint-heap invariant.

Every DOM manipulation (node creation, deletion, in-sertion or removal; attribute creation or modification; etc.)notifies any registered DOM listener via a straightforwardinterface. One such listener is used to inform the layoutengine of all document manipulations; others could beused for testing or various diagnostic purposes.

2.7.2 The layout thread(s)

Each top-level browser window is assigned a layoutthread, responsible for resolving layout constraints asdescribed in Section 2.5. Several browser windows mightbe simultaneously visible on screen, so their layout com-putations must proceed in parallel for each window toquickly reflect mutations to the underlying documents.Once the DOM thread computes a layout tree, it transfersownership of the tree to the layout thread, and beginsbuilding a new tree. Any external resources necessary forlayout or display (such as image data), are also passedto the layout thread as uninterpreted .Net streams. Thisisolates the DOM thread from any computational errorson the layout threads.

2.7.3 The UI thread

It is common for GUI toolkits to impose threading restric-tions, such as only accessing UI widgets from their creat-ing thread. These restrictions influence the platform inso-

7We ignore for now web-workers, which are an orthogonal concern.8Defining when pages are actually separate is non-trivial, and is a

refinement of the same-origin policy, which in turn has been the subjectof considerable research [7, 2]

far as replaced elements (such as buttons or text boxes)are implemented by toolkit widgets.

C3 is agnostic in choosing a particular toolkit, butrather exposes abstract interfaces for the few widget prop-erties actually needed by layout. Our prototype currentlyuses the .Net WinForms toolkit, which designates onethread as the “UI thread”, to which all input events aredispatched and on which all widgets must be accessed.When the DOM encounters a replaced element, an actualWinForms widget must be constructed so that layout canin turn set style properties on that widget. This requiressynchronous calls from the DOM and layout threads tothe UI thread. Note, however, that responding to events(such as mouse clicks or key presses) is asynchronous,due to the indirection introduced by numeric node ids: theUI thread simply adds a message to the DOM event loopwith the relevant ids; the DOM thread will process thatmessage in due course.

3 C3 Extension points

The extension mechanisms we introduce into C3 stemfrom a principled examination of the various semantics ofHTML. Our interactions with webapps tacitly rely on ma-nipulating HTML in two distinct ways: we can interpretit operationally via the DOM and JS programs, and wecan interpret it visually via CSS and its associated layoutalgorithms. Teasing these interpretations apart leads tothe following two transformation pipelines:

• JS global object + HTML source1,2

HTML parsing−−−−−−−−−→ 3DOM subtrees4

onload−−−−→ DOM document5

JS events−−−−−−→ DOM document . . .

• DOM document + CSS source6

CSS parsing−−−−−−−−→ CSS content model7

layout−−−−→ CSS box model

The first pipeline distinguishes four phases of the docu-ment lifecycle, from textual sources through to the event-based running of JS: the initial onload event marks thetransition point after which the document is asserted tobe fully loaded; before this event fires, the page maybe inconsistent as critical resources in the page may notyet have loaded, or scripts may still be writing into thedocument stream.

Explicitly highlighting these pipeline stages leads todesigning extension points in a principled way: we canextend the inputs accepted or the outputs produced byeach stage, as long as we produce outputs that are accept-able inputs to the following stages. This is in contrast to

6

public interface IDOMTagFactory {

IEnumerable<Element> TagTemplates { get; }

}

public class HelloWorldTag : Element {

string TagName { get { return "HelloWorld"; } }

...

}

public class HelloWorldFactory : IDOMTagFactory {

IEnumerable<Element> TagTemplates { get {

yield return new HelloWorldTag();

} }

}

Figure 2: Factory and simple extension defining new tags

the extension models of existing browsers, which supportvarious extension points without relating them to otherpossibilities or to the browser’s behavior as a whole. Theextension points engendered by the pipelines above are(as numbered):

1. Before beginning HTML parsing, extensions mayprovide new tag names and DOM-node implementa-tions for the parser to support.

2. Before running any scripts, extensions may modifythe JS global scope by adding or removing bindings.

3. Before inserting subtrees into the document, exten-sions may preprocess them using arbitrary C# code.

4. Before firing the onload event, extensions maydeclaratively inject new content into the nearly-complete tree using overlays.

5. Once the document is complete and events are run-ning, extensions may modify existing event handlersusing aspects.

6. Before beginning CSS parsing, extensions may pro-vide new CSS properties and values for the parserto support.

7. Before computing layout, extensions may providenew layout box types and implementations to affectlayout and rendering.

Some of these extension points are simpler than othersdue to regularities in the input language, others are morecomplicated, and others are as yet unimplemented. Points(1) and (5) are novel to C3. C3 does not yet implementpoints (6) or (7), though they are planned future work;they are also novel. We explain points (1), (3) and (4) inSection 3.1, points (2) and (5) in Section 3.2, and finallypoints (6) and (7) in Section 3.3.

3.1 HTML parsing/document constructionPoint (1): New tags and DOM nodes The HTMLparser recognizes concrete syntax resembling〈tagName attrName=“val”/〉 and constructs newDOM nodes for each tag. In most browsers, the choicesof which tag names to recognize, and what correspondingobjects to construct, are tightly coupled into the parser. InC3, however, we abstract both of these decisions behind afactory, whose interface is shown in the top of Figure 2.9

Besides simplifying our code’s internal structure, thisapproach permits extensions to contribute factories too.

Our default implementation of this interface providesone “template” element for each of the standard HTMLtag names; these templates inform the parser which tagnames are recognized, and are then cloned as neededby the parser. Any unknown tag names fall back to re-turning an HTMLUnknownElement object, as defined bythe HTML specification. However, if an extension con-tributes another factory that provides additional templates,the parser seamlessly can clone those instead of using thefallback: effectively, this extends the language recognizedby the parser, as XML3D needed, for example. A trivialexample that adds support for a 〈HelloWorld/〉 tag isshown in Figure 2. A more realistic example is used byC3 to support overlays (see Figure 4 and below).

The factory abstraction also gives us the flexibilityto support additional experiments: rather than addingnew tags, a researcher might wish to modify existing tags.Therefore, we permit factories to provide a new templatefor existing tag names—and we require that at most oneextension does so per tag name. This permits extensionsto easily subclass the C3 DOM implementation, e.g. toadd instrumentation or auditing, or to modify existingfunctionality. Together, these extensions yield a parserthat accepts a superset of the standard HTML tags andstill produces a DOM tree as output.

Point (3): Preprocessing subtrees The HTML 5 pars-ing algorithm produces a document tree in a bottom-upmanner: nodes are created and then attached to parentnodes, which eventually are attached to the root DOMnode. Compiler-authors have long known that it is use-ful to support semantic actions, callbacks that examineor preprocess subtrees as they are constructed. Indeed,the HTML parsing algorithm itself specifies some behav-iors that are essentially semantic actions, e.g., “when an〈img/〉 is inserted into the document, download the ref-erenced image file”. Extensions might use this ability tocollect statistics on the document, or to sanitize it dur-ing construction. These actions typically are local—theyexamine just the newly-inserted tree—and rarely mutate

9Firefox seems not to use a factory; Chrome uses one, but the choiceof factory is fixed at compile-time. C3 can load factories dynamically.

7

public interface IParserMutatorExtension {

IEnumerable<string> TagNamesOfInterest { get; }

void OnFinishedParsing(Element element);

}

Figure 3: The interface for HTML parser semantic actions

Base constructions〈overlay/〉 Root node of extension document〈insert

selector=“selector”where=“before|after”/〉

Insert new content adjacent to allnodes matched by CSS selector

〈replaceselector=“selector”/〉

Replace existing subtrees matchingselector with new content

〈selfattrName=“value”. . ./〉

Used within 〈replace/〉, refers tonode being replaced and permitsmodifying its attributes

〈contents/〉 Used within 〈replace/〉, refers tochildren of node being replaced

Syntactic sugar〈before . . ./〉 〈insert where=“before”. . ./〉〈after . . ./〉 〈insert where=“after”. . ./〉〈modify selector=“sel”

where=“before”〉〈self new attributes〉

new content〈/self〉

〈/modify〉

〈replace selector=“sel”〉〈self new attributes〉

new content〈contents/〉

〈/self〉〈/replace〉and likewise for where=“after”

Figure 4: The overlay language for document constructionextensions. The bottom set of tags are syntactic sugar.

the surrounding document. (In HTML in particular, be-cause inline scripts execute during the parsing phase, thedocument may change arbitrarily between two successivesemantic-action callbacks, and so semantic actions willbe challenging to write if they are not local.)

Extensions in C3 can define custom semantic actionsusing the interface shown in Figure 3. The interface sup-plies a list of tag names, and a callback to be used whentags of those names are constructed.

Point (4): Document construction Firefox pioneeredthe ability to both define application UI and define ex-tensions to that UI using a single declarative markuplanguage (XUL), an approach whose success is witnessedby the variety and popularity of Firefox’s extensions. Thefundamental construction is the overlay, which behaveslike a “tree-shaped patch”: the children of the 〈overlay/〉select nodes in a target document and define content tobe inserted into or modified within them, much as hunkswithin a patch select lines in a target text file. C3 adaptsand generalizes this idea for HTML.

Our implementation adds eight new tags to HTML,

〈overlay〉〈modify selector=“head” where=“after”〉

〈self〉〈style〉li > #bullet { color: blue; }

〈/style〉〈/self〉

〈/modify〉〈before selector=“li > *:first-child”〉

〈span class=“bullet”〉&bull;〈/span〉〈/before〉

〈/overlay〉

Figure 5: Simulating list bullets (in language of Fig. 4)

shown in Figure 4, to define overlays and the various ac-tions they can perform. As they are a language extensionto HTML, we inform the parser of these new tags usingthe IDOMTagFactory described above.10 Overlays can〈insert/〉 or 〈replace/〉 elements, as matched by CSSselectors. To support modifying content, we give over-lays the ability to refer to the target node (〈self/〉) or its〈contents/〉. Finally, we define syntactic sugar to makeoverlays easier to write.

Figure 5 shows a simple but real example used dur-ing development of our system, to simulate bulleted listswhile generated content support was not yet implemented.It appends a 〈style/〉 element to the end of the 〈head/〉subtree (and fails if no 〈head/〉 element exists), and in-serts a 〈span/〉 element at the beginning of each 〈li/〉.

The subtlety of defining the semantics of overlays liesin their interactions with scripts: when should overlaysbe applied to the target document? Clearly overlays mustbe applied after the document structure is present, so astrawman approach would apply overlays “when pars-ing finishes”. This exposes a potential inconsistency, asscripts that run during parsing would see a partial, not-yet-overlaid document, with nodes a and b adjacent, whilescripts that run after parsing would see an overlaid docu-ment where a and b may no longer be adjacent. However,the HTML specification offers a way out: the DOM raisesa particular event, onload, that indicates the documenthas finished loading and is ready to begin execution. Priorto that point, the document structure is in flux—and sowe choose to apply overlays as part of that flux, imme-diately before the onload event is fired. This may breakpoorly-coded sites, but in practice has not been an issuewith Firefox’s extensions.

10We apply the overlays using just one general-purpose callbackwithin our code. This callback could be factored as a standalone, ad-hocextension point, making overlays themselves truly an extension to C3.

8

3.2 JS execution

Point (2): Runtime environment Extensions such asMaverick may wish to inject new properties into theJS global object. This object is an input to all scripts,and provides the initial set of functionality availableto pages. As an input, it must be constructed beforeHTML parsing begins, as the constructed DOM nodesshould be consistent with the properties available fromthe global object: e.g., document.body must be an in-stance of window.HTMLBodyElement. This point in thedocument’s execution is stable—no scripts have executed,no nodes have been constructed—and so we permit ex-tensions to manipulate the global object as they please.(This could lead to inconsistencies, e.g. if they modifywindow.HTMLBodyElement but do not replace the im-plementation of 〈body/〉 tags using the prior extensionpoints. We ignore such buggy extensions for now.)

Point (5): Scripts themselves The extensions de-scribed so far modify discrete pieces of implementation,such as individual node types or the document structure,because there exist ways to name each of these resourcesstatically: e.g., overlays can examine the HTML sourceof a page and write CSS selectors to name parts of thestructure. The analogous extension to script code needsto modify the sources of individual functions. Many JSidioms have been developed to achieve this, but they allsuffer from JS’s dynamic nature: function names do notexist statically, and scripts can create new functions oralias existing ones at runtime; no static inspection of thescripts’ sources can precisely identify these names. More-over, the common idioms used by extensions today arebrittle and prone to silent failure.

C3 includes our prior work [10], which addresses thisdisparity by modifying the JS compiler to support aspectoriented programming using a dynamic weaving mecha-nism to advise closures (rather than variables that pointto them). Only a dynamic approach can detect runtime-evaluated functions, and this requires compiler supportto advise all aliases to a function (rather than individualnames). As a side benefit, aspects’ integration with thecompiler often improves the performance of the advice:in the work cited, we successfully evaluated our approachon the sources of twenty Firefox extensions, and showedthat they could express nearly all observed idioms withshorter, clearer and often faster code.

3.3 CSS and layout

Discussion An extensible CSS engine permits incre-mentally adding new features to layout in a modular, cleanway. The CSS 3 specifications themselves are a step inthis direction, breaking the tightly-coupled CSS 2.1 spec-

ification into smaller pieces. A true test of our proposedextension points’ expressiveness would be to implementnew CSS 3 features, such as generated content or theflex-box model, as extensions. An even harder test wouldbe to extricate older CSS 2 features, such as floats, and re-implement them as compositional extensions. The benefitto successfully implementing these extensions is clear: astronger understanding of the semantics of CSS features.

We discovered the possibility of these CSS extensionpoints quite recently, in exploring the consequences ofmaking each stage of the layout pipeline extensible “in thesame way” as the DOM/JS pipeline is. To our knowledge,implementing the extension points below has not beendone before in any browser, and is planned future work.

Point (6): Parsing CSS values We can extend theCSS language in four ways: 1) by adding new prop-erty names and associated values, 2) by recognizing newvalues for existing properties, 3) by extending the set ofselectors, or 4) by adding entirely new syntax outside ofstyle declaration blocks. The latter two are beyond thescope of an extension, as they require more sweepingchanges to both the parser and to layout, and are bettersuited to an alternate implementation of the CSS parseraltogether (i.e., a different configuration of C3).

Supporting even just the first two extension points isnontrivial. Unlike HTML’s uniform tag syntax, nearlyevery CSS attribute has its own idiosyncratic syntax:

font: italic bold 10pt/1.2em "Gentium", serif;

margin: 0 0 2em 3pt;

display: inline-block;

background-image: url(mypic.jpg);

...

However, a style declaration itself is very regular, being asemicolon-separated list of colon-separated name/valuepairs. Moreover, the CSS parsing algorithm discardsany un-parsable attributes (up to the semicolon), and thenparse the rest of the style declaration normally.

Supporting the first extension point—new propertynames—requires making the parser table-driven and reg-istering value-parsing routines for each known propertyname. Then, like HTML tag extensions, CSS property ex-tensions can register new property names and callbacks toparse the values. (Those values must never contain semi-colons, or else the underlying parsing algorithm wouldnot be able to separate one attribute from another.)

Supporting the second extension point is subtler. Un-like the HTML parser’s uniqueness constraint on tagnames, here multiple extensions might contribute newvalues to an existing property; we must ensure that thesyntaxes of such new values do not overlap, or else pro-vide some ranking to choose among them.

9

Point (7): Composing layout The CSS layout algo-rithm describes how to transform the document tree (thecontent model) into a tree of boxes of varying types, ap-pearances and positions. Some boxes represent lines oftext, while others represent checkboxes, for example. Thistransformation is not obviously compositional: manyCSS properties interact with each other in non-trivialways to determine precisely which types of boxes to con-struct. Rather than hard-code the interactions, the layouttransformation must become table-driven as well. Thenboth types of extension above become easy: extensionscan create new box subtypes, and patch entries in thetransformation table to indicate when to create them.

4 Evaluation

The C3 platform is rapidly evolving, and only a few ex-tensions have yet been written. To evaluate our platform,we examine: the performance of our extension points,ensuring that the benefits are not outweighed by hugeoverheads; the expressiveness, both in the ease of “port-ing” existing extensions to our model and in comparisonto other browsers’ models; and the security implicationsof providing such pervasive customizations.

4.1 PerformanceAny time spent running the extension manager or conflictanalyses slows down the perceived performance of thebrowser. Fortunately, this process is very cheap: with oneextension of each supported type, it costs roughly 100msto run the extensions. This time includes: enumerating allextensions (27ms), loading all extensions (4ms), and de-tecting parser-tag conflicts (3ms), mutator conflicts (2ms),and overlay conflicts (72ms). All but the last of thesetasks runs just once, at browser startup; overlay conflictdetection must run per-page. Enumerating all extensionscurrently reads a directory, and so scales linearly withthe number of extensions. Parser and mutator conflictdetection scale linearly with the number of extensionsas well; overlay conflict detection is more expensive aseach overlay provides more interacting constraints thanother types of extensions do. If necessary, these costscan be amortized further by caching the results of conflictdetection between browser executions.

4.2 ExpressivenessFigure 6 lists several examples of extensions availablefor IE, Chrome, and Firefox, and the corresponding C3extension points they would use if ported to C3. Many ofthese extensions simply overlay the browser’s user inter-face and require no additional support from the browser.Some, such as Smooth Gestures or LastTab, add or revise

UI functionality. As our UI is entirely script-driven, wesupport these via script extensions. Others, such as thevarious Native Client libraries, are sandboxed programsthat are then exposed through JS objects; we support theJS objects and .Net provides the sandboxing.

Figure 6 also shows some research projects that are notimplementable as extensions in any other browser exceptC3. As described below, these projects extend the HTMLlanguage, CSS layout, and JS environment to achievetheir functionality. Implementing these on C3 requiresno hacking of C3 , leading to a much lower learningcurve and fewer implementation pitfalls than modifyingexisting browsers. We examine some examples, and howthey might look in C3, in more detail here.

4.2.1 XML3D: Extending HTML, CSS and layout

XML3D [14] is a recent project aiming to provide3D scenes and real-time ray-traced graphics for webpages, in a declarative form analogous to 〈svg/〉 for two-dimensional content. This work uses XML namespaces todefine new scene-description tags and requires modifyingeach browser to recognize them and construct special-ized DOM nodes accordingly. To style the scenes, thiswork must modify the CSS engine to recognize new styleattributes. Scripting the scenes and making them inter-active requires constructing JS objects that expose thecustomized properties of the new DOM nodes. It alsoentails informing the browser of a new scripting language(AnySL) tailored to animating 3D scenes.

Instead of modifying the browser to recognize new tagnames, we can use the new-tag extension point to definethem in an extension, and provide a subclassed 〈script/〉implementation recognizing AnySL. Similarly, we canprovide new CSS values and new box subclasses forlayout to use. The full XML3D extension would consistof these four extension hooks and the ray-tracer engine.

4.2.2 Maverick: Extensions to the global scope

Maverick [12] aims to connect devices such as webcamsor USB keys to web content, by writing device drivers inJS and connecting them to the devices via Native Client(NaCl) [17]. NaCl exposes a socket-like interface to webJS over which all interactions with native modules aremultiplexed. To expose its API to JS, Maverick injects anactual DOM 〈embed/〉 node into the document, stashingstate within it, and using JS properties on that object tocommunicate with NaCl. This object can then transliteratethe image frames from the webcam into Base64-encodedsrc URLs for other scripts’ use in 〈img/〉 tags, and soreuse the browser’s image decoding libraries.

There are two main annoyances with Maverick’s im-plementation that could be avoided in C3. First, NaCl

10

Extensions Available from C3-equivalent extension points usedIE:

Explorer bars (4) overlay the main browser UIContext menu items (4) overlay the context menu in the browser UIAccelerators (4) overlay the context menuWebSlices (4) overlay browser UI

Chrome:Gmail checkers https://chrome.google.com/

extensions/search?q=gmail

(4) overlay browser UI, (5) script advice

Skype http://go.skype.com/dc/

clicktocall

(4) overlay browser UI, (2) new JS objects, (5) scriptadvice

Smooth Gestures http://goo.gl/rN5Y (4) overlay browser UI, (5) script adviceNative Client libraries http://code.google.com/p/

nativeclient/

(2) new JS objects

Firefox:TreeStyleTab https://addons.mozilla.org/

en-US/firefox/addon/5890/

(4) overlay tabbar in browser UI, inject CSS

LastTab https://addons.mozilla.org/

en-US/firefox/addon/112/

(5) script advice

Perspectives [16] (5) script extensions, (4) overlay error UIFirebug http://getfirebug.com/ (4) overlays, (5) script extensions, (2) new JS objects

Research projects:XML3D [14] (1) new HTML tags, (6) new CSS values, (7) new layoutsMaverick [12] (2) new JS objectsFine [6] (1) HTML 〈script/〉 tag replacementRePriv [5] (2) new JS objects

Figure 6: Example extensions in IE, Firefox, and Chrome, as well as research projects best implemented in C3, and theC3 extension points that they might use

isolates native modules in a strong sandbox that preventsdirect communication with resources like devices; Maver-ick could not be implemented in NaCl without modifyingthe sandbox to expose a new system call and writinguntrusted glue code to connect it to JS; in C3, trustedJS objects can be added without recompiling C3 itself.Second, implementing Maverick’s exposed API requirescarefully managing low-level NPAPI routines that mustmimic JS’s name-based property dispatch; in C3, expos-ing properties can simply reuse the JS property dispatch,as in Section 2.3.

Ultimately, using a DOM node to expose a device isnot the right abstraction: it is not a node in the documentbut rather a global JS object like XMLHttpRequest. Andwhile using Base64-encoded URLs is a convenient imple-mentation trick, it would be far more natural to call theimage-decoding libraries directly, avoiding both overheadand potential transcoding errors.

4.2.3 RePriv: Extensions hosting extensions

RePriv [5] runs in the background of the browser andmines user browsing history to infer personal interests. Itcarefully guards the release of that information to web-sites, via APIs whose uses can be verified to avoid un-wanted information leakage. At the same time, it offers its

own extension points for site-specific “interest miners” touse to improve the quality of inferred information. Theseminers are all scheduled to run during an onload eventhandler registered by RePriv. Finally, extensions can bewritten to use the collected information to reorganize webpages at the client to match the user’s interests.

While this functionality is largely implementable as aplug-in in other browsers, several factors make it mucheasier to implement in C3. First and foremost, RePriv’ssecurity guarantees rely on C3 being entirely managedcode: we can remove the browser from RePriv’s trustedcomputing base by isolating RePriv extensions in an App-Domain and leveraging .Net’s freedom from commonexploits such as buffer overflows. Obtaining such a strongsecurity guarantee in other browsers is at best very chal-lenging. Second, the document construction hook makesit trivial for RePriv to install the onload event handler.Third, AppDomains ensure the memory isolation of everyminer from each other and from the DOM of the doc-ument, except as mediated by RePriv’s own APIs; thismakes proving the desired security properties much eas-ier. Finally, RePriv uses Fine [6] for writing its interestminers; since C3, RePriv and Fine target .Net, RePriv canreuse .Net’s assembly-loading mechanisms.

11

4.3 Other extension models4.3.1 Extensions to application UI

Internet Explorer 4.0 introduced two extension points per-mitting customized toolbars (Explorer Bars) and context-menu entries. These extensions were written in native C++code, had full access to the browser’s internal DOM repre-sentations, and could implement essentially any function-ality they chose. Unsurprisingly, early extensions oftencompromised the browser’s security and stability. IE 8later introduced two new extension points that permit-ted self-updating bookmarks of web-page snippets (WebSlices) and context-menu items to speed access to repeti-tive tasks (Accelerators), providing safer implementationsof common uses for Explorer Bars and context menus.

The majority of IE’s interface is not modifiable by ex-tensions. By contrast, Firefox explored the possibilitythat entire application interfaces could be implementedin a markup language, and that a declarative extensionmechanism could overlay those UIs with new construc-tions. Research projects such as Perspectives change theway Firefox’s SSL connection errors are presented, whileothers such as Xmarks or Weave synchronize bookmarksand user settings between multiple browsers. The UI forthese extensions is written in precisely the same declar-ative way as Firefox’s own UI, making it as simple toextend Firefox’s browser UI as it is to design any website.

But the single most compelling feature of these ex-tensions is also their greatest weakness: they permit im-plementing features that were never anticipated by thebrowser designers. End users can then install multiplesuch extensions, thereby losing any assurance that thecomposite browser is stable, or even that the extensionsare compatible with each other. Indeed, Chrome’s care-fully curtailed extension model is largely a reaction to theinstabilities often seen with Firefox extensions. Chromepermits extensions only minimal change to the browser’sUI, and prevents interactions between extensions. Forcomparison, Chrome directly implements bookmarksand settings synchronization, and now permits extensioncontext-menu actions, but the Perspectives behavior re-mains unimplementable by design.

Our design for overlays is based strongly on Firefox’sdeclarative approach, but provides stronger semantics foroverlays so that we can detect and either prevent or correctconflicts between multiple extensions. We also general-ized several details of Firefox’s overlay mechanism forgreater convenience, without sacrificing its analyzability.

4.3.2 Extensions to scripts

In tandem with the UI extensions, almost the entiretyof Firefox’s UI behaviors are driven by JS, and againextensions can manipulate those scripts to customize

those behaviors. A similar ability lets extensions modifyor inject scripts within web pages. Extensions such asLastTab change the tab-switching order from cyclic tomost-recently-used, while others such as Ghostery blockso-called “web tracking bugs” from executing. Firefoxexposes a huge API, opening basically the entire plat-form to extension scripts. This flexibility also poses aproblem: multiple extensions may attempt to modify thesame scripts, often leading to broken or partially-modifiedscripts with unpredictable consequences.

Modern browser extension design, like Firefox’s Jet-pack or Chrome’s extensions, are typically developedusing HTML, JS, and CSS. While Firefox “jetpacks” arecurrently still fully-privileged, Chrome extensions runin a sandboxed process. Chrome extensions cannot ac-cess privileged information and cannot crash or hang thebrowser. While these new guarantees are necessary for thestability of a commercial system protecting valuable userinformation, they also restrict the power of extensions.

One attempt to curtail these scripts’ interactions witheach other within web pages is the Fine project [6]. In-stead of directly using JS, the authors use a dependently-typed programming language to express the precise read-and write-sets of extension scripts, and a security policyconstrains the information flow between them. Exten-sions that satisfy the security policy are provably non-conflicting. The Fine project can target C3 easily, eitherby compiling its scripts to .Net assemblies and loadingthem dynamically (by subclassing the 〈script/〉 tag), orby statically compiling its scripts to JS and dynamicallyinjecting them into web content (via the JS global-objecthook). Guha et al. successfully ported twenty Chromeextensions to Fine and compiled them to run on C3 withminimal developer effort.

As mentioned earlier, C3 includes our prior work onaspect-oriented programming for JS [10], permitting ex-tensions clearer language mechanisms to express howtheir modifications apply to existing code. Beyond theperformance gains and clarity improvements, by elimi-nating the need for brittle mechanisms and exposing theintent of the extension, compatibility analyses betweenextensions become feasible.

4.4 Security considerations

Of the five implemented extension points, two are writtenin .Net and have full access to our DOM internals. Inparticular, new DOM nodes or new JS runtime objectsthat subclass our implementation may use protected DOMfields inappropriately and violate the same-origin policy.We view this flexibility as both an asset and a liability:it permits researchers to experiment with alternatives tothe SOP, or to prototype enhancements to HTML andthe DOM. At the same time, we do not advocate these

12

extensions for web-scale use. The remaining extensionpoints are either limited to safe, narrow .Net interfacesor are written in HTML and JS and inherently subject tothe SOP. Sanitizing potentially unsafe .Net extensions topreserve the SOP is itself an interesting research problem.Possible approaches include using .Net AppDomains tosegregate extensions from the main DOM, or static analy-ses to exclude unsafe accesses to DOM internals.

5 Future work

We have focused so far on the abilities extensions havewithin our system. However, the more powerful exten-sions become, the more likely they are to conflict with oneanother. Certain extension points are easily amenable toconflict detection; for example, two parser tag extensionscannot both contribute the same new tag name. However,in previous work we have shown that defining conflictsprecisely between overlay extensions, or between JS run-time extensions, is a more challenging task [9] .

Assuming a suitable notion of extension conflict existsfor each extension type, it falls to the extension loadingmechanism to ensure that, whenever possible, conflictingextensions are not loaded. In some ways this is very sim-ilar to the job of a compile-time linker, ensuring that allmodules are compatible before producing the executableimage. Such load-time prevention gives users a much bet-ter experience than in current browsers, where problemsnever surface until runtime. However not all conflicts aredetectable statically, and so some runtime mechanism isstill needed to detect conflict, blame the offending exten-sion, and prevent the conflict from recurring.

6 Conclusion

We presented C3, a platform implementing of HTML,CSS and JS, and explored how its design was tuned foreasy reconfiguration and runtime extension. We presentedseveral motivating examples for each extension point,and confirmed that our design is at least as expressive asexisting extension systems, supporting current extensionsas well as new ones not previously possible.

References[1] BARTH, A., FELT, A. P., SAXENA, P., AND BOODMAN, A.

Protecting browsers from extension vulnerabilities. In NDSS(2010).

[2] BARTH, A., WEINBERGER, J., AND SONG, D. Cross-originJavaScript capability leaks: Detection, exploitation, and defense.In SSYM’09: Proceedings of the 18th conference on USENIX secu-rity symposium (Berkeley, CA, USA, 2009), USENIX Association,pp. 187–198.

[3] BEBENITA, M., BRANDNER, F., FAHNDRICH, M., LOGOZZO,F., SCHULTE, W., TILLMANN, N., AND VENTER, H. SPUR:

A trace-based JIT compiler for CIL. In OOPSLA/SPLASH ’10:Proceedings of the 25th ACM SIGPLAN conference on Object-Oriented Programming Systems, Languages and Applications(New York, NY, USA, 2010), ACM.

[4] FAHNDRICH, M., BARNETT, M., AND LOGOZZO, F. Embeddedcontract languages. In SAC ’10: Proceedings of the 2010 ACMSymposium on Applied Computing (New York, NY, USA, 2010),ACM, pp. 2103–2110.

[5] FREDRIKSON, M., AND LIVSHITS, B. RePriv: Re-envisioningin-browser privacy. Tech. rep., Microsoft Research, Aug. 2010.

[6] GUHA, A., FREDRIKSON, M., LIVSHITS, B., AND SWAMY, N.Verified security for browser extensions. MSR-TR to be available11/01, September 2010.

[7] JACKSON, C., AND BARTH, A. Beware of finer-grained origins.In In Web 2.0 Security and Privacy (W2SP 2008) (2008).

[8] JONES, C. G., LIU, R., MEYEROVICH, L., ASANOVIC, K.,AND BODIK, R. Parallelizing the Web Browser. In HotPar ’09:Proceedings of the Workshop on Hot Topics in Parallelism (March2009), USENIX.

[9] LERNER, B. S., AND GROSSMAN, D. Language support forextensible web browsers. In APLWACA ’10: Proceedings of the2010 Workshop on Analysis and Programming Languages for WebApplications and Cloud Applications (New York, NY, USA, 2010),ACM, pp. 39–43.

[10] LERNER, B. S., VENTER, H., AND GROSSMAN, D. Support-ing dynamic, third-party code customizations in JavaScript usingaspects. In OOPSLA ’10: Companion of the 25th annual ACMSIGPLAN conference on Object-oriented programming, systems,languages, and applications (New York, NY, USA, 2010), ACM.

[11] MEYEROVICH, L. A., AND BODIK, R. Fast and parallel webpagelayout. In Proceedings of the 19th International Conference onthe World Wide Web (2010), WWW ’10, pp. 711–720.

[12] RICHARDSON, D. W., AND GRIBBLE, S. D. Maverick: Pro-viding web applications with safe and flexible access to localdevices. In Proceedings of the 2011 USENIX Conference on WebApplication Development (June 2011), WebApps’11.

[13] RUDERMAN, J. Same origin policy for javascript, Oct. 2010.

[14] SONS, K., KLEIN, F., RUBINSTEIN, D., BYELOZYOROV, S.,AND SLUSALLEK, P. XML3D: interactive 3d graphics for theweb. In Web3D ’10: Proceedings of the 15th International Confer-ence on Web 3D Technology (New York, NY, USA, 2010), ACM,pp. 175–184.

[15] WAGNER, G., GAL, A., WIMMER, C., EICH, B., AND FRANZ,M. Compartmental memory management in a modern webbrowser. In Proceedings of the International Symposium on Mem-ory Management (June 2011), ACM. To appear.

[16] WENDLANDT, D., ANDERSEN, D. G., AND PERRIG, A. Per-spectives: Improving ssh-style host authentication with multi-pathprobing. In Proceedings of the USENIX Annual Technical Confer-ence (Usenix ATC) (June 2008).

[17] YEE, B., SEHR, D., DARDYK, G., CHEN, J., MUTH, R., OR-MANDY, T., OKASAKA, S., NARULA, N., AND FULLAGAR, N.Native client: A sandbox for portable, untrusted x86 native code.In Security and Privacy, 2009 30th IEEE Symposium on (May2009), pp. 79 –93.

13