SMash: Secure Component Model for Cross-DomainMashups on Unmodified Browsers

Frederik De Keukelaere, Sumeer Bhola, Michael Steiner, Suresh Chari, Sachiko Yoshihama{eb41704, sachikoy}@jp.ibm.com, {sbhola, msteiner, schari}@us.ibm.com

IBM Tokyo Research Laboratory, Kanagawa, Japan; IBM T.J. Watson Research Center, New York, USA

ABSTRACTMashup applications mix and merge content (data and code)from multiple content providers in a user’s browser, to pro-vide high-value web applications that can rival the user ex-perience provided by desktop applications. Current browsersecurity models were not designed to support such appli-cations and they are therefore implemented with insecureworkarounds. In this paper, we present a secure componentmodel, where components are provided by different trust do-mains, and can interact using a communication abstractionthat allows ease of specification of a security policy. Wehave developed an implementation of this model that workscurrently in all major browsers, and addresses challenges ofcommunication integrity and frame-phishing. An evaluationof the performance of our implementation shows that thisapproach is not just feasible but also practical. The tech-nology discussed in this paper allows mutually mistrustingclient-side components to communicate safely without anymodifications to current browsers, and hence has the poten-tial to achieve immediate and widespread adoption.

Categories and Subject Descriptors: D.2.0 [General]:Protection mechanisms, D.2.11 [Software Architectures]: In-formation hiding, domain-specific

General Terms: Security, design.

Keywords: Web 2.0, browser, mashup, component model,phishing.

1. INTRODUCTIONWeb applications increasingly rely on extensive scripting

on the client-side (browser) using readily available JavaScriptlibraries. One motivation for this is to enable a browser userexperience comparable to that of desktop applications. Theextensive use of scripting on the client side and program-ming paradigms such as AJAX [1] has also led to the growthof applications, called mashups, which mix and merge con-tent1 coming from different content providers in the browser.Mashups are now prevalent in a number of contexts, includ-ing news websites, which have integrity requirements, or webemail, which handles confidential information. They are es-sential to an advertising supported business model, and for

1 We use the term content to refer to active content, i.e.,both data and JavaScript.

Copyright is held by the International World Wide Web Conference Com-mittee (IW3C2). Distribution of these papers is limited to classroom use,and personal use by others.WWW 2008, April 21–25, 2008, Beijing, China.ACM 978-1-60558-085-2/08/04.

allowing user-generated content in Web 2.0 websites. Thetremendous additional value that can be provided to users bymixing and merging content implies that such applicationswill eventually be prevalent in contexts with stricter datasecurity requirements, like consumer banking sites and en-terprise applications. Since existing browser security modelswere defined and developed without anticipating such appli-cations, these applications are pushing the boundaries ofcurrent browser security models.

Since content in a mashup application can stem from mu-tually untrusting providers, it is clear that they should bebuilt on a sound security foundation protecting the interestsof the various involved parties such as the content providersand the end-user. For example, consider a mashup applica-tion scenario of a car portal where information from multiplecar dealers, insurance companies and the user’s bank couldbe combined and co-resident on the user’s browser. It isclear that, at a minimum, we want certain security require-ments to be enforced, such as the dealer’s scripts not beingable to modify each others car prices, nor should they beable to spy on a user’s bank account information.

The traditional browser security model dictates that con-tent from different origins2 cannot interact with each other,while content from the same origin can interact without con-straints (reading and writing of each others’ state). Thismodel does not support mashups, where controlled interac-tion is desirable. To overcome the no interaction restriction,mashup developers typically enable interaction by either (1)using a web application proxy server which fetches the con-tent from different servers and serves it to the mashup, or(2) by directly including code and data from different ori-gins (using <script> tags). In both cases, it appears tothe browser that the mashup originates from a single origin,though it contains content from different trust domains3,enabling uncontrolled interaction.

In this paper we examine the problem of building se-cure componentized mashups. We propose an abstraction onwhich security policies can be specified, and an implementa-tion that realizes this abstraction for unmodified browsers.

2Origin is a pair of hostname (DNS domain or IP address)and URI-scheme (protocol) from a given URL. The “same-origin policy” [2] usually includes also the port. However,this is not done by all browsers, e.g., Internet Explorer 6ignores ports when comparing origins.3Clearly trust domain is not the same as DNS domain. How-ever, designing a secure solution for current browsers in-volves some mapping between the two. In the remainder ofthe paper, the term domain used alone refers to DNS domainor IP address.

1

1.1 Our ApproachOur abstraction involves encapsulating content from dif-

ferent trust domains as components running in a browserwindow. Components can be loaded and unloaded dynam-ically, as the application in the browser window evolves.Components are wired together using communication chan-nels, which are the only means for them to interact in thebrowser. The channel abstraction and security policies as-sociated with channels are implemented by an event hubthat is part of the Trusted Computing Base (TCB) fromthe mashup provider’s perspective. Components are loadedfrom their own server (as opposed to being proxied or usinga <script> element) and isolated from the mashup applica-tion code. This has security advantages in (1) not requiringthe component to completely trust the mashup application,and (2) making the component abstraction compatible withpassword anti-phishing mechanisms that use the component(DNS) domain or the certificate of the SSL connection, likePasspet [3] and Microsoft CardSpace [4].

By creating a high level abstraction for cross-componentinteraction, we ensure that the different communication tech-nologies used in our implementation can be replaced by,or even combined with, other technologies as they becomeavailable on the browser platforms.

We realize the component abstraction using the HTML<iframe> element (Section 16.5 of [5]), which was designedas a container for loading sub-documents inside the maindocument. The technical challenges that we address in theimplementation are (1) enabling parent to child documentcommunication links when the parent and child are fromdifferent trust domains, (2) ensuring integrity and confiden-tiality of information on these links, and (3) guarding againstframe-phishing, where a malicious component in a mashupcan change which component is loaded in another part of themashup. Our implementation is a JavaScript library whichis used by the mashup and component providers. It is avail-able as open-source in the OpenAjax Alliance [6] Source-Forge project. We have tested our library on Internet Ex-plorer (IE), Firefox, Safari, and Opera.4

There are several competing technologies under develop-ment that attempt to address the problem of secure mashups.We briefly contrast them here and discuss them in more de-tail in related work (see Section 6). Many of these proposalsrequire HTML and browser modifications, but the long timeline of adoption by standards committees, browser vendors,and eventually by end-users, makes these nonviable for any-one wanting to build secure mashups in the near term. In ad-dition, there are some proposals that work without browsermodifications. These are either targeted at client-servercross-domain communication for mashups, which is a verydifferent programming model, or web widget/gadget deploy-ments. Our components have some conceptual similaritywith web widgets, but need not have a user-interface. Also,web widget deployments offer a programming abstractiononly to widget developers, not mashup developers. All theseproposals typically, (1) are vulnerable to frame-phishing, (2)consider untrusted components but not untrusted mashupapplications.

4More specifically, the tested browser versions are InternetExplorer 7.0, Firefox 2.0.0.7, Safari 3.0.3, and Opera 9.24.There is no technical reason, though, that the library wouldnot work on different versions or other browsers.

1.2 Building Secure MashupsWe believe that using our high-level abstraction of com-

ponents which communicate through a mediated event hub,using channels, will provide a key primitive for secure com-ponentized mashups. The mashup provider does not needto proxy all the components so that they appear to be fromthe same origin, nor resort to other unsafe practices, suchas directly including scripts from different domains. It isalso in line with the general principle of least privilege [7]:unavoidable programming and configuration errors mandatedecomposition of web applications into small isolated unitseven when they come from the same administrative domain.Finally, it provides a general security mechanism to guardagainst cross-site scripting (XSS) attacks, as discussed next.

In the context of attacks on web applications, XSS at-tacks [8] are getting significant attention. These affect aspecial case of a mashup, where a website insecurely com-bines content generated by the website with content gener-ated by its users, which are different trust domains. XSSattacks allow user-generated malicious content to not justread and write website-generated (trusted) content, but alsogives it access to browser-cached credentials (e.g., cookies)for that trusted content. The common XSS mitigation ap-proach is to disallow users to generate content that containsJavaScript, using content filters, but this is both (1) difficultto implement, resulting in many attacks against incompletecontent filtering, and (2) limiting for user creativity. Us-ing our component abstraction, user-generated code can besafely placed in a separate, less-trusted component.

The paper is structured as follows. In Section 2 we presentour secure component model, followed by a discussion of se-curity policies in Section 3. Then we describe our imple-mentation and how we addressed various attack vectors inSection 4. We present a performance evaluation in Section 5,discuss related work in Section 6, and conclude in Section 7.

2. SECURE COMPONENT MODELIn this section, we describe our secure component model

for mashups. As discussed in the introduction, the currentbrowser security model either allows different content to ar-bitrarily interact if they are from the same origin, or disal-lows all interaction if they are from different origins. Thus,it is clear that the current browser security model is in-sufficient for mashup applications. What is desirable is anew security model that allows content to be separated bytrust domain, with a carefully mediated interaction betweensuch separated content. Furthermore, to make this accessi-ble from a programmer’s perspective, there must be a highlevel programming interface that allows creation of securemashups, and makes this easy.

Both from a programmability and usable security perspec-tive, it is essential to follow the concept of information hid-ing [9] by limiting the exposure of internal design and state.Thus, our model is analogous to using a message-passing in-teraction style instead of a shared-memory style. We firstpresent the model, and then explicitly specify the securityrequirements.

2.1 ModelFigure 1 graphically represents, in an abstract manner,

our proposed model for secure mashups. The model consistsof components, with input/output ports, and an event hub,with mediated communication channels.

2

Figure 1: Component Model

The mashup application, provided by the mashup provider,consists of an event hub and one or more components, whichcan be provided by third-party component providers. Com-ponents could be visible or invisible. Visible componentsshare the browser display in a manner determined by themashup application. A component contains (active) contentfrom one trust domain. The components, and therefore alsothe trust domains, are logically separated and can only com-municate with each other through the mediated channelsimplemented by the event hub. A component may spec-ify input/output ports (respectively depicted in the figureby white and gray ellipses) that define the types of inputand output that the component expects in order to functionproperly. The event hub wires the component ports to theappropriate channels (depicted by the arrows in Figure 1).

The event hub is a publish/subscribe system with many-to-many channels on which messages are published and dis-tributed. This model differs from a traditional publish/sub-scribe model by separating the namespace of the compo-nent ports from the namespace of the channels. This avoidsclashes in the namespace of the component ports and en-hances the re-usability of the components. In Figure 1, Com-ponent A can publish to Channel 1 and Channel 3 and issubscribed to Channel 2 and Channel 3. The channels sup-port asynchronous pass-by-value communication. An asyn-chronous model, though typically considered harder to pro-gram to, is a natural one for applications running in thebrowser, since they have significant logic for asynchronousevent handling related to user-interface (UI) events. In ad-dition, an asynchronous model allows more implementationchoices, since application code running in a browser is single-threaded.

The model can be extended hierarchically, i.e., a compo-nent could contain sub-components, and an event hub whichmediates between these sub-components.

2.2 Security RequirementsWe explicitly list the security requirements for the previ-

ously presented model, when embodied in a browser.

1. The DOM (Document Object Model) [10] tree of eachcomponent is completely isolated from other compo-nents. That is, there is no reading and writing of DOMelements across trust domains.

2. The JavaScript namespace of each component is com-pletely isolated from other components.

3. Components can be loaded directly from the compo-nent provider. From a security perspective, this has

the following advantages: (1) A component is pro-tected (isolated) even from the mashup applicationcode; (2) It is compatible with password anti-phishingmechanisms, like Microsoft CardSpace [4] and Pass-pet [3], that take into account the (DNS) domain of thecomponent, or the certificate of the SSL connection.This is important if the component needs to authen-ticate the user to perform its function; (3) It retainsthe possibility of using cookies, secured by the DNSdomain, as is still common practise for session authen-tication. This also has the benefit of not needing todeploy an additional web proxy.

4. Inter-component communication is secure: Maliciouscomponents can not affect the integrity and confiden-tiality of communication between other componentsother than (unavoidable) denial-of-service attacks re-sulting in aborted connections. Specifically, the modelprovides one-way authentication of components to themashup application. Mutual authentication could beimplemented with a slightly more elaborated protocol.However, the context in which we use our client-sidelibrary does not require it: that aspect is addressedwith server-side access control for component loading(section 3.2).

5. Component loading and unloading is completely un-der the control of the mashup application. A ma-licious component cannot replace a peer componentin another part of the application without detectionand appropriate (context-specific) remediation by themashup application.

6. Channel access control is completely under the controlof the mashup application.

Limiting Trust in Mashup Application Based on thesesecurity requirements, a mashup application cannot directlyattack the integrity or confidentiality of a component. How-ever, a component has to trust the mashup application forthe integrity of its user interface (excluding user authenti-cation, as mentioned above). This is reasonable from anend-to-end perspective since the end-user trusts the mashupapplication for integrity of the overall user interface (UI),and there is a simple delegation of trust from the mashupapplication to components for parts of the UI. Note thatthe mashup application cannot attack the confidentiality ofinformation displayed by a component in its UI.

A component needs to trust the mashup application forintegrity and confidentiality of communication with its peercomponents. Removing this trust is expensive without in-built browser support. The cross-document messaging pro-posal in HTML 5 (section 6.2) addresses this.

3. SECURITY POLICYThe component model described in the previous section

provides component isolation and mediated inter-componentcommunication. To describe which component interactionsare permitted and which are forbidden, we need to define asecurity policy for the model.

The policy specification can be derived from many sourcesof high level policies. This is especially true for enterprise-class mashups, where the security policy may be a com-bination of enterprise-level policy, department policy, and

3

end-user policy. Component providers may want to expresshow their components are to be integrated into a mashupapplication. For example, a component provider may con-strain what data is exposed by the component to a mashupprovider, and what the mashup provider may do with it.On the other hand, mashup providers may not trust compo-nents equally, and may want to prevent certain componentsfrom communicating with each other. In general, securitypolicies for componentized mashups can have many facets,depending on which entity specifies the policy.

We have identified two different levels at which policiescan be expressed: low level policies that express basic accesscontrol, and high level policies which express interactionsat a more semantic level. We consider basic access controlpolicies in the remainder of this section. We envision thatbasic policy is derived by inputs from high level policies.

Next, we describe two complimentary aspects of accesscontrol: component interaction in the browser, and compo-nent to server interaction. Both are necessary for end-to-endcontrol on what accesses are permitted to whom.

3.1 Component Access Control in the BrowserThis controls who is allowed to (1) create and destroy

named components, (2) create and destroy named channels,and (3) which components can publish or subscribe to eventson a named channel. The policy is enforced by the eventhub. The subjects in the policy are named components ortrust domains.

We consider a special case of such a policy, where com-ponent and channel creation (and destruction) can only bedone by the mashup application. This special case is in linewith current practice, and has the advantage that it makespolicy specification very straightforward. The policy is im-plicitly specified by the mashup application code by, creatingchannels, loading the different components, and then wiringthem together by specifying the channels that connect tothe input/output ports of each component.

Another alternative is for the event hub to read securitypolicy constraints from a configuration policy file. This pol-icy file could possibly be provided outside of the mashupapplication, potentially even by third parties. In this sce-nario, when input ports are being wired to channels (i.e.,components are being subscribed) or output ports are beingwired to channels (i.e., components are given permission topublish) the event hub checks if this is an allowed interac-tion according to its policy file. This decouples the policydefinition from the actual coding process of the mashup ap-plication and enables scenarios in which the mashup devel-oper is not the one defining the policy for the componentinteraction.

3.2 Component to Server Access ControlFor non-public services exposed by web servers, user au-

thentication is typically required in order to perform theaccess. Components should not have to trust the mashupapplication to acquire user credentials. Following the prin-ciple of least privilege [7], the authentication should also becoupled with limited delegation logic, e.g., as in SecPAL [11].

While the details of our current solution are outside thescope of this paper, we give a brief overview here. In addi-tion to traditional user authentication, potentially improvedby phishing-resistant technologies such as CardSpace [4], ouraccess control model authenticates a component and its as-

sociated (limited) access rights, as well as the mashup appli-cation it is loaded in. In particular, it makes sure that com-ponents are loaded in a proper iframe of the component’sdomain, not vulnerable to a man-in-the-middle attack, andonly after verifying that the requesting code has explicitlybeen granted the right to load the component. This ap-proach allows us to have a unified access control policy spec-ification for expressing limited delegation within and acrosstrust domains, and for both client-side mashups (mashuphappens in browser) and server-side mashups (mashup hap-pens at server). Our solution can be considered an extensionof current authentication and delegation protocols, such asYahoo’s BBAuth [12] or Google’s AuthSub [13].

The authentication is based on two credentials, user cre-dentials and code credentials. User credentials are used toauthenticate the secure channel to the user’s browser and tobootstrap the secure loading of components into an iframefrom the proper domain. Each component contains an addi-tional code credential, imprinted at creation time. To autho-rize a service request, the requester has to prove possessionof both the user and code credential.

4. IMPLEMENTING THE MODELIn this section, we discuss our design and implementa-

tion of the secure component model. Our approach is toleverage the current browser security model to isolate com-ponents belonging to different trust domains, and then toenable interaction by sending-receiving on named compo-nent ports. These get translated to send-receive on namedshared channels. Our approach does not require any browsermodifications, hence adoption can be immediate.

In section 4.1 we give some background on browser ab-stractions and their security, which is relevant to our solu-tion. Section 4.2 provides an overview of our solution, andsection 4.3 gives details on the key aspects of the solution.

4.1 BackgroundWe review a few concepts from HTML documents and

their properties, including the “same-origin” security policyof browsers.

An HTML document loaded into a browser is representedin an object model called the Document Object Model. Adocument has a domain property which is the hostname ofthe server it was accessed from. The hostname could be anumeric IP address or a DNS domain name. DNS names arehierarchical, and browsers allow a document to relax its ori-gin via the domain property. For instance, a document withdomain foo.bar.baz.com can change it to bar.baz.com orbaz.com. A document has a window object with a location

property that represents the URL of the document. It ispossible to change the location property of the document,by updating the window.location. This will cause a newdocument to be loaded to and to replace the current docu-ment in that window.

Documents can include frames using HTML <frame> and<iframe> tags where each frame is a document with domain

and location attributes (and a window object). Frames caninclude sub-frames, forming a hierarchy, which we will referto as a frame hierarchy. For consistency of terminology, wewill refer to even the top-level document in the frame hier-archy as a frame. The “same-origin” policy says that doc-uments from different domains that are in the same framehierarchy cannot examine or alter each others internal state.

4

Figure 2: Isolated components with component-mashup communication

Code running in a frame can read/write the internal state ofall documents from the same origin (that is, domain) thatare part of the same frame hierarchy. For purposes of ourdiscussion, we will use the terms origin and domain inter-changeably.5

Even if frames are from different domains, a frame cantypically write the location property of any frame in thesame frame hierarchy, regardless of origin. Such browsersare labeled permissive browsers [14], and include Firefox,Safari, and some configurations of IE 6 and IE 7. Howevercode from one domain can never read the location propertyof a frame from another domain.

4.2 Solution OverviewIn this section, we give an overview of the key features and

issues addressed in our solution, which include componentisolation, enabling and securing component-mashup commu-nication links, and protection against frame-phishing.Component isolation using iframes: In our solution,we load components which come from different trust do-mains into different iframes, i.e., they represent differentsub-frames. Even in the case where a single host is serv-ing components from multiple trust domains, isolation isobtained by having the host use multiple DNS names, onefor each trust domain.6 However, given that componentscan change their domain properties as described earlier, theDNS domains used are such that a component cannot relaxits domain property to attack another component. For in-stance, a server foo.bar.com that serves components fromtrust domain t1 and t2 can create two DNS domains t1.foo.bar.com and t2.foo.bar.com. Unless both components re-lax to the same super-domain no attacks are possible.Component-mashup communication links: While iso-lation can be achieved by placing components in differentframes, the challenge is to enable cross-domain inter-com-ponent communication, since it is not explicitly supportedin browsers. Recently, an approach to communicate be-tween iframes using the fragment identifier of the URL ofthe iframe has been discovered [15]. The communication isbased on the observation that even though the parent andchild iframes have different origins, the parent can write to

5 Origin is not identical to domain, as origin is semanticallysomething that cannot be modified, and indeed this con-stant aspect of origin is taken into account for constrainingXMLHttpRequest. However, the distinction is not criticalto our discussion.6HTTP virtual hosts and DNS aliases, e.g., wildcard re-source records, allow easy realization of such co-residence.

the child’s location property. Note that if we only modifythe fragment identifier of the location property the docu-ment will not be reloaded and hence the document state canbe preserved because the fragment identifier was designed tobe used for navigation inside a document. This techniquehas been used in the Dojo JavaScript toolkit [16] to circum-vent the same-origin policy for client-server communication,and more recently in XDDE [17]. We reused this techniqueto enable communication between components.

As mentioned previously, browsers vary in the constraintsthey place on navigating the frame hierarchy. Hence, oneneeds to organize the iframes in a way that allows for frag-ment communication. Figure 2 illustrates the iframe config-uration used with three trust domains in the mashup. Thefirst trust domain, represented by origin www.mashup.com,is that of the mashup application. It uses two components,both from the same server with DNS domain component.

com, but from two different trust domains. To leverage theiframe isolation, the components are loaded from differentorigins: component A is loaded into c1.component.com andcomponent B into c2.component.com. In each of the compo-nents, there is a tunnel iframe loaded from www.mashup.com.This tunnel can access the JavaScript context of the mashupapplication since it is in the same origin as the mashup appli-cation. The tunnel and the component iframes communicatecross-domain using fragment identifiers. We have also inves-tigated the use of other inter-frame communication mecha-nisms, details of which are described in Section 5.Link Security: Permissive browsers allow complete nav-igation of the frame hierarchy. For example, in Figure 2,component B can get direct access to the window object ofcomponent A even though they both come from differentorigins. Note that it is not possible for B to read the lo-

cation property of an iframe not in the same origin. Thisensures confidentiality of the link between component A andthe mashup. However, integrity is not guaranteed.

To ensure integrity, we extend the fragment communica-tion protocol with an additional security token. The detailsare discussed in the next section.Protection from frame-phishing: Since it is possiblefor a malicious component to write to the location propertyof another component’s iframe, it can navigate a componentaway from its URL to another, possibly malicious, URL. Werefer to this as frame-phishing, and is a common vulnerabil-ity of current sites that use iframes for isolating untrustedcontent.

Frame-phishing is dangerous for a number of reasons, (1)it compromises integrity of a part of the application viewthat was not meant to be controlled by the malicious com-ponent, (2) it can be used to steal information entered intothe phished frame, much like the more common phishing ofsites, which could include personally identifiable information(PII) or passwords. Since the URLs loaded by iframes arenot visible in the browser’s URL bar, one cannot rely on theend-user to detect frame-phishing, and so it has to be donein an automated manner.

Vulnerability to frame-phishing is also quite common. Awell-known portal, aggregating components into a single page,suffers from this attack.7 Each component is placed in aniframe and comes from a server with a DNS alias which looks

7We did inform the provider about this vulnerability. How-ever, as countermeasures are only about to be put in place,we refrain from naming it explicitly.

5

Browser

Mashup Application

Component A

Event Hub

Event Comm

Frag Comm

Frag Comm

Event Comm

Component B

Event Hub

Event Comm

Frag Comm

Frag Comm

Event Comm

Channel 1 Event Hub

1

2

3 4

5

6 7

8

9 10

11

12

7

8

9 10

11

12

Figure 3: Layered communication stack

like <n>.foo.com, where <n> is a small integer. Thus oneach page the component appear to come from different do-main providing isolation. However, there is a serious flaw inthe implementation: the binding of the component to DNSalias is not global. The server <n>.foo.com can proxy andserve any component. To attack this, we were able to createcomponents which successively loads itself from 1.foo.com,2..foo.com,.... Once loaded from a particular DNS location,it traverses the frame hierarchy of the document, reading thelocation of the different component iframes. If it shares thesame origin as the attacked component, it can read the loca-tion property and then replace the location U of the the framewith the URL http://<man-in-the-middle>/U where theserver at <man-in-the-middle> is controlled by us and canthus transparently relay and completely record the interac-tion of the user with the site at url U, including any cre-dentials which the user may supply to this site. Since ourmalicious components can quickly exhaust the small num-ber of aliases used to serve components, we can easily hijackthe entire set of components. Furthermore, this attack alsocompletely circumvents the inherent masquerading protec-tion provided by the offered personalization.

Note that frame phishing is not only limited to changingthe location of a component’s iframe. It can be performedon the tunnel iframe, and even the main mashup document.One could argue that such an attack on the mashup docu-ment could be detected using the browser’s URL bar, but(1) the URL bar has been shown to offer very weak phishingprotection [18], and (2) the timing of the attack can be ar-bitrary, unlike conventional phishing attacks. For instance,a user that keeps a web application open in one of the tabsof their browser could be attacked at an arbitrary point inthe lifetime of the application, after the user has verified theURL in the URL bar.

We use a combination of event handlers, timeouts, andcommunication using the tunnel iframe, to detect such at-tacks. The details are discussed in the next section.

4.3 Solution DetailsOur implementation is the SMash JavaScript library used

by both the mashup application and component program-mer. The library is structured as a layered communication

stack, where the peer layers in the component and mashupapplication communicate using the lower layers. This isshown in Figure 3: the event hub layer, event communi-cation layer and the fragment communication layer.

The event hub layer is aware of component ports andchannels wiring these ports. In the mashup application, thislayer is responsible for loading and unloading components,creating and deleting channels, and wiring the ports of thecomponents to channels. In a component, this layer is awareof the component’s ports and handles sending and receivingevents on these ports. The event communication layer is re-sponsible for composing the messages which are used to mul-tiplex the multiple component ports on a single link. Thefragment communication layer is the only layer aware of theuse of fragments to communicate between the componentand the mashup application. By substituting this layer, it ispossible to employ another low-level communication mecha-nism, e.g., inter-iframe communication potentially built intofuture browsers (see Section 6).

In the following subsections, we describe the API offeredto mashup and component programmers, provide some de-tails on fragment communication and corresponding integrityprotection, and describe how we detect frame-phishing.

4.3.1 APIThe API offered by SMash is shown in Table 1. Most

of the API is self-explanatory. We draw, though, atten-tion to the component state lifecycle, shown with the get-

ComponentState function. This state management is of-fered as a way for the programmers to deal with the asyn-chrony of component loading/unloading, and the concur-rency of wiring a loaded component. The state transitionfrom loaded to wired is done by the mashup application,to indicate to the component that it can start publishingevents. The transition to startedCleanup is also done by themashup application, when it intends to unload the compo-nent, while the transition to doneCleanup is typically doneby the component (subject to a timeout, to handle misbe-having components). The remaining transitions are initi-ated inside SMash. To avoid polling of component state,the constructors of the hub (not shown) allow the mashupapplication and the component to register listener functionson the state transitions.

4.3.2 Fragment Communication and Link IntegrityAs mentioned earlier, fragment communication is used to

implement the links between the mashup application and acomponent. However, such communication is limited sincecurrent browsers implement a limit on the URL length. InSMash, we work with a conservative limit of 4000 bytes,which works well in all major browsers. Long messages haveto be split correspondingly into segments which, with pay-load and protocol overhead, do not exceed that limit.

To send a segment to the tunnel, the component writes itto the fragment in the tunnel’s location property, and viceversa. To write the next segment, the component has towait till the previous segment has been read by the tunnel.This is implemented by using a periodic timer at both thecomponent and the tunnel, and polling for changes to one’sown location property. As the component cannot read thelocation of the tunnel, it needs to get an explicit acknowl-edgment when the tunnel has read the previous segment.This is accomplished using acknowledgment messages.

6

Mashup API

loadComponent(componentId,inPortNames,outPortNames) load a component with a given id

createChannel(channelName) create a channel with the given name

deleteChannel(channelName) delete a channel

addReader(channelName, componentId, inPortName) wire an input port to a channel

addWriter(channelName, componentId, outPortName) wire an outport port to a channel

removeReader(channelName, componentId) unwire an input port

removeWriter(channelName, componentId) unwire an output port

broadcastOnChannel(channelName, message) event broadcast by mashup application

getComponentState(componentId) get component state: start→loaded→wired→startedCleanup→doneCleanup→unloaded

componentWired(componentId) transition to wired state

startCleanupComponent(componentId) transition to startedCleanup state

Component API

getComponentState() get component state

registerCallback(inPortName, callback) register function to handle event on input port

publish(outPortName, message) send event on output port

doneCleanupComponent() transition to doneCleanup state

Table 1: API

Link Integrity: As mentioned previously, link confiden-tiality is implicit in fragment communication. For link in-tegrity, we have to guard against a malicious componentmodifying the location property of a peer component orthe peer’s tunnel.

We cannot prevent a malicious component from modify-ing location. However, it can only do so atomically, i.e.,it has to overwrite the complete value of the current frag-ment (overwriting the non-fragment part is discussed underframe-phishing, in the next section). Therefore we use theapproach of embedding a shared secret, in each fragment, toauthenticate the sender of the fragment, and hence ensureits integrity. This shared secret is embedded in the clear,as the attacker cannot read the location. Note that this issufficient to provide (one-way) authentication of the compo-nent to the mashup application as required by Section 2.2.If we would require direct mutual authentication using theidentity implied by the domain of the tunnel-url (instead onrelying on component-load access control), a protocol suchas Lowe-Needham-Schroeder [19] could be used.8

We also need to securely distribute this shared secret be-tween the mashup application and the component. TheSMash library in the mashup application creates the secret,an unguessable random value. 9 When creating the com-ponent, it includes the secret in the fragment of the compo-nent URL. When the component creates the tunnel iframeit passes the secret in the same manner. After receiving thesecret, the tunnel iframe provides the secret to the mashupapplication which verifies if the received secret is the sameas the originally generated secret. If it is the same, it allowsthe tunnel to accept this secret as proof of message integrity.If not, the application is informed, which can take somerecovery action, for instance, unloading and reloading thecomponent. One of the reasons for doing the initial secretdistribution to the component using the fragment part of theURL is that RFC 2616 forbids fragments in the <Referer>

8We thank Colin Jackson and Adam Barth for the corre-sponding suggestion.9Unlike a nonce in cryptographic protocols, which is usedto protect against replay attacks, we use the same randomlygenerated value repeatedly on the same link. This is secureas there is no possibility of eavesdropping and so we can usethis value as an authenticator.

header. So this secret will not be leaked by the componentto remote parties when it loads data from them.

To ensure that the attacker cannot mount an attack bydeleting fragments, we use sequence numbering on consec-utive fragments, so missing fragments will be detected andattributed to an attack. We currently do not try to recoverfrom such attacks by retransmitting, and leave it up to theapplication to decide on the high-level action to take. Onereasonable action would be to (1) notify the mashup serverabout the components present in the application when theattack occurred, (2) notify the user, say using an alert box,and then (3) shut down the application. The notification tothe server can be used to search for the possible attacker,since we cannot identify the attacker in the browser.

4.3.3 Protection from Frame-PhishingAs described earlier, frame-phishing is a dangerous attack

on mashups that use iframe isolation. We describe how wedetect such attacks in SMash.

Since the mashup application cannot read the location

property of its components, we cannot simply poll for changesto this value. The parent iframe could set onload and onun-

load event handlers on the child iframe. But browser imple-mentations vary and are unreliable in invoking these han-dlers when a child event happens. We use a combination ofonunload event handler on one’s own frame (which in ourexperience is reliable), timeouts, and communication usingthe tunnel iframe, to detect such attacks.

There are three targets to consider with respect to suchattacks: (1) component, (2) tunnel, (3) mashup application.

When the component is replaced by an attacker, the com-ponent’s onunload event handler is called. At this point, itcould try to notify the mashup application. However, since itcommunicates with the mashup application asynchronously,using the tunnel, there is no guarantee that this communi-cation will succeed before the unload completes. Instead, weutilize the fact that replacing the component will also causethe onunload event on the tunnel to fire, as it is a child ofthe component iframe. The tunnel can communicate syn-chronously with the mashup application using a JavaScriptfunction call, and informs it of the unloading before it re-turns from the onunload event handler. Hence, we handlecases (1) and (2) in a unified manner.

7

Another possibility for the attacker is to replace the com-ponent before the tunnel iframe is loaded. This case is han-dled by setting a timeout, in the mashup application, for suc-cessfully establishing initial communication with the tunnel.If this timeout expires, an application specific error-handleris called, which could decide to unload and reload the com-ponent.

Using the tunnel’s onunload event handler, though, posesa challenge as the event is also called when the user nav-igates away from the mashup application. To avoid falsepositives, we briefly delay the alert issuing in a timer. Thetimer will only fire and notify the application of a potentialframe-phishing attack, if the user remains in the mashupapplication.

Finally, we need to detect frame-phishing of the mashupdocument. We have found it hard to distinguish between thetwo cases of either a frame-phishing attack, or the user vol-untarily navigating away from the document. In the interim,we use an alert box to notify the user about the change inthe document URL. This has a negative impact on usability,but in the absence of browser support to distinguish the twocases, it seems the only way to ensure protection of the user.

The authors acknowledge that providing the end-user withpop-up warnings, albeit being a best effort, is hardly a fail-safe solution. However, there are limits what can be donewith current browsers. The ideal solution to these prob-lems is to revisit browser policies and fix browsers corre-spondingly. Recently, there has been an in-depth study ofthe navigation behavior of browsers resulting in several im-provements [20]. Until these fixes become widespread, oursolution can be applied on current browsers.

5. PERFORMANCE EVALUATIONIn this section we describe a preliminary performance eval-

uation of our implementation. The evaluation consists ofmicro-benchmarks in which we vary the number of com-ponents, to measure the scalability of the implementation(assuming all components are in different trust domains).Additionally, we vary a system parameter, the polling timerinterval used for fragment communication, to see how it im-pacts communication throughput. The metrics used in theexperiments are:

1. Event Rate: This measures the maximum event ratewe can sustain, for small event payloads. This is typ-ical for many mashup applications where componentsexchange short events in response to user actions.

2. Data Throughput: This measures the maximum rate inkilobytes/s, and is important for data intensive mashupapplications that want to transfer large volumes ofdata between trust domains, inside the user’s browser.

3. Component Load Latency : This measures the latencyto load a component and setup the communication linkbetween the component and the mashup application.

Next, we describe our testbed, followed by the results foreach of the above metrics. Finally, we briefly discuss usingan alternative inter-frame communication mechanism thatuses Java applets, in the context of SMash.

5.1 TestbedTo do a fair comparison across the different browsers, all

tests were performed on exactly the same test platform. The

underlying test machine was an Intel Core 2 Duo T7300 @2.0 GHz with 2 GB of RAM. This machine was runningWindows XP with VMware player 2.0.1. The actual perfor-mance evaluation was done on a VMware virtual machineemulating a single processor @ 2.0 GHz, 1 GB of RAM andrunning a clean fully patched Windows XP. Within this ma-chine, we had Apache Tomcat 6.0.14 serving the data tothe browsers. All of the tests were performed on Firefox2.0.0.7, Internet Explorer 7.0 (IE), Safari 3.0.3, Opera 9.24.To minimize measurement errors, all tests were performedmultiple times until the standard deviation of the resultsbecame acceptably small. The main text presents only theevent rate and data throughput results for Firefox and IE,since they are the most popular browsers. Correspondingdata for Opera and Safari can be found in the Appendix.

5.2 Event RateWe used a small payload of 13 characters, representing a

simple event name/value pair. Figure 4 (top) gives a sum-mary of the measured performance as the number of com-ponents is increased from 1 to 32 and the polling timer isvaried from 10ms to 80ms. Both the X and Y axis are on alog scale.

For each browser we observed a saturation point. Thispoint, mainly caused by CPU load, varies across browsers,timer intervals, and number of components. Prior to reach-ing this saturation point, there is a linear increase in aggre-gate rate with increasing number of components and timerfrequency. Once the saturation point is reached, and morecomponents are added, or the timer frequency is increased,performance loss due to over-saturation becomes apparent.An adaptive timer frequency, that detects and reacts to over-saturation, may be able to avoid this behavior. Overall,Firefox shows significantly better performance than IE.

For many mashups the inter-component events are trig-gered by user actions, requiring only a low event rate. Themeasured rates are sufficient for such applications.

5.3 Data ThroughputThe data throughput was tested by transferring a total of

1 megabyte (MB) of data from the mashup application to thecomponents. Given the approximately 4 kilobyte (KB) limitof the fragment payload10, this resulted in transferring 256messages from the mashup application to the components.Figure 4 gives a summary of the measured performance.

Like the event rate experiments, the throughput increaseslinearly with the number of components and timer frequency,prior to the saturation point. At the saturation point, addingadditional components or increasing the timer frequency re-sults in degraded performance.

5.4 Component Load LatencyFor evaluating the component loading performance, we

measured per component loading latency while increasingthe number of components being concurrently loaded. Theoverall loading latency is measured from the moment atwhich the mashup application creates the components untilthe moment at which the mashup application receives con-firmation of a successful load of all components. This con-firmation is communicated across domains using fragment

10This limit was chosen based on the limit for IE, which hadthe smallest fragment length limit of the tested browsers.

8

Figure 4: Event rate (top) and data throughput (bottom) for Firefox and IE.

communication. Figure 5 gives an overview of the measuredperformance.

We observe that load latency does not increase with anincrease in number of components. In fact, the loading la-tency per component initially decreases and and then startsto increase back towards its initial value. The latter canbe explained by the additional system load due the concur-rent loading of many components. Note that caching wasdisabled on all browsers except for Safari 11.

5.5 Alternative Inter-Frame CommunicationAs mentioned in section 4.3, it is possible to employ alter-

native inter-frame communication mechanisms in SMash, byreplacing a layer in the communication stack. In particular,alternatives such as Java applets, Adobe Flash, or GoogleGears, though lacking universal support in browsers, couldbe used to increase throughput when available. In this ex-periment, we investigated the use of Java applets.

Our implementation employs different components thatload applets from the same location, and use the static vari-ables of the applet to communicate in a secure manner withthe mashup application (ensuring that components cannotinterfere with each other’s communication). The LiveCon-nect feature in browsers is used to communicate between acomponent written in JavaScript and the low-level communi-cation layer written in Java. We use polling from JavaScriptto Java to detect the reception of a new message. This isnecessary since browsers enforce the same-origin policy, andprevent a method call from Java to JavaScript from crossingorigins.Results: On both Firefox and IE there were stability prob-lems in loading large number of applets on the same page, sowe limited the throughput tests to pages which had no morethan 8 applets, which implies no more than 8 components.For Firefox and Opera we observed aggregate throughput of16 MB/s, independent of the number of components. For IE,

11We were unable to disable caching on Safari due to theunavailability of cache configuration parameters.

Figure 5: Component loading latency.

we observed an aggregate throughput of 8 MB/s. Our con-clusion is that for browsers that do support Java applets andLiveConnect, componentized mashup applications could usethis mechanism to get significantly higher throughput thanfragment communication.

6. RELATED WORKRelated work can be largely divided into three groups:

proposals working with unmodified browsers; extensions toHTML requiring browser modifications; solutions based onbrowser plugins. In the following subsection, we will have acloser look at each of them.

6.1 Unmodified BrowserAlternatives for unmodified browsers fall into three cat-

egories: (proxied) iframes with client-side communication,(proxied) iframes with server-side communication, and server-side induced JavaScript rewriting or restrictions.

6.1.1 Iframes with Client-Side CommunicationClosest to our work are XDDE [17] and the recently an-

nounced Google PubSub [21]. Both use iframes and frag-ments for client-side communication similar to our approach.Neither of them, though, seems to address the integrity andframe-phishing issues raised and addressed in this paper.

9

A second technique for client-side communication is Sub-space [14]. It exploits domain-relaxation of the domain DOMattribute, mentioned in Section 4.1, to place a request to aforeign service safely in an iframe served from a one-time-use sub-domain of the mashup server. While their primarygoal is secure cross-domain client-server communication, itcould also be used for secure cross-domain component com-munication within the browser. After some setup cost in-volving multiple iframes, this solution allows exchange ofJavaScript objects of arbitrary length and hence scales verywell in terms of bandwidth. Depending on the particularbrowser, though, the event rate will be bounded by the limitsof polling similar to our approach. As a drawback, Subspacerequires that all connections are setup in the very beginning,prohibiting dynamic on-demand loading of components. 12

More importantly and contrary to our approach, Subspacerequires complete trust of the component providers in themashup provider as their code is executed in DNS domainscontrolled by the mashup provider.

6.1.2 Iframes with Server-Side CommunicationAn alternative to the above is to do server-side communi-

cation between client-side components that are representedas iframes. Each client-side component has a correspond-ing server-side communication object. Communication be-tween component A and B would occur by component Asending a message to its server-side communication objectwhich would pass it to component B’s communication ob-ject, which would then pass it back to component B. Thissolution requires asynchronous server to client communica-tion, which could be implemented using emerging techniqueslike the Bayeux protocol [23] and Cometd [24]. We did notchoose this approach since it needs a complicated connec-tion setup, and all component-component communicationin the client needs to go through two (logical) servers, withincreased server load and considerable latency.

6.1.3 JavaScript Rewriting or RestrictionsAn alternative to browser isolation mechanisms is to use

language analysis and rewriting. A combination of staticanalysis, language restrictions and dynamic code rewritingcould achieve isolation of JavaScript code [25, 26, 27, 28].However, due to the complexity of rewriting self-modifyingcode in weakly documented and varied runtime environ-ments, it makes it hard to verify that the isolation achievedis complete. Furthermore, it requires a trusted server, lim-iting the use to a single administrative domain. Finally, itfaces considerable performance and integration challengeson client as well as server side.

6.2 HTML ExtensionsThere are a number of competing proposals to extend

the HTML specifications with goals similar to our securecomponent model: the <module> tag proposal [29], cross-document messaging in the HTML 5 working document ofthe Web Hypertext Application Technology Working Group(WHATWG) [30] and the <friv> element proposal [31].

All three proposals provide an isolated DOM containerelement – essentially variations of <iframe> – which enablescross-domain communication by offering a message passing

12The open-source implementation CrossSafe [22] relaxes thisrequirement. However, it essentially requires all componentsto trust each other, clearly unacceptable for many contexts.

interface. Invoked in a controlled fashion and assisted byadditional meta-data about the caller, the receiving elementcan then process such messages in a secure way.

While the granularity of isolation in HTML5 is based onthe same-origin policy, different <module>s and <friv>s areisolated even when they are loaded from the same origin.This will simplify administration of servers hosting multi-ple components — not each of them has to be assigned aseparate DNS sub-domain — and encourage finer-granularcomponents. However, it raises the question of how wellit integrates with traditional authentication schemes, oftentied to the same-origin policy due to cookies.

The key difference from a programming model perspec-tive is that these proposals implement one port for eachcomponent, which multiplexes all communication, while wesupport multiple ports. In addition, we support (multi-cast)channels directly between components, and not just betweena component and the parent. This allows us to define fine-grained access control policies, which cannot be directly de-fined using these proposals. However, as pointed out in Sec-tion 4.3, these proposals could easily be integrated into ouroverall architecture by replacing the fragment communica-tion layer in Figure 3.

These proposals all require browser modifications and hencethere will be a considerable time lag before they are adoptedby all end-users.

6.3 PluginsA third communication approach is to use browser plug-

ins to facilitate cross-domain communication. Good candi-dates are Adobe Flash, Java Applets or Google Gears. Animplementations based on these can be more efficient (seeSection 5.5). They also increase the trust requirements, forapplets the components have to trust completely the mashupapplication, similar to SubSpace, and all of them it increasesthe TCB by including the code of the plugin. However,the required plugins might not be installed in each browser,or not even available on a given platform, and are mostlybased on proprietary technology. That said, as discussedabove for HTML extensions, such plugin-based cross-domaincommunication could serve, where available, as an alterna-tive provider in our lowest communication layer with thefragment-based communication as a guaranteed fallback.

7. CONCLUSIONThis paper addresses the problem of securing mashup ap-

plications which mix active content from different trust do-mains. As a solution, we propose a secure component modelcomprising a central event communication hub and governedcommunication channels which mediate the communicationbetween isolated components. We illustrated how such amodel can be used to enforce basic access control policieswhich define the allowed interactions between components.

We described SMash, an implementation of this model oncurrent browsers, which can be used right away in build-ing secure mashup applications. Our implementation de-pends on iframes for isolation while bootstrapping a publish-subscribe model of communication using URL fragment iden-tifiers. Our programming model is intentionally generalenough that other communication techniques could be usedinstead of URL fragments. SMash is resilient to attacks suchas channel spying, message forging, and frame-phishing. Wehave evaluated our implementation and find that it scales

10

well with increasing number of components in the mashup,and has enough data throughput to be useful in a number ofmashup application scenarios. Our implementation is avail-able as an open-source JavaScript library.

8. REFERENCES[1] Brett McLaughlin. Mastering Ajax. IBM

developerWorks, 2005 – 2007. http://www-128.ibm.com/developerworks/views/web/libraryview.jsp?

search_by=Mastering+Ajax+Part. (Cited on page 1)

[2] Mozilla.org. The same origin policy. http://www.mozilla.org/projects/security/components/

same-origin.html. (Cited on page 1)

[3] Ka-Ping Yee and Kragen Sitaker. Passpet: Convenientpassword management and phishing protection. InSymposium On Usable Privacy and Security, 2006.(Cited on pages 2 and 3)

[4] Microsoft. Windows cardspace.http://cardspace.netfx3.com,http://www.identityblog.com. (Cited on pages 2, 3,and 4)

[5] Dave Raggett, Hors Le Arnaud, and IanJacobs (Editors). HyperText Markup Language(HTML). W3C Recommendation 4.01, W3C, Dec,December 1999. (Cited on page 2)

[6] OpenAjax Alliance Open Source Project. http://openajaxallianc.sourceforge.net. (Cited on page2)

[7] Jerome H. Saltzer and Michael D. Schroeder. Theprotection of information in computer systems.Proceedings of the IEEE, 63(9):1278–1308, September1975. (Cited on pages 2 and 4)

[8] Kevin Spett. Cross-site scripting — are your webapplications vulnerable? Technical report, SPIDynamics, 2005. http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf. (Citedon page 2)

[9] David Parnas. On the criteria to be used indecomposing systems into modules. Communicationsof the ACM, 15(12):1053–1058, December 1972. (Citedon page 2)

[10] World Wide Web Consortium. Document ObjectModel. http://www.w3.org/DOM/. (Cited on page 3)

[11] Moritz Y. Becker, Cedric Fournet, and Andrew D.Gordon. SecPAL: Design and semantics of adecentralized authorization language. TechnicalReport MSR-TR-2006-120, Microsoft Research,September 2006. (Cited on page 4)

[12] Yahoo! Browser-based authentication (BBAuth).http://developer.yahoo.com/auth/. (Cited on page4)

[13] Google. Google account authentication (AuthSub).http://code.google.com/apis/accounts/

AuthForWebApps.html. (Cited on page 4)

[14] Collin Jackson and Helen Wang. Subspace: Securecross-domain communication for web mashups. In 16thInternational Conference on the World-Wide Web,2007. (Cited on pages 5 and 10)

[15] James Burke. Cross domain frame communicationwith fragment identifiers. http://tagneto.blogspot.com/2006/06/

cross-domain-frame-communication-with.html,June 2006. (Cited on page 5)

[16] Dojo Foundation. Dojo javascript toolkit. http://www.dojotoolkit.org/. (Cited on page 5)

[17] Gideon Lee. Personal communication on XDDE.http://www.openspot.com, 2007. (Cited on pages 5and 9)

[18] Rachna Dhamija, J.D. Tygar, and Marti Hearst. Whyphishing works. In Conference on Human Factors inComputing Systems (CHI 2006), 2006. (Cited on page6)

[19] Gavin Lowe. Breaking and fixing theNeedham-Schroeder public-key protocol using FDR.In Tools and Algorithms for the Construction andAnalysis of Systems (TACAS), volume 1055 of LectureNotes in Computer Science, pages 147–166.Springer-Verlag, Berlin Germany, 1996. (Cited on page7)

[20] Adam Barth and Collin Jackson. Protecting browsersfrom frame hijacking attacks. http://crypto.stanford.edu/frames/. (Cited on page 8)

[21] Google. Gadget-to-gadget communication. http://www.google.com/apis/gadgets/pubsub.html. (Citedon page 9)

[22] Kris Zyp. CrossSafe. http://code.google.com/p/crosssafe/. (Cited on page 10)

[23] Alex Russel, David Davis, Greg Wilkins, and MarkNesbitt. Bayeux protocol. Technical Report 1.0draft0,Dojo Foundation, 2007. (Cited on page 10)

[24] Teknikill, Shadowcat Systems, and SitePen, Inc.Cometd. http://www.cometd.com/. (Cited on page 10)

[25] Charles Reis, John Dunagan, Helen J. Wang, OpherDubrovsky, and Saher Esmeir. BrowserShield:Vulnerability-driven filtering of dynamic HTML. InProceedings of the Sixth Symposium on OperatingSystems Design and Implementation, November 2006.(Cited on page 10)

[26] Dachuan Yu, Ajay Chander, Nayeem Islam, and IgorSerikov. JavaScript instrumentation for browsersecurity. In 34st ACM Symposium on Principles ofProgramming Languages (POPL), pages 237–249,2007. (Cited on page 10)

[27] K. Vikram and Michael Steiner. Mashup componentisolation via server-side analysis and instrumentation.In Web 2.0 Security & Privacy Workshop. IEEEComputer Society, Technical Committee on Securityand Privacy, 2007. (Cited on page 10)

[28] Mark S. Miller, Mike Samuel, Ben Laurie, Ihab Awad,and Mike Stay. Caja — safe active content in sanitizedJavascript. http://google-caja.googlecode.com/files/caja-spec-2007-10-11.pdf, October 2007.(Cited on page 10)

[29] Douglas Crockford. The <module> tag. http://www.json.org/module.html, October 2006. (Cited on page10)

[30] Ian Hickson (Editor). HTML 5. Technical report, WebHypertext Application Technology Working GroupHTML 5, 2007. Working Draft, http://www.whatwg.org/specs/web-apps/current-work. (Cited on page10)

[31] Jon Howell, Collin Jackson, Helen J. Wang, and

11

Xiaofeng Fan. MashupOS: Operating systemabstractions for client mashups. In Proceedings ofHotOS XI: The 11th Workshop on Hot Topics inOperating Systems. USENIX, May 2007. (Cited onpage 10)

APPENDIX

A. COMPLETE PERFORMANCE EVALU-ATION RESULTS

Following the complete set of performance evaluation fig-ures omitted from Section 5: Figure 6 and Figure 7 give theevent rate and throughput, respectively, for all four testedbrowsers. Note that for Opera, we observed some anoma-lies in system load, that are probably due to a bug in therendering engine when using fragments in invisible frames.

12

Figure 6: Event rate for Firefox, Internet Explorer, Safari and Opera.

Figure 7: Data throughput for Firefox, Internet Explorer, Safari and Opera.

13