Most Websites Don’t Need to Vibrate:

A Cost–Benefit Approach to Improving Browser Security

Peter Snyder

University Of Illinois at Chicago

psnyde2@uic.edu

Cynthia Taylor

University Of Illinois at Chicago

cynthiat@uic.edu

Chris Kanich

University Of Illinois at Chicago

ckanich@uic.edu

ABSTRACT

Modern web browsers have accrued an incredibly broad set of

features since being invented for hypermedia dissemination in

1990. Many of these features benefit users by enabling new types

of web applications. However, some features also bring risk to

users’ privacy and security, whether through implementation error,

unexpected composition, or unintended use. Currently there is

no general methodology for weighing these costs and benefits.

Restricting access to only the features which are necessary for

delivering desired functionality on a given website would allow

users to enforce the principle of lease privilege on use of the myriad

APIs present in the modern web browser.

However, security benefits gained by increasing restrictions must

be balanced against the risk of breaking existing websites. This

work addresses this problem with a methodology for weighing

the costs and benefits of giving websites default access to each

browser feature. We model the benefit as the number of websites

that require the feature for some user-visible benefit, and the cost

as the number of CVEs, lines of code, and academic attacks related

to the functionality. We then apply this methodology to 74 Web

API standards implemented in modern browsers. We find that al-

lowing websites default access to large parts of the Web API poses

significant security and privacy risks, with little corresponding

benefit.

We also introduce a configurable browser extension that allows

users to selectively restrict access to low-benefit, high-risk features

on a per site basis. We evaluated our extension with two hardened

browser configurations, and found that blocking 15 of the 74 stan-

dards avoids 52.0% of code paths related to previous CVEs, and

50.0% of implementation code identified by our metric, without

affecting the functionality of 94.7% of measured websites.

KEYWORDS

Network security, Software security, Web security and privacy

ACM Reference format:

Peter Snyder, Cynthia Taylor, and Chris Kanich. 2017. Most Websites Don’t

Need to Vibrate: A Cost–Benefit Approach to Improving Browser Secu-

rity. In Proceedings of ACM Conference, Washington, DC, USA, July 2017

(Conference’17), 16 pages.

https://doi.org/10.1145/nnnnnnn.nnnnnnn

1 INTRODUCTION

Since its beginnings as a hypermedia dissemination platform, the

web has evolved extensively and impressively, becoming part com-

munication medium and part software distribution platform. More

recently, the move from browser plugins to native HTML5 capa-

bilities, along with efforts like Chrome OS and the now defunct

Firefox OS, have expanded the Web API tremendously. Modern

browsers have, for example, gained the ability to detect changes

in ambient light levels [

], perform complex audio synthesis [

enforce digital rights management systems [

], cause vibrations

in enabled devices [36], and create peer to peer networks [11].

While the web has picked up new capabilities, the security model

underlying the Web API has remained largely unchanged. All web-

sites have access to nearly all browser capabilities. Unintended in-

formation leaks caused by these capabilities have been leveraged by

attackers in several ways: for instance, WebGL and Canvas allowed

Cao et al. to construct resilient cross-browser fingerprints [

], and

Gras et al. were able to defeat ASLR in the browser [

] using the

Web Workers and High Resolution Timing APIs.

One purported

benefit of deploying applications via JavaScript in the browser is

that the runtime is sandboxed, so that websites can execute any

code it likes, even if the user had never visited that site before. The

above attacks, and many more, have subverted that assumption to

great effect.

These attacks notwithstanding, allowing websites to quickly pro-

vide new experiences is a killer feature that enables rapid delivery

of innovative new applications. Even though some sites take ad-

vantage of these capabilities to deliver novel applications, a large

portion of the web still provides its primary value through rich me-

dia content dissemination. We show in this work that most websites

can deliver their beneficial functionality to users with only a limited

number of JavaScript APIs. Additionally, when websites need ac-

cess to less common functionality, we demonstrate a mechanism to

enable fine-grained access to JavaScript features on a case-by-case

basis.

An understanding of the benefits and risks of each JavaScript

feature is necessary to make sound decisions about which features

need to be enabled by default to create the modern web experience.

With this knowledge, a set of highly beneficial features can be

exposed by default to all websites, while only trusted sites that

need additional features are given the ability to access the full set

of capabilities in the browser, thus enforcing the principle of least

privilege on the Web API.

This work applies a systematic cost-benefit analysis to the por-

tions of the Web API implemented in all popular browsers. We

present a method to quantitatively evaluate both the

cost

of a fea-

ture (the added security risk of making a feature available) and

the

benefit

of a feature (the number of websites that require the

feature to function properly). We then build a browser extension

which blocks selected JavaScript functions to generate the results

discussed in this paper. In this work we specifically consider the

We present a more extensive overview of academic attacks and the JavaScript APIs

that enable them in Section 5.2.1, and further enumerate the attack to enabling feature

mapping in Table 4 in the Appendix.

arXiv:1708.08510v2 [cs.CR] 5 Sep 2017

open web accessed via a desktop browser, but the same approach

could be expanded to any website viewed via any browser.

Using these cost-benefit measurements, we create two hardened

browser configurations by identifying high-cost standards that

could be blocked in the browser without affecting the browsing

experience on most websites. We present a browser extension that

enforces these hardened browser configurations, and compare the

usability of these hardened browser configurations against other

popular browser-security tools, NoScript and the Tor Browser Bun-

dle (TBB). We find that our hardened browser configurations offer

substantial security benefits for users, while breaking fewer web-

sites than either NoScript or the default configuration of the TBB

during our evaluation on both the 200 most popular sites in the

Alexa 10k, and a random sampling of the rest of the Alexa 10k.

Our browser-hardening extension is highly configurable, allow-

ing functionality to be blocked or allowed on a per-site basis. The

set of standards blocked can be updated to reflect changes in the

popularity or security costs of each standard.

This work presents the following technical contributions:

•ES6 Proxy based feature firewall. (Section 3)

We lever-

age the ES6 proxy object to build a feature firewall which

dynamically disables JavaScript API features without break-

ing most code that expects those features to exist.

•Code complexity as cost. (Section 4.5.2)

We perform a

static analysis of the Firefox codebase to identify and count

lines of code exclusively used to enable each web standard.

We find a moderate, statistically significant relationship

between this code complexity metric and previously dis-

covered vulnerabilities attributed to these standards.

•Contextual protection extension. (Section 7)

We pack-

age the feature firewall in an open source browser exten-

sion that allows the deployment of pre-defined conserva-

tive and aggressive feature blocking policies. The extension

is highly customizable, with a user experience similar to

popular ad blocking software, including blocked API noti-

fications, streamlined reload and retry, and customizable

site whitelisting.

Further, these tools enable an analysis of the Firefox source code

with the intention of determining the costs and benefits of each

Web API standard, yielding the following additional contributions.

Understanding feature benefit (Section 5.1).

We define the

benefit of enabling a feature as the number of websites which

require the feature to function correctly, as perceived by the user in

a casual browsing scenario. We show that two humans using simple

rules to independently gauge the functionality of a website under

different levels of browser functionality can have high agreement

(97%), and thus can be used to model the benefit of a given feature.

We use this methodology to investigate the necessity of 74 different

features in 1,684 different paired tests undertaken across 500 hours

of human effort.

Understanding feature cost. (Section 5.2)

We define the cost

of enabling a feature as the number of vulnerabilities in the newly

exposed attack surface. Because this value is unknowable, we model

cost in three ways: first, we model security cost as a function of the

number of previously reported CVEs in a feature, on the intuition

that features which are difficult to code correctly are more likely to

have further undiscovered vulnerabilities.

Second, we model security cost as the number of attacks intro-

duced in academic papers which have been enabled by each Web

API standard.

Third, we model security cost as a function of code complex-

ity. We attribute entry points in the browser’s C++ codebase to

JavaScript exposed features, and then quantify complexity as the

number of lines of code used solely to implement access to each

feature.

2 RELATED WORK

In this section we discuss the current state of browser features, as

well as existing user level security defenses.

2.1 Browser Feature Inclusion

Browsers compete on performance, security, and compatibility. This

final point introduces two security related challenges: first, ven-

dors are very wary of removing features from the browser, even if

they are used by a very small fraction of all websites [

]. Second,

because the web is evolving and even competing with native appli-

cations (especially on mobile devices), browser vendors are incen-

tivized to continue to add new features to the web browser and not

remove old features. Browsers using the same code base across all

devices, including mobile, browser OS devices (e.g., Google Chrome-

books), and traditional PCs also increases the amount of code in

the browser. The addition of support for this variety of devices

means that JavaScript features that support hardware features (we-

bcams, rotation sensors, vibration motors, or ambient light sensors,

etc. [

]) are included in the browser for all devices, re-

gardless of whether they include such hardware. All of this has

resulted in a massive growth of the amount of code in the browser,

with Firefox currently containing over 13 million lines of code, and

Chrome containing over 14 million [18].

2.2 Client Side Browser Defenses

There are variety of techniques which “harden” the browser against

attacks via limiting what JavaScript is allowed to run within the

browser. These defenses can be split into two categories: those

configured by the user, and those configured by the website author.

Our method is in the former category, allowing the user to make

decisions about which features to enable when.

In the user configured category, both Adblock and NoScript pre-

vent JavaScript from running based on the site serving it. While

its primary function is to block ads for aesthetic purposes, Ad-

block [

] can also prevent infection by malware being served in

those ads [

]. Adblock blocks JavaScript features by prevent-

ing the loading of resources from certain domains, rather than

disabling specific functionality. NoScript [

] prevents JavaScript

on an all-or-nothing basis, decided based on its origin. Its default

for unknown origins is to allow nothing, rendering a large swath

of the web unusable. It is worth noting that NoScript defaults to

whitelisting a number of websites, which has resulted in a proof of

concept exploit via purchasing expired whitelisted domains [

Beyond these popular tools, IceShield [

] dynamically detects sus-

picious JavaScript calls within the browser, and modifies the DOM

to prevent attacks.

The Tor Browser [

] disables by default or prompts the user be-

fore using a number of features. Regarding JavaScript, they disable

SharedWorkers [

], and prompt before using calls from HTML5

Canvas, the GamePad API, WebGL, the Battery API, and the Sensor

API [

]. These particular features are disabled because they enable

techniques which violate the Tor Browser’s security and privacy

goals.

On the website author side, Content Security Policy allows lim-

iting of the functionality of a website, but rather than allowing

browser users to decide what will be run, CSP allows web devel-

opers to constrain code on their own sites so that potential attack

code cannot access functionality deemed unnecessary or danger-

ous [

]. Conscript is another client-side implementation which

allows a hosting page to specify policies for any third-party scripts

it includes [

]. There are also a number of technologies selected

by the website author but enforced on the client side, including

Google Caja [44] and GATEKEEPER [32].

There are existing models for enforcing policies to limit function-

ality outside of the web browser as well. Mobile applications use a

richer permission model where permission to use certain features

is asked of the user at either install or run-time [6, 17].

3 INTERCEPTING JAVASCRIPT

FUNCTIONALITY

Core to both our measurements and the browser hardening exten-

sion is the ability to disable specific features from the browser’s

JavaScript environment. Here we present a technique for removing

access to these features while minimizing collateral damage in code

that expects those features to be available.

3.1 Web API / W3C standards

When visiting and displaying websites, browsers build a tree-based

model of the document. This tree, along with the methods and

properties the browser provides to allow site authors to interact

with the browser and the tree, are collectively known as the DOM

(document object model), or the Web API.

The browser makes much of its functionality available to web-

sites through a single, global object, called

window

. Almost all

JavaScript accessible browser functionality is implemented as a

property or method on this global object. The set of properties,

functions, and methods available in the DOM is standardized us-

ing Interface Description Language documents. Browser vendors

implement these standards in their browsers.

For the purposes of this paper, we define a

feature

as an in-

dividual JavaScript method or property available in the browser,

and a

Web API standard

(or just

standard

) as a collection of fea-

tures collected into a single document and published together. Each

standard generally contains features that are intended to be used to-

gether to enable a common functionality (such as WebGL graphics

manipulation, geolocation services, or cryptographic services).

3.2 Removing Features from the DOM

Each webpage and iframe gets its own global window object. Changes

made to the global object are shared across all scripts on the same

page, but not between pages. Furthermore, changes made to this

global object are seen immediately by all other script running in the

page. If one script deletes or overwrites the

window.alert

function,

for example, no other scripts on the page will be able to use the

alert function, and there is no way they can recover it.

As a result, code executed earlier can arbitrarily modify the

browser environment seen by code executed later. Since code run

by browser extensions can run before any scripts included by the

page, extensions can modify the browser environment for all code

executed in any page. The challenge in removing a feature from the

browser environment is not to just prevent pages from reaching

the feature, but to do so in way that still allows the rest of the code

on the page to execute without introducing errors.

For example, to disable the

getElementsByTagName

feature, one

could simply remove the

getElementsByTagName

method from the

window.document

object. However, this will result in fatal errors

if future code attempts to call that now-removed method.

Consider the code in Figure 1: removing the

window.document

.getElementsByTagName

method will cause an error on line one,

as the site would be trying to call the now-missing property as

if were a function. Replacing

getElementsByTagName

with a new,

empty function would solve the problem on line one, but would

cause an error on line two, unless the function returned an array

of at least length five. Even after accounting for that result, one

would need to expect that the

setAttribute

method was defined

on the fourth element in that array. One could further imagine that

other code on the page may be predicated on other properties of

that return value, and fail when those are not true.

1var ps , p5 ;

2ps = doc u me nt . g e tE l em e nt s By T ag N am e ( "p");

3p5 = ps [4 ];

4p5 . s e t A tt r i b ut e ( " s ty l e " ," co l or : re d " ) ;

5al e rt ( " S uc ce s s ! ") ;

Figure 1: Trivial JavaScript code example, changing the color

of the text in a paragraph.

3.3 ES6 Proxy Configuration

Our technique solves this problem through a specially constructed

version of the

Proxy

object. The

Proxy

object can intercept opera-

tions and optionally pass them along to another object. Relevant to

this work, proxy objects also allow code to trap on general language-

operations. Proxies can register generic handlers that fire when the

proxy is called like a function, indexed into like an array, has its

properties accessed like an object, and operated on in other ways.

We take advantage of the

Proxy

object’s versatility in two ways.

First, we use it to prevent websites from accessing certain browser

features, without breaking existing code. This use case is described

in detail in Subsection 3.4. And second, we use the

Proxy

object

to enforce policies on runtime created objects. This use case is

described in further detail in Subsection 3.5

3.4 Proxy-Based Approach

We first use the

Proxy

object to solve the problems described in

3.2. We create a specially configured a proxy object that registers

callback functions for all possible JavaScript operations, and having

those callback functions return a reference to the same proxy object.

We also handle cases where Web API properties and functions

return scalar values (instead of functions, arrays or higher order

objects), by programming the proxy to evaluate to

, empty string,

undefined

, depending on the context. Thus configured, the

proxy object can validly take on the semantics of any variable in

any JavaScript program.

By replacing

getElementsByTagName

with our proxy, the code

in Figure 1 will execute cleanly and the alert dialog on line four

will successfully appear. On line one, the proxy object’s function

handler will execute, resulting in the proxy being stored in the

variable. On line two, the proxy’s

get

handler will execute, which

also returns the proxy, resulting in the proxy again being stored in

. Calling the

setAttribute

method causes the proxy object to

be called twice, first because of looking up the

setAttribute

, and

then because of the result of that look up being called as a function.

The end result is that the code executes correctly, but without

accessing any browser functionality beyond the core JavaScript

language.

The complete proxy-based approach to graceful degradation can

be found in the source code of our browser extension2.

Most state changing features in the browser are implemented

through methods which we block or record using the above de-

scribed method. This approach does not work for the small number

of features implemented through property sets. For example, assign-

ing a string to

document.location

redirects the browser to the

URL represented by the string. When the property is being set on a

singleton object in the browser, as is the case with the

document

ob-

ject, we interpose on property sets by assigning a new “set” function

for the property on the singleton using Object.defineProperty.

3.5 Sets on Non-Singleton Objects

A different approach is needed for property sets on non-singleton

objects. Property sets cannot be imposed on through altering an

object’s

Prototype

, and non-singleton objects can not be modified

with

Object.defineProperty

at instrumentation time (since those

objects do not yet exist). We instead interpose on methods that yield

non-singleton objects.

We modify these methods to return

Proxy

objects that wrap

these non-singleton objects, which we use to control access to set

these properties at run time. For example, consider the below code

example, using the Web Audio API.

1var co n t ex t = new w i n do w . A u d i oC o n t ex t () ;

2var ga i n No d e = con t e xt . c re a t e Ga i n ( ) ;

3ga i nN o de . c h an n el C ou n t = 1;

Figure 2: Example of setting a property on a non-singleton

object in the Web API.

2URL Redacted for review.

In this example, we are not able to interpose on the

gainNode.

channelCount

set, as the

gainNode

object does not exist when

we modify the

DOM

. To address these cases, we further modify the

AudioContext.property.createGain

to return a specially cre-

ated proxy object, instead of a

GainNode

object. This, specially

crafted proxy object wraps the

GainNode

object, allowing us to in-

terpose on property sets. Depending on the current policy, we either

ignore the property set or pass it along to the original

GainNode

object.

3.6 Security Implications

There are some code patterns where the proxy approach described

here could have a negative impact on security, such as when se-

curity sensitive computations are done in the client, relying on

functionality provided by the Web API, and where the results of

those calculations are critical inputs to other security sensitive op-

erations. We expect that such cases are rare, given common web

application design practices. Even so, in the interest of safety, we

whitelist the WebCrypto API by default, and discuss the security

and privacy tradeoffs here.

As discussed above, our proxy-based approach for interposing

on Web API features replaces references to the functionality being

blocked with a new function that returns the proxy object. In most

cases where the feature being replaced is security relevant, this

should not negativly effect the security of the system. For example,

if the

encrypt

method from the Web Crypto were replaced with our

proxy object, the function would not return an unencrypted string,

but instead the proxy object. While this would break a system that

expected the cryptographic operation to be successful, it would

“fail-closed”; sensitive information would

not

be returned where

encrypted information was expected.

Conversely, if

getRandomValues

is used to generate a nonce, the

returned proxy object would coerce to an empty string. While the

security repercussions of this silent failure could possibly be grave,

[

] observed that the vast majority of calls to

getRandomValues

on the open web could be considered privacy-invasive, as they

were used as part of the Google Analytics tracking library. Even

so, the potential harm to users from a silent failure is too great,

resulting in our decision to whitelist WebCrypto. As our proposed

contextual protection extension can implement arbitrary policies,

we look forward to debate among experts and users as to what a

sensible set of defaults should be in this situation.

4 METHODOLOGY

In this section we describe a general methodology for measuring the

costs and benefits of enabling a Web API standard in the browser.

We measure the benefit of each standard using the described feature

degradation technique for each standard of features, browsing sites

that use those feature, and observing the result. We measure the cost

of enabling each standard in three ways: as a function of the prior

research identifying security or privacy issues with the standard,

the number and severity of associated historical CVEs, and the LoC

needed to implement that standard.

4.1 Representative Browser Selection

This section describes a general methodology for evaluating the

costs and benefits of enabling Web API standards in web browsers,

and then the application of that general approach to a specific

browser,

Firefox 43.0.1

. We selected this browser to represent

modern web browsers general for several reasons.

First

, Firefox’s implementation of Web API standards is represen-

tative of how Web API standards are implemented in other popular

web browsers, such as Chrome. These browsers use WebIDL to

define the supported Web API interfaces, and implement the un-

derlying functionality mostly in C++, with some newer standards

implemented in JavaScript. These browsers even share a signifi-

cant amount of code, through their use of third party libraries and

code explicitly copied from each other’s projects (for example, very

large portions of Mozilla’s WebRTC implementation is taken or

shared with the Chromium project in the form of the “webrtc” and

“libjingle” libraries).

Second

, the standardized nature of the Web API means that mea-

sures of Web API costs and benefits performed against one browser

will roughly generalize to all modern browsers; features that are

frequently used in one browser will be as popular when using any

other recent browser. Similarly, most of the attacks documented in

academic literature exploit functionality that is operating as speci-

fied in these cross-browser standards, making it further likely that

this category of security issue will generalize to all browsers.

Third

, we use Firefox, instead of other popular browsers, to build

on other related research conducted on Firefox (e.x. [

] and [

]).

Such research does not exist for other popular browsers, making

Firefox a natural choice as a research focus.

For these reasons, we use Firefox 43.0.1 as representative of

browsers in general in this work. However, this approach would

work with any modern browser, and is in no way tied to Firefox

43.0.1 in particular.

4.2 Measuring by Standard

To measure the costs and benefits of Web API features in the

browser, we identified a large, representative set browser features

implemented across all modern web browsers. We extracted the

1,392 standardized Web API features implemented in Firefox, and

categorized those features into 74 Web API standards, using the

same technique as in [54].

Using the features listed in the W3C’s (and related standards orga-

nizations) publications, we categorized

Console.prototype.log

and Console.prototype.timeline with the Console API,

SVGFilterElement.apply

and

SVGNumberList.prototype.getItem

with the SVG standard, and so forth, for each of the 1,392 features.

We use these 74 standards as our unit of Web API measurement

for two reasons. First, focusing on 74 standards leads to less of a

combinatorial explosion when testing different subsets of Web API

functionality. Secondly, as standards are organized around high

level features of the browser that often have one cohesive purpose,

for instance the Scalable Vector Graphics standard or the Web Audio

API, being able to reason about what features a website might need

is useful for communicating with users who might be interested

in blocking (or allowing) such features to run as part of a given

website.

4.3 Determining When A Website Needs A

Feature

Core to our benefit metric is determining whether a given website

needs a browser feature to function. When a site does not need a

feature, enabling the feature on the site provides little benefit to

browser users.

Importantly, we focus our measurements on an unauthenticated

casual browsing scenario. This approach will not capture features

like rich user to user messaging or video chat. We believe this casual

browsing scenario properly approximates the situation in which a

heightened security posture is most needed: when a user first visits

a new site, and thus does not have any trust relationship with the

site, and likely little or no understanding of the site’s reputation for

good security or privacy practices. Once a user has a better idea of

how much to trust the site and what features the site requires, they

may adaptively grant specific permissions to the site.

Determining whether a website actually needs a feature to func-

tion is difficult. On one end of the spectrum, when a website never

uses a feature, the site trivially does not need to feature to run cor-

rectly. Previous work [

] shows that most features in the browser

fall in this category, and are rarely used on the open web.

However, a website may use a feature, but not need it to carry

out the site’s core functionality. With the feature removed, the

website will still function correctly and be fully usable. For example,

a blog may wish to use the Canvas standard to invisibly fingerprint

the visitor. But if a visitor’s browser does not support the Canvas

standard, the visitor will still be able to interact with the blog as

if the standard was enabled (though the invisible fingerprinting

attempt will fail).

This measure of feature “need” is intentionally focused on the

the perspective of the browser user. The usefulness of a feature to

a website author is not considered beyond the ability of the site

author to deliver a user-experience to the browser user. If a site’s

functionality is altered (e.g. tracking code is broken, or the ability

to A/B test is hampered) in a way the user cannot perceive, then

we consider this feature as not being needed from the perspective

of the browser user, and thus not needed for the site.

With this insight in mind, we developed a methodology for

evaluating the functionality of a given website. We instructed two

undergraduate workers to visit the same website, twice in a row. The

first visit is used as a control, and was conducted in an unmodified

Firefox browser. The worker was instructed to perform as many

different actions on the page as possible within one minute. (This is

in keeping with the average dwell time a user spends on a website,

which is slightly under a minute [

].) On a news site this would

mean skimming articles or watching videos, on e-commerce sites

searching for products, adding them to the cart and beginning the

checkout process, on sites advertising products reading or watching

informational material and trying any live demos available, etc.

The second visit is used to measure the effect of a specific treat-

ment on the browsing experience. The worker visits the same page

a second time, with all of the features in a Web API standard dis-

abled. For another minute, the worker attempts to perform the same

actions they did during the first visit. They then assign a score to

the functionality of the site:

if there was no perceptible difference

between the control and treatment conditions,

if the browsing

experience was altered, but the worker was still able to complete

the same tasks as during the first visit, or

if the worker was not

able to complete the same tasks as during the control visit.

We then defined a site as broken if the user cannot accomplish

their intended task (i.e., the visit was coded as a 3). This approach

is inherently subjective. To account for this, we had both workers

browse the same site independently, and record their score without

knowledge of the other’s experience. Our workers averaged a 96.74%

agreement ratio. This high agreement supports the hypothesis that

the workers were able to successfully gauge whether particular

functionality was necessary to the goals of a user performing casual

web browsing.

4.4 Determining Per-Standard Benefit

We determined the benefit of each of the 74 measured standards in

four steps.

First, we select a set of websites to represent the internet as a

whole. This work considers the top 10,000 most popular websites

on the Alexa rankings as representative of the web in general, as

of July 1, 2015, when this work began.

Second, for each standard, we randomly sampled 40 sites from

the Alexa 10k that use the standard, as identified by [

]. Where

there were less than 40 sites using the standard, we selected all

such sites. That work found that while there is some difference in

the Web API standards that popular and unpopular websites use,

these differences are small [

]. We therefor treat these randomly

sampled 40 as representative of all sites using the standard.

Third, we used the technique described in Section 3 to create

multiple browser configurations, each with one standard disabled.

This yielded 75 different browser configurations (one configura-

tion with each standard disabled, and one “control” case with all

standards enabled).

Fourth, we performed the manual testing described in Section 4.3.

We carried out the above process twice for each of the 1679 sites

tested for this purpose. By carrying out the above process for all 74

standards, we were able to measure the

site break rate

for each

Web API standard, defined as the percentage of times we observed

a site break during our paired tests with the featured disabled,

multiplied by how frequently the standard is used in the Alexa 10k.

We then define the benefit of a standard as a function of its site

break rate; the more sites break when a standard is disabled, the

more useful the standard is to a browser user. The results of this

measurement are discussed in Section 5.

4.5 Determining Per-Standard Cost

We measure the security cost of enabling a Web API standard in

three ways.

First, we measure the cost of enabling a Web API standard in a

browser as a function of CVEs that have been reported against the

standard’s implementation in the browser in the past. We take past

CVEs as an indicator of present risk for three reasons. First, areas of

code that have multiple past CVEs suggest that there is something

about the problem domain addressed by this code that is difficult to

code securely, suggesting that these code areas deserve heightened

scrutiny (and carry additional risk). Second, prior research [

]

suggest that bugs fixes often introduce nearly as many bugs as they

address, suggesting that code that has been previously patched for

CVEs carries heightened risk for future CVEs. Third, recent notable

industry practices suggest that project maintainers sometimes be-

lieve that code that has had multiple security vulnerabilities should

be treated greater caution (and that shedding the risky code is safer

than continually patching it) [29].

Second, we measure the cost of including a Web API standard

by the amount of related academic work documenting security and

privacy issues in a standard. We searched for attacks leveraging

each Web API standard in security conferences and journals over

the last five years.

Third, we measure the cost of including a Web API standard by

the number of lines of code needed solely to implement the standard

in the browser, as code complexity (measured through number

of lines of code in function definitions) has been shown to have

moderate predictive power for discovering where vulnerabilities

will happen within the Firefox codebase [53].

4.5.1 CVEs. We determined the number of CVEs previously

associated with each Web API standard through the following steps:

First, we searched the MITRE CVE database for all references

to Firefox in CVEs issued in 2010 or later, resulting in 1,554 CVE

records.

We then reviewed each CVE and discarded 41 CVEs that were

predominantly about other pieces of software, where the browser

was only incidentally related (such as the Adobe Flash Player plu-

gin [

], or vulnerabilities in web sites that are exploitable through

Firefox [4]).

Next, we examined each of the remaining CVEs to determine if

they documented vulnerabilities in the implementation of one of

the 74 considered Web API standards, or in some other part of the

browser, such as the layout engine, the JavaScript runtime, or net-

working libraries. We identified 175 CVEs describing vulnerabilities

in Firefox’s implementation of 39 standards. 13 CVEs documented

vulnerabilities affecting multiple standards.

We identified which Web API standard a CVE related to by

reading the text description of each CVE. We were able to attribute

CVEs to individual standards in the following ways:

•117 (66.9%) CVEs explicitly named a Web API standard.

•

32 (18.3%) CVEs named a JavaScript method, structure or

interface) that we tied to a larger standard.

•

21 (12%) CVEs named a C++ class or method that we tie

to the implementation of Web API standard, using the

methodology described in 4.5.2.

•

5 (2.8%) CVEs named browser functionality defined by a

Web API standard (e.x. several CVEs described vulnerabili-

ties in Firefox’s handling of drag-and-drop events, which

are covered by the HTML standard [61]).

When associating CVEs with Web API standards, we were careful

to distinguish between CVEs associated with DOM-level function-

ality and those associated with more core functionality. This was

done to narrowly measure the cost of only the DOM implementa-

tion of the standard. For example, the SVG Web API standard [

]

allows site authors to use JavaScript to dynamically manipulate

SVG documents embedded in websites. We counted CVEs like

interface BatteryManager {

readonly charging;

readonly chargingTime;

readonly dischargingTime;

};

mozilla::dom::BatteryManagerBinding::

charging

mozilla::dom::BatteryManagerBinding::

chargingTime

mozilla::dom::BatteryManagerBinding::

dischargingTime

mozilla::dom::BatteryManager::

Charging

mozilla::dom::BatteryManager::

ChargingTime

mozilla::dom::BatteryManager::

DischargingTime

Standardized interface

description

Automatically generated

binding functions

Functions used exclusively

for implementing the Battery API

Figure 3: An example of applying the graph pruning algorithm to a simplified version of the Battery API.

CVE-2011-2363

[

], a “Use-after-free vulnerability” in Firefox’s

implementation of JavaScript DOM API for manipulating SVG doc-

uments, as part of the cost of including the SVG Web API standard

in Firefox. We did not consider CVEs relating to other aspects of

SVGs handing in our Web API standard costs.

CVE-2015-0818

[

a privilege escalation bug in Firefox’s SVG handling, is an example

of a CVE we did not associate with the SVG Web API standard, as

it was not part of the DOM.

4.5.2 Implementation Complexity. We use the browser source

to generate lower-bound approximations for how complex each

standards’ implementation, as significant lines of C/C++ code. We

consider standards with more complex implementations as having

a greater cost to the security of the browser than those with simpler

implementations.

We consider only lines of C/C++ code used only to support

JavaScript based access to that specific feature. We henceforth refer

to this metric as Exclusive Lines of Code, or

ELoC

. We compute

the ELoC for each Web API standard in three steps.

We generated a call graph of Firefox using Mozilla’s DXR tool [

DXR uses a clang compiler plugin to produce an annotated version

of the source code through a web app.

We use this call graph to

determine which functions call which other functions, where func-

tions are referenced, etc. We further modified DXR to record the

number of lines of code for each function.

Next, we determined each standards’ unique entry points in

the call graph. Each property, method or interface defined by a

Web API standard has two categories of underlying code in Fire-

fox code. There is

implementation code

(hand written code that

implements Web API standard’s functionality), and

binding code

(programmatically generated C++ code only called by the JavaScript

runtime). Binding code is generated at build time from WebIDL

documents, an interface description language that defines each Web

API standard’s JavaScript API endpoints. By mapping each feature

in each Web IDL document to a Web API standard, we are able to

associate each binding code function with a Web API standard.

An example of the DXR interface is available at https://dxr.mozilla.org/

mozilla-central/source/.

Given the entry points in the call graph for each Web API feature,

we used a recursive graph algorithm to identify implementation

code associated with each standard. We illustrate an example of this

approach in Figure 3. In step 1, we programmatically extract the

standard’s definitions for its binding functions, as we do here using

a simplified version of the Battery API. In step 2, we locate these

generated binding functions in the Firefox call graph (denoted by

blue nodes). By following the call graph, we identify implementa-

tion functions that are called by the Battery API’s binding functions,

denoted by pink nodes. (step 3). If these pink nodes have no incom-

ing edges other than binding functions, we know they are solely

in the code base because of the Web API standard associated with

those binding functions.

The first iteration of the algorithm identifies two functions,

Charging

and

DischargingTime

, as being solely related to the Bat-

tery API standard, since no other code within the Firefox codebase

contains a reference or call to those functions. The second iteration

of the pruning process identifies the

ChargingTime

function as

also guaranteed to be solely related to the Battery API standard’s

implementation, since it is only called by functions we know to

be solely part of the Battery API ’s implementation. Thus, the lines

implementing all three of these pink implementing functions are

used to compute the ELoC metric for the Battery API.

4.5.3 Third Party Libraries. This technique gives a highly accu-

rate, lower bound measurement of lines of code in the Firefox source

included only to implement a single Web API standard. It does not

include code from third-party libraries, which are compiled as a

separate step in the Firefox build process, and thus excluded from

DXR’s call-graph.

To better understand their use, we investigated how third party

libraries are used in the Firefox build process. In nearly all cases,

the referenced third party libraries are used in multiples places

in the Firefox codebase and cannot be uniquely attributed to any

single standard, and thus are not relevant to our per-standard ELoC

counts.

The sole exception is the WebRTC standard, which uniquely uses

over 500k lines of third party code. While this undercount is large,

0% 25% 50% 75%

Sites Broken Without this Feature

Number of Standards

Figure 4: A histogram giving the number of standards

binned by the percentage of sites that broke when removing

the standard.

it is ultimately not significant to our goal of identifying high-cost,

low-benefit standards, as the high number of vulnerabilities in the

standard (as found in CVEs) and comparatively high ELoC metric

already flag the standard as being high-cost.

5 MEASURED COST AND BENEFIT

This section presents the results of applying the methodology dis-

cussed in Section 4 to Firefox 43.0.1. The section first describes

the benefit of each Web API standard, and follows with the cost

measurements.

5.1 Per-Standard Benefit

As explained in Section 4.4, our workers conducted up to 40 mea-

surements of websites in the Alexa 10k known to use each specific

Web API standard. If a standard was observed being used fewer

than 40 times within the Alexa 10k, all sites using that standard

were measured. In total, we did two measurements of 1,684 (website,

disabled feature) tuples, one by each worker.

Figure 4 gives a histogram of the break rates for each of the 74

standards measured in this work. As the graph shows, removing

over 60% of the measured standards resulted in no noticeable effect

on the user’s experience.

In some cases, this was because the standard was never observed

being used

. In other cases, it was because the standard is intended

to be used in a way that users do not notice5.

Other standards caused a large number of sites to break when

removed from the browser. Disabling access to the DOM 1 standard

(which provides basic functionality for modifying the text and

appearance of a document) broke an estimated 69.05% of the web.

A listing of the site break rate for all 74 standards is provided in

the appendix in Table 4.

e.x. the WebVT T standard, which allows document authors to synchronize text

changes with media playing on the page.

e.x. the Beacon standard, which allows content authors to trigger code execution

when a user browses away from a website.

We note that these measurements only cover the interacting

with a website as an unauthenticated user. It is possible that site

feature use changes when users log into websites, since some sites

only provide full functionality to registered users. These numbers

only describe the functionality sites use before they’ve established

a trust-relationship with the site (e.g. before they’ve created an

account and logged into a web site).

5.2 Per-Standard Cost

As described in Section 4.5, we measure the cost of a Web API stan-

dard being available in the browser in three ways: first by related

research documenting security and privacy attacks that leverage

the standard (Section 5.2.1), second by the number of historical

CVEs reported against the standard since 2010 (Section 4.5.1), and

third with a lower bound estimate of the number of ELoC needed

to implement the standard in the browser (Section 4.5.2).

5.2.1 Security Costs - Attacks from Related Research. We searched

the last five years of work published at major research conferences

and journals for research on browser weaknesses related to Web

API standards. These papers either explicitly identify either Web

API standards, or features or functionality that belong to a Web

API standard. In each case the standard was either necessary for

the attack to succeed, or was used to make the attack faster or

more reliable. While academic attacks do not aim to discover all

possible vulnerabilities, the academic emphasis on novelty mean

that the Web API standards implicated in these attacks allow a new,

previously undiscovered way to exploit the browser.

The most frequently cited standard was the High Resolution Time

Level 2 [

] standard, which provides highly accurate, millisecond-

resolution timers. Seven papers published since 2013 leverage the

standard to break the isolation protections provided by the browser,

such as learning information about the environment the browser

is running in [

], learning information about other open

browser windows [

], and gaining identifying information

from other domains [59].

Other implicated standards include the Canvas standard, which

was identified by researchers as allowing attackers to persistently

track users across websites [

], learn about the browser’s execu-

tion environment [

] or obtain information from other browsing

windows [

], and the Media Capture and Streams standard, which

was used by researchers to perform “cross-site request forgery,

history sniffing, and information stealing” attacks [57].

In total we identified 20 papers leveraging 23 standards to attack

the privacy and security protections of the web browser. Citations

for these papers are included in Table 4.

5.2.2 Security Costs - CVEs. Vulnerability reports are not evenly

distributed across browser standards. Figure 5 presents this com-

parison of standard benefit (measured by the number of sites that

require the standard to function) on the y-axis, and the number

of severe CVEs historically associated with the standard on the x-

axis. A plot of all CVEs (not just high and severe ones), is included

in the appendix as Figure 7. It shows the same general relation-

ships between break rate and CVEs as Figure 5, and is included for

completeness.

AJAX

DOM

DOM1

DOM2−C

DOM2−E

DOM2−S H−C

H−WW

HTML

SVG

WEBA WEBGL

WRTC

25%

50%

75%

100%

0 10 20 30

Attributed High or Severe CVEs Since 2010

Sites Broken Without this Feature

Figure 5: A scatter plot showing the number of “high” or “se-

vere” CVEs filed against each standard since 2010, by how

many sites in the Alexa 10k break when the standard is re-

moved.

Points in the upper-left of the graph depict standards that are

high benefit, low cost, i.e. standards that are frequently required

on the web but have rarely (or never) been implicated in CVEs.

For example, consider the Document Object Model (DOM) Level 2

Events Specification standard, denoted by

DOM2-E

in Figure 5. This

standard defines how website authors can associate functionality

with page events such as button clicks and mouse movement. This

standard is highly beneficial to browser users, being required by

34% of pages to function correctly. Enabling the standard comes

with little risk to web users, being associated with zero CVEs since

2010.

Standards in the lower-right section of the graph, by contrast, are

low benefit, high cost standards, when using historical CVE counts

as an estimate of security cost. The WebGL Specification standard,

denoted by

WEBGL

in Figure 5, is an example of such a low-benefit,

high-cost standard. The standard allows websites to take advantage

of graphics hardware on the browsing device for 3D graphics and

other advanced image generation. The standard is needed for less

than 1% of web sites in the Alexa 10k to function correctly, but is

implicated in 22 high or severe CVEs since 2010. How infrequently

this standard is needed on the web, compared with how often the

standard has previously been the cause of security vulnerabilities,

suggests that the standard poses a high security risk to users going

forward, with little attenuating benefit.

As Figures 7 and 5 show, some standards have historically put

users at much greater risk than others. Given that for many of

these standards the risk has come with little benefit to users, these

standards are good candidates for disabling when visiting untrusted

websites.

5.2.3 Security Costs - Implementation Complexity. We further

found that the cost of implementing standards in the browser are

not equal, and that some standards have far more complex imple-

mentations than others (with complexity measured as the ELoC

uniquely needed to implement a given standard). Figure 6 presents

a comparison of standard benefit (again measured by the number

AJAX

DOM

DOM1

DOM2−C

DOM2−E

DOM2−S

H−C

HTML

HTML5

IDB SVG

WEBA

WEBGL

25%

50%

75%

100%

0 5000 10000 15000 20000

Exclusively Used Lines of Code

Sites Broken Without this Feature

Figure 6: A scatter plot showing the LOC measured to im-

plement each standard, by how many sites in the Alexa 10k

break when the standard is removed.

of sites that require the standard to function) and the exclusive

lines of code needed to implement the standard, using the method

described in section 4.5.2.

Points in the upper-left of Figure 6 depict standards that are fre-

quently needed on the web for sites for function correctly, but which

have relatively non-complex implementations. One example of such

a standard is the Document Object Model (DOM) Level 2 Core Speci-

fication standard, denoted by

DOM2-C

. This standard provides ex-

tensions the browser’s basic document modification methods, most

popularly, the

Document.prototype.createDocumentFragment

method, which allows websites to quickly create and append sub-

documents to the current website. This method is needed for 89% of

websites to function correctly, suggesting it is highly beneficial to

web users to have it enabled in their browser. The standard comes

with a low security cost to users as well; our technique identifies

only 225 exclusive lines of code that are in the codebase solely to

enable this standard.

Points in the lower-right of the figure depict standards that pro-

vide infrequent benefit to browser users, but which are responsible

for a great deal of complexity in the browser’s code base. The Scal-

able Vector Graphics (SVG) 1.1 (Second Edition) standard, denoted by

SVG

, is an example of such a high-cost, low-benefit standard. The

standards allows website authors to dynamically create and interact

with embedded SVG documents through JavaScript. The standard

is required for core functionality in approximately 0% of websites

on the Alexa 10k, while adding a large amount of complexity to

the browser’s code base (at least 5,949 exclusive lines of code, more

than our technique identified for any other standard).

5.3 Threats to Validity

The main threat to validity in this experiment is the accuracy of our

human-executed casual browsing scenario. With respect to internal

validity, the high agreement between the two users performing

tasks on the same sites lends credence to the claim that the users

were able to successfully exercise most or all of the functionality

that a casual browser might encounter. The students who worked

on this project spent over 500 hours combined performing these

casual browsing tasks and recording their results, and while they

were completely separated while actively browsing, they spent a

good deal of time comparing notes about how to fully exercise the

functionality of a website within the 70 second time window for

each site.

External validity, i.e. the extent to which our results can be

generalized, is also a concern. However, visiting a website for 70

or fewer seconds encapsulates 80% of all web page visits according

to [

], thus accurately representing a majority of web browsing

activity, especially when visiting untrusted websites. Furthermore,

while our experiment does not evaluate the JavaScript functionality

that is only available to authenticated users, we posit that protection

against unknown sites—the content aggregators, pop-up ads, or

occasionally consulted websites that a user does not interact with

enough to trust—are precisely the sites with which the user should

exercise the most caution.

6 USABILITY EVALUATION

This section describes how we evaluated the usability of our feature-

restricting approach, to determine whether the security benefits

discussed in Section 5 could be achieved without negatively effect-

ing common browsing experiences across a broad range of websites.

We performed this evaluation in two steps. First, we selected two

sets of Web API standards to prevent websites from accessing by

default, each representing a different trade off between affecting

the functionality of existing sites and improving browser security.

Second, we implemented these hardened browser configurations

using the browser extension mentioned in Section 7, and compared

their usability against other popular browser hardening techniques.

6.1 Selecting Configurations

To evaluate the utility and usability of our fine grained, standards-

focused approach to browser hardening, we created two hardened

browser configurations.

Table 3 lists the standards that we blocked for the conservative

and aggressive hardened browser configurations. Our

conserva-

tive

configuration focuses on removing features that are infre-

quently needed by websites to function, and would be fitting for

users who desire more security than is typical of a commodity web

browser, and are tolerant of a slight loss of functionality. Our

ag-

gressive

configuration focuses on removing attack surface from

the browser, even when that necessitates breaking more websites.

This configuration would fit highly security sensitive environments,

where users are willing to accept breaking a higher percentage of

websites in order to gain further security

We selected these profiles based on the data discussed in Section

5, related previous work on how often standards are needed by

websites [

], and prioritizing not affecting the functionality of the

most popular sites on the web. We further chose to not restrict the

Web Crypto standard, to avoid affecting the critical path of security

senstivie code.

We note that these are just two possible configurations, and that

users (or trusted curators, IT administrators, or other sources) could

use this method to find the security / usability tradeoff that best fit

their needs.

Statistic Conservative Aggressive

Standards blocked 15 45

Previous CVEs # 89 123

Previous CVEs % 52.0% 71.9%

LOC Removed # 37,848 53,518

LOC Removed % 50.00% 70.76%

% Popular sites broken 7.14% 15.71%

% Less popular sites broken 3.87% 11.61%

Table 1: Cost and benefit statistics for the evaluated conser-

vative and aggressive browser configurations.

We evaluated the usability and the security gains these hardened

browser configurations provided. Table 1 shows the results of this

evaluation. As expected, blocking more standards resulted in a

more secure browser, but at some cost to usability (measured by

the number of broken sites).

Our evolution was carried out similarly to the per-standard mea-

surement technique described in Section 4.4. First we created two

sets of test sites,

popular

sites (the 200 most popular sites in the

Alexa 10k that are in English and not pornographic) and

less pop-

ular sites

(a random sampling of sites from the Alexa 10k that

are rank 201 or lower). This yielded 175 test sites in the popular

category, and 155 in the less popular category.

Next we had two evaluators visit each of these 330 websites

under three browsing configurations, for 60 seconds each. Our

decision to use 60 seconds per page is based on prior research [

]

finding that that users on average spend under a minute per page.

Our evaluators first visited each site in an unmodified Firefox

browser, to determine the author-intended functionality of the

website. Second, they visited in a Firefox browser in the above

mentioned conservative configuration. And then finally, a third

time in the aggressive hardened configuration.

For the conservative and aggressive tests, the evaluators recorded

how the modified browser configurations affected each page, using

the same 1–3 scale described in Section 4.4. Our evaluators inde-

pendently gave each site the same 1–3 ranking 97.6% of the time

for popular sites, and 98.3% of the time for less popular sites, giving

us a high degree of confidence in their evaluations. The “% Popular

sites broken” and “% Less popular sites broken” rows in Table 1

give the results of this measurement.

To further increase our confidence the reported site-break rates,

our evaluators recorded, in text, what broken functionality they

encountered. We were then able to randomly sample and check

these textual descriptions, and ensure that our evaluators were

experiencing similar broken functionality. The consistency we ob-

served through this sampling supports the internal validity of the

reported site break rates.

As Table 1 shows, the trade off between gained security and

lessened usability is non-linear. The conservative configuration

disables code paths associated with 52% of previous CVEs, and

removes 50% of ELoC, while affecting the functionally of only 3.87%-

7.14% of sites on the internet. Similarly, the aggressive configuration

disables 71.9% of code paths associated with previous CVEs and

% Popular % Less popular Sites tested

sites broken sites broken

Conservative Profile 7.14% 3.87% 330

Aggressive Profile 15.71% 11.61% 330

Tor Browser Bundle 16.28% 7.50% 100

NoScript 40.86% 43.87% 330

Table 2: How many popular and less popular sites break

when using conservative and aggressive hardening profiles,

versus other popular browser security tools.

over 70% of ELoC, while affecting the usability of 11.61%-15.71% of

the web.

6.2 Usability Comparison

We compared the usability of our sample browser configurations

against other popular browser security tools. We compared our

conservative and aggressive configurations first with Tor Browser

and NoScript, each discussed in Section 2.2. We find that the con-

servative configuration has the highest usability of all four tested

tools, and that the aggressive hardened configuration is roughly

comparable to the default configuration of the Tor Browser. The

results of this comparison are given in Table 2.

We note that this comparison is not included to imply which

method is the most secure. The types of security problems addressed

by each of these approaches are largely intended to solve different

types of problems, and all three compose well (i.e., one could use

a cost-benefit method to determine which Web API standards to

enable and harden the build environment and route traffic through

the Tor network and apply per-origin rules to script execution).

However, as Tor Browser and NoScript are widely used security

tools, comparing against them gives a good baseline for usability

for security conscious users.

We tested the usability using the same technique we used for the

conservative and aggressive browser configurations, described in

Section 6.1; the same two evaluators visited the same 175 popular

and 155 less popular sites, but compared the page in an unmodified

Firefox browser with the default configuration of the NoScript

extension.

The same comparison was carried out for default Firefox against

the default configuration of the Tor Browser bundle

. The evalua-

tors again reported very similar scores in their evaluation, reaching

the same score 99.75% of the time when evaluating NoScript and

90.35% when evaluating the Tor Browser. We expect this lower

agreement score for the Tor Browser is a result of our evaluators

being routed differently through the Tor network, and receiving

different versions of the website based on the location of their exit

nodes.7

As Table 2 shows, the usability of our conservative and aggres-

sive configurations is as good as or better than other popularly

used browser security tools. This suggests that, while our Web API

Smaller sample sizes were used when evaluating the Tor Browser because of time

constraints, not for fundamental methodological reasons.

We chose to not fix the Tor exit node in a fixed location during this evaluation to

accurately recreate the experience of using the default configuration of the TBB.

standards cost-benefit approach has some affect on usability, it is a

cost security-sensitive users would accept.

6.3 Allowing Features For Trusted Applications

We further evaluated our approach by attempting to use several

popular, complex JavaScript applications in a browser in the

aggres-

sive

hardened configuration. We then created application-specific

configurations to allow these applications to run, but with access

to only the minimal set of features needed for functionality.

This process of creating specific feature configurations for differ-

ent applications is roughly analogous to granting trusted applica-

tions additional capabilities (in the context of a permissions based

system), or allowing trusted domains to run JavaScript code (in the

context of browser security extensions, like NoScript).

We built these application specific configurations using a tool-

assisted, trial and error process: first, we visited the application with

the browser extension in “debug” mode, which caused the extension

to log blocked functionality. Next, when we encountered a part of

the web application that did not function correctly, we reviewed the

extension’s log to see what blocked functionality seemed related to

the error. We then iteratively enabled the related blocked standards

and revisited the application, to see if enabling the standard allowed

the app to function correctly. We repeated the above steps until the

app worked as desired.

This process is would be beyond what typical web users would

be capable of, or interested in doing. Users who were interested

in improving the security of their browser, but not interested in

creating hardened app configurations themselves, could subscribe

to trusted, expert curated polices, similar to how users of AdBlock

Plus receive community created rules from EasyList. Section 8.2

discusses ways that rulesets could be distributed to users.

For each of the following tests, we started with a browser con-

figured in the previously mentioned

aggressive

hardened configu-

ration, which disables 42 of the 74 Web API standards measured in

this work. We then created application-specific configurations for

three popular, complex web applications, enabling only the addi-

tional standards needed to allow each application to work correctly

(as judged from the user’s perspective).

First, we watched videos on YouTube, by first searching for

videos on the site’s homepage, clicking on a video to watch, watch-

ing the video on its specific page, and then expanding the video’s

display to full-screen. Doing so required enabling three standards

that are blocked in our

aggressive

configuration: the File API stan-

dard

, the Media Source Extensions standard

, and the Fullscreen

API standard. Once we enabled these three standards on the site,

we were able to search for and watch videos on the site, while still

having 39 other standards disabled.

Second, we used the Google Drive application to write and save

a text document, formatting the text using the formatting features

provided by the website (creating bulleted lists, altering justifica-

tions, changing fonts and text sizes, embedding links, etc.). Doing so

required enabling two standards that are by default blocked in our

YouTube uses methods defined in this standard to create URL strings referring to

media on the page.

YouTube uses the

HTMLVideoElement.prototype.getVideoPlaybackQuality

method from this standard to calibrate video quality based on bandwith.

aggressive

configuration: the HTML: Web Storage standard

and

the UI Events standard

. Allowing Google Docs to access these two

additional standards, but leaving the other 40 standards disabled,

allowed us create rich text documents without any user-noticeable

affect in site functionality.

Third and finally, we used the Google Maps application to map a

route between Chicago and New York. We did so by first searching

for “Chicago, IL”, allowing the map to zoom in on the city, click-

ing the “Directions” button, searching for “New York, NY”, and

then selecting the “driving directions” option. Once we enabled the

HTML: Channel Messaging standard

we were able to use the site

as normal.

7 BROWSER EXTENSION

As part of this work, we are also releasing a Firefox browser ex-

tension that allows users to harden their browsers using the same

standard disabling technique described in this paper. The extension

is available as source code13.

7.1 Implementation

Our browser extension uses the same Web API standard disabling

technique described in Section 3 to dynamically control the DOM-

related attack surface to expose to websites. The extension allows

users to deploy the same conservative and aggressive hardened

browser configurations described in Section 6.1. Extension users

can also create their own hardened configurations by selecting any

permutation of the 74 measured Web API standards to disable.

Hardened configurations can be adjusted over time, as the rel-

ative security and benefit of different browser features changes.

This fixed-core-functionality, updated-policies deployment model

works well for popular web-modifying browser extensions (such as

AdBlock, PrivacyBadger and Ghostery). Our browser-hardening ex-

tension similarly allows users to subscribe to configuration updates

from external sources (trusted members of the security community,

a company’s IT staff, security-and-privacy advice groups, etc.), or

allows users to create their own configurations.

If a browser standard were found to be vulnerable to new attacks

in the future, security sensitive users could update their hardened

configurations to remove it. Likewise, if other features became more

popular or useful to users on the web, future hardened configu-

rations could be updated to allow those standards. The extension

enables users to define their own cost-benefit balance in the security

of their browser, rather than prescribing a specific configuration.

Finally, the tool allows users to create per-origin attack-surface

policies, so that trusted sites can be granted access to more JavaScript-

accessible features and standards than unknown or untrusted web-

sites. Similar to, but finer grained than, the origin based policies

of tools like NoScript, this approach allows users to better limit

websites to the least privilege needed to carry out the sites’ desired

functionality.

Google Drive uses functionality from this standard to track user state between pages.

Google Drive uses this standard for finer-grained detection of where the mouse

cursor is clicking in the application’s interface.

Which Google Maps uses to enable communication between different sub-parts of

the application.

13https://github.com/snyderp/firefox-api- blocking- extension

We discussed our approach with engineers at Mozilla, and we

are investigating how our feature usage measurement and blocking

techniques could be incorporated into Firefox Test Pilot as an ex-

perimental feature. This capability would allow wider deployment

of this technique within a genuine browsing environment, which

can also improve the external validity of our measurements.

7.2 Tradeoffs and Limitations

Implementing our approach as a browser extension entails signifi-

cant tradeoffs. It has the benefit of being easy for users to install

and update, and that it works on popular browsers already. The

extension approach also protect users from vulnerabilities that de-

pends on accessing a JavaScript-exposed method or data structure

(of which there are many, as documented in Section 5.2.2), with min-

imal re-engineering effort, allowing policies to be updated quickly,

as security needs change. Finally, the Web API standard-blocking,

extension approach is also useful for disabling large portions of

high-risk functionality, which could protect users from not-yet-

discovered bugs, in a way that ad-hoc fixing of known bugs could

not.

There are several significant downsides to the extension-based

approach however. First is that there are substantial categories

of browser exploits that our extension-based approach cannot

guard against. Our approach does not provide protection against

exploits that rely on browser functionality that is reachable through

means other than JavaScript-exposed functionality. The extension

would not provide protection against, for example, exploits in the

browser’s CSS parser, TLS code, or image parsers (since the attacker

would not require JavaScript to access such code-paths).

Additionally, the extension approach does not have access to

some information that could be used to make more sophisticated

decisions about when to allow a website to access a feature. An

alternate approach that modified the browser could use factors such

as the state of the stack at call time (e.x. distinguishing between

first-and-third party calls to a Web API standard), or where a func-

tion was defined (e.x. whether a function was defined in JavaScript

code delivered over TLS from a trusted website). Because such in-

formation is not exposed to the browser in JavaScript, our extension

is not able to take advantage of such information.

8 DISCUSSION

Below we outline some techniques which can be used with our

extension to maximize functionality for trusted websites while

simultaneously limiting the threat posed by unknown, untrusted

sites.

8.1 Potential Standards for Disabling

Standards that impose a large cost to the security and privacy

of browser users, while providing little corresponding benefit to

users, should be considered for removal from the browser. While

historically such steps are rare, Mozilla’s decision to remove the

Battery API shows that Web API standard removal is feasible.

We identify several standards as candidates for removal from

the browser, based on the low benefit they provide, and the high

risk they pose to users’ privacy and security. The High Resolution

Time Level 2,Canvas and Web Audio APIs have all been leveraged

in attacks in academic security research and have been associated

with CVEs (several severe). With perfect agreement, our testers

did not encounter any sites with broken functionality when these

standards were removed.

While its easy to imagine use cases for each of these standards,

our measurements indicate that such use cases are rare. The over-

whelming majority of websites do not require them to deliver their

content to users. Disabling these standards by default, and requiring

users to actively enable them, much like access to a user’s location

or webcam, would improve browser security at a minimal cost to

user convenience.

8.2 Dynamic Policy Configuration

Our evaluation uses a global policy for all websites. This approach

could be modified to apply different levels of trust to different

origins of code, similar to what TBB and NoScript do. A set of

community-derived feature rules could also be maintained for dif-

ferent websites, much like the EasyList ad blocker filter [

], with

our conservative and aggressive profiles serving as sensible de-

faults.

One could also apply heuristics to infer a user’s level of trust

with a given website. When visiting a site for the first time, a user

has no preexisting relationship with that origin. Under this insight,

different features could be exposed depending on how often a user

visits a site, or whether the user has logged in to that website.

Similarly, browser vendors could reduce the set of enabled Web

API standards in “private browsing modes”, where users signal their

desire for privacy, at the possible cost of some convenience. This

signal is already being used, as Firefox enables enhanced tracking

protection features when a user enables private browsing mode.

Disabling high-cost standards in such a mode would be a further

way to protect user privacy and security.

9 CONCLUSION

As browser vendors move away from plugins and provide more

functionality natively within the DOM, the modern web browser

has experienced a terrific growth in features available to every web

page that a user might visit. Indeed, part of the appeal of the web

is the ability to deploy complex, performant software without the

user even realizing that it has happened.14

However, the one size fits all approach to exposing these features

to websites has a cost which is borne in terms of vulnerabilities,

exploits, and attacks. Simplistic approaches like ripping out every

feature that isn’t absolutely necessary are not practical solutions

to this problem. We believe that enabling users to contextually

control and empirically decide which features are exposed to which

websites will allow the web to continue to improve the browser’s

feature set and performance, while still being usable in high risk

situations where the security of a reduced feature set is desired.

10 ACKNOWLEDGEMENTS

Thank you to Joshua Castor and Moin Vahora for performing the

manual website analysis. This work was supported in part by Na-

tional Science Foundation grants CNS-1409868, CNS-1405886 and

DGE-1069311.

14https://xkcd.com/1367/

REFERENCES

[1] Adblock plus. https://adblockplus.org/. [Online; accessed 16-October-2015].

[2]

Cve-2011-2363. https://cve.mitre.org/cgi-bin/cvename.cgi?name=

CVE-2011- 2363, 2011. [Online; accessed 11-August-2016].

[3]

Cve-2012-4171. https://cve.mitre.org/cgi-bin/cvename.cgi?name=

CVE-2012- 4171, 2012. [Online; accessed 11-August-2016].

[4]

Cve-2013-2031. https://cve.mitre.org/cgi-bin/cvename.cgi?name=

CVE-2013- 2031, 2013. [Online; accessed 11-August-2016].

[5]

Chromium blink mailing list discussion. https://groups.google.com/a/chromium.

org/forum/#!topic/blink-dev/1wWhVoKWztY, 2014. [Online; accessed 15-

February-2016].

[6]

Android developer’s guide: System permissions. https://developer.android.com/

guide/topics/security/permissions.html, 2015. [Online; accessed 17-February-

2016].

[7]

Cve-2015-0818. https://cve.mitre.org/cgi-bin/cvename.cgi?name=

CVE-2015- 0818, 2015. [Online; accessed 11-August-2016].

[8]

Chromium blink web features guidelines. https://dev.chromium.org/blink#

new-features, 2016. [Online; accessed 15-February-2016].

[9]

High resolution time level 2. https://www.w3.org/TR/hr-time-2/, 2016. [Online;

accessed 11-November-2016].

[10]

Web workers. https://www.w3.org/TR/workers/, 2016. [Online; accessed 13-

August-2016].

[11]

Webrtc 1.0: Real-time communication between browsers. https://www.w3.org/

TR/webrtc/, 2016. [Online; accessed 11-August-2016].

[12]

Acar, G., Eubank, C., Englehardt, S., Juarez, M., Narayanan, A., and Diaz, C.

The web never forgets: Persistent tracking mechanisms in the wild. In Proceedings

of the 2014 ACM SIGSAC Conference on Computer and Communications Security

(2014), ACM, pp. 674–689.

[13]

Acar, G., Juarez, M., Nikiforakis, N., Diaz, C., Gürses, S., Piessens, F., and

Preneel, B. Fpdetective: dusting the web for fingerprinters. In Proceedings of

the 2013 ACM SIGSAC conference on Computer & communications security (2013),

ACM, pp. 1129–1140.

[14]

Adenot, P., Wilson, C., and Rogers, C. Web audio api. http://www.w3.org/

TR/webaudio/, 2013.

[15]

Alaca, F., and van Oorschot, P. Device fingerprinting for augmenting web

authentication: Classification and analysis of methods. In Proceedings of the 32th

Annual Computer Security Applications Conference (2016).

[16]

Andrysco, M., Kohlbrenner, D., Mowery, K., Jhala, R., Lerner, S., and

Shacham, H. On subnormal floating point and abnormal timing. In 2015 IEEE

Symposium on Security and Privacy (2015), IEEE, pp. 623–639.

[17]

Au, K. W. Y., Zhou, Y. F., Huang, Z., Gill, P., and Lie, D. Short paper: a look

at smartphone permission models. In Proceedings of the 1st ACM workshop on

Security and privacy in smartphones and mobile devices (2011), ACM, pp. 63–68.

[18]

Black Duck Software Inc. The chromium (google chrome) open source project

on open hub. https://www.openhub.net/p/chrome/analyses/latest/code_history,

2015. [Online; accessed 16-October-2015].

[19]

Blue, V. You say advertising, i say block that malware. http://www.engadget.

com/2016/01/08/you-say- advertising-i- say-block-that- malware/, 2016. [Online;

accessed 15-February-2016].

[20]

Bryant, M. The noscript misnomer - why should

i trust vjs.zendcdn.net? https://thehackerblog.com/

the-noscript- misnomer-why- should-i-trust- vjs-zendcdn- net/index.html,

2015. [Online; accessed 12-August-2016].

[21]

Cao, Y., Li, S., and Wijmans, E. (Cross-)Browser Fingerprinting via OS and

Hardware Level Features. In Proceedings of the Symposium on Networked and

Distributed System Security (2017).

[22]

DahlstrÃűm, E., Dengler, P., Grasso, A., Lilley, C., McCormack, C., Schepers,

D., and Watt, J. Scalable vector graphics (svg) 1.1 (second edition). http:

//www.w3.org/TR/SVG11/, 2011.

[23]

Das, A., Borisov, N., and Caesar, M. Tracking mobile web users through

motion sensors: Attacks and defenses. In Proceedings of the 23rd Annual Network

and Distributed System Security Symposium (NDSS) (2016).

[24]

Dingledine, R., Mathewson, N., and Syverson, P. Tor: The second-generation

onion router. Tech. rep., DTIC Document, 2004.

[25] Dorwin, D., Smith, J., Watson, M., and Bateman, A. Encrypted media exten-

sions. http://www.w3.org/TR/encrypted-media/, 2015.

[26]

Englehardt, S., and Narayanan, A. Online tracking: A 1-million-site mea-

surement and analysis. In Proceedings of the 2016 ACM SIGSAC Conference on

Computer and Communications Security (2016), ACM, pp. 1388–1401.

[27]

Fanboy, MonztA, Famlam, and Khrin. Easylist. https://easylist.adblockplus.

org/en/. [Online; accessed 16-October-2015].

[28]

Gelernter, N., and Herzberg, A. Cross-site search attacks. In Proceedings of

the 22nd ACM SIGSAC Conference on Computer and Communications Security

(2015), ACM, pp. 1394–1405.

[29]

Google. boringssl - git at google. https://boringssl.googlesource.com/boringssl/,

2016. [Online; accessed 12-November-2016].

[30]

Gras, B., Razavi, K., Bosman, E., Bos, H., and Giuffrida, C. ASLR on the

Line: Practical Cache Attacks on the MMU. In Proceedings of the Symposium on

Networked and Distributed System Security (2017).

[31]

Gruss, D., Bidner, D., and Mangard, S. Practical memory deduplication attacks

in sandboxed javascript. In European Symposium on Research in Computer Security

(2015), Springer, pp. 108–122.

[32]

Guarnieri, S., and Livshits, B. Gatekeeper: mostly static enforcement of

security and reliability policies for javascript code. In Proceedings of the 18th

conference on USENIX security symposium (Berkeley, CA, USA, 2009), SSYM’09,

USENIX Association, pp. 151–168.

[33]

Heiderich, M., Frosch, T., and Holz, T. Iceshield: detection and mitigation

of malicious websites with a frozen dom. In International Workshop on Recent

Advances in Intrusion Detection (2011), Springer, pp. 281–300.

[34]

Ho, G., Boneh, D., Ballard, L., and Provos, N. Tick tock: building browser red

pills from timing side channels. In 8th USENIX Workshop on Offensive Technologies

(WOOT 14) (2014).

[35]

Kim, H., Lee, S., and Kim, J. Exploring and mitigating privacy threats of html5

geolocation api. In Proceedings of the 30th Annual Computer Security Applications

Conference (2014), ACM, pp. 306–315.

[36] Kostiainen, A. Vibration. http://www.w3.org/TR/vibration/, 2105.

[37]

Kostiainen, A., Oksanen, I., and Hazaël-Massieux, D. Html media capture.

http://www.w3.org/TR/html-media-capture/, 2104.

[38]

Kotcher, R., Pei, Y., Jumde, P., and Jackson, C. Cross-origin pixel stealing:

timing attacks using css filters. In Proceedings of the 2013 ACM SIGSAC conference

on Computer & communications security (2013), ACM, pp. 1055–1062.

[39]

Lamouri, M., and Cï£¡ceres, M. Screen orientation. http://www.w3.org/TR/

screen-orientation/, 2105.

[40]

Laperdrix, P., Rudametkin, W., and Baudry, B. Beauty and the beast: Divert-

ing modern web browsers to build unique browser fingerprints. In 37th IEEE

Symposium on Security and Privacy (S&P 2016) (2016).

[41]

Liu, C., White, R. W., and Dumais, S. Understanding web browsing behaviors

through weibull analysis of dwell time. In Proceedings of the 33rd international

ACM SIGIR conference on Research and development in information retrieval (2010),

ACM, pp. 379–386.

[42]

Maone, G. Noscript - javascript/java/flash blocker for a safer firefox experience!

https://noscript.net/, 2015. [Online; accessed 08-February-2015].

[43] Meyerovich, L. A., and Livshits, B. Conscript: Specifying and enforcing fine-

grained security policies for javascript in the browser. In 2010 IEEE Symposium

on Security and Privacy (2010), IEEE, pp. 481–496.

[44] Miller, M. S. Google caja. https://developers.google.com/caja/, 2013.

[45] Mozilla Corporation. Dxr. https://github.com/mozilla/dxr, 2016.

[46]

Nikiforakis, N., Kapravelos, A., Joosen, W., Kruegel, C., Piessens, F., and

Vigna, G. Cookieless monster: Exploring the ecosystem of web-based device

fingerprinting. In IEEE Symposium on Security and Privacy (2013).

[47]

Olejnik, L. Stealing sensitive browser data with the W3C

Ambient Light Sensor API. https://blog.lukaszolejnik.com/

stealing-sensitive- browser- data-with-the-w3c-ambient- light-sensor-api/, 2017.

[48]

Olejnik, L., Acar, G., Castelluccia, C., and Diaz, C. The leaking battery a

privacy analysis of the html5 battery status api. Tech. rep., Cryptology ePrint

Archive, Report 2015/616, 2015, ht tp://eprint. iacr. org, 2015.

[49]

Oren, Y., Kemerlis, V. P., Sethumadhavan, S., and Keromytis, A. D. The spy in

the sandbox: Practical cache attacks in javascript and their implications. In Pro-

ceedings of the 22nd ACM SIGSAC Conference on Computer and Communications

Security (2015), ACM, pp. 1406–1418.

[50]

Ozment, A., and Schechter, S. E. Milk or wine: does software security improve

with age? In Usenix Security (2006).

[51]

Patrizio, A. How forbes inadvertently proved the anti-malware value

of ad blockers. http://www.networkworld.com/article/3021113/security/

forbes-malware- ad-blocker- advertisements.html, 2016. [Online; accessed 15-

February-2016].

[52]

Perry, M., Clark, E., and Murdoch, S. The design and implementation

of the tor browser. https://www.torproject.org/projects/torbrowser/design/

#fingerprinting-linkability, 2015. [Online; accessed 15-February-2016].

[53]

Shin, Y., Meneely, A., Williams, L., and Osborne, J. A. Evaluating complexity,

code churn, and developer activity metrics as indicators of software vulnerabili-

ties. IEEE Transactions on Software Engineering 37, 6 (2011), 772–787.

[54]

Snyder, P., Ansari, L., Taylor, C., and Kanich, C. Browser feature usage on

the modern web. In Proceedings of the 2016 Internet Measurement Conference (to

appear) (2016).

[55]

Son, S., and Shmatikov, V. The postman always rings twice: Attacking and

defending postmessage in html5 websites. In NDSS (2013).

[56]

Stamm, S., Sterne, B., and Markham, G. Reining in the web with content

security policy. In Proceedings of the 19th International Conference on World Wide

Web (2010), ACM, pp. 921–930.

[57]

Tian, Y., Liu, Y. C., Bhosale, A., Huang, L. S., Tague, P., and Jackson, C. All

your screens are belong to us: attacks exploiting the html5 screen sharing api.

In 2014 IEEE Symposium on Security and Privacy (2014), IEEE, pp. 34–48.

[58]

Turner, D., and Kostiainen, A. Ambient light events. http://www.w3.org/TR/

ambient-light/, 2105.

[59]

Van Goethem, T., Joosen, W., and Nikiforakis, N. The clock is still ticking:

Timing attacks in the modern web. In Proceedings of the 22nd ACM SIGSAC

Conference on Computer and Communications Security (2015), ACM, pp. 1382–

1393.

[60]

Van Goethem, T., Vanhoef, M., Piessens, F., and Joosen, W. Request and

conquer: Exposing cross-origin resource size. In Proceedings of the Usenix Security

Symposium (2016).

[61]

Web Hypertext Application Technology Working Group (WHATWG).

Html living standard. https://html.spec.whatwg.org/, 2015.

[62]

Weissbacher, M., Robertson, W.,Kirda, E., Kruegel, C., and Vigna, G. Zigzag:

Automatically hardening web applications against client-side validation vul-

nerabilities. In 24th USENIX Security Symposium (USENIX Security 15) (2015),

pp. 737–752.

[63]

Xu, M., Jang, Y., Xing, X., Kim, T., and Lee, W. Ucognito: Private browsing

without tears. In Proceedings of the 22nd ACM SIGSAC Conference on Computer

and Communications Security (2015), ACM, pp. 438–449.

[64]

Zimmermann, T., Nagappan, N., and Zeller, A. Predicting bugs from history.

In Software Evolution. Springer, 2008, pp. 69–88.

AJAX

DOM

DOM1

DOM2−C

DOM2−E

DOM2−S H−C H−WW

HTML

SVG

WEBA

WEBGL

WRTC

25%

50%

75%

100%

0 10 20 30

Attributed CVEs Since 2010

Sites Broken Without this Feature

Figure 7: A scatter plot showing the number of CVEs filed

against each standard since 2010, by how many sites in the

Alexa 10k break when the standard is removed.

A BROWSER CONFIGURATIONS

Standard Conservative Aggressive

Beacon X X

DOM Parsing and Serialization X X

Fullscreen API X X

High Resolution Time Level 2 X X

HTML: Web Sockets X X

HTML: Channel Messaging X X

HTML: Web Workers X X

Indexed Database API X X

Performance Timeline Level 2 X X

Resource Timing X X

Scalable Vector Graphics 1.1 X X

UI Events Specification X X

Web Audio API X X

WebGL Specification X X

Ambient Light Sensor API X

Battery Status API X

CSS Conditional Rules Module Level 3 X

CSS Font Loading Module Level 3 X

CSSOM View Module X

DOM Level 2: Traversal and Range X

Encrypted Media Extensions X

execCommand X

Fetch X

File API X

Gamepad X

Geolocation API Specification X

HTML: Broadcasting X

HTML: Plugins X

HTML: History Interface X

HTML: Web Storage X

Media Capture and Streams X

Media Source Extensions X

Navigation Timing X

Performance Timeline X

Pointer Lock X

Proximity Events X

Selection API X

The Screen Orientation API X

Timing control for script-based animations X

URL X

User Timing Level 2 X

W3C DOM4 X

Web Notifications X

WebRTC 1.0 X

Table 3: Listing of which standards were disabled in the eval-

uated conservative and aggressive hardened browser config-

urations.

Standard Name Abbreviation # Alexa 10k Site Break Agree # CVEs # High or % ELoC Enabled

Using Rate % Severe attacks

WebGL WEBGL 852 <1% 93% 31 22 27.43 [15, 21, 34, 40]

HTML: Web Workers H-WW 856 0% 100% 16 9 1.63 [30, 34]

WebRTC WRTC 24 0% 93% 15 4 2.48 [15, 26]

HTML: The canvas element H-C 6935 0% 100% 14 6 5.03 [12, 15, 21, 26, 34, 38, 40]

Scalable Vector Graphics SVG 1516 0% 98% 13 10 7.86

Web Audio API WEBA 148 0% 100% 10 5 5.79 [15, 26]

XMLHttpRequest AJAX 7806 32% 82% 11 4 1.73

HTML HTML 8939 40% 85% 6 2 0.89 [13, 46]

HTML 5 HTML5 6882 4% 97% 5 2 5.72

Service Workers SW 0 0% - 5 0 2.84 [28, 59, 60]

HTML: Web Sockets H-WS 514 0% 95% 5 3 0.67

HTML: History Interface H-HI 1481 1% 96% 5 1 1.04

Indexed Database API IDB 288 <1% 100% 4 2 4.73 [12, 15]

Web Cryptography API WCR 7048 4% 90% 4 3 0.52

Media Capture and Streams MCS 49 0% 95% 4 3 1.08 [57]

DOM Level 2: HTML DOM2-H 8956 13% 89% 3 1 2.09

DOM Level 2: Traversal and Range DOM2-T 4406 0% 100% 3 2 0.04

HTML 5.1 HTML51 2 0% 100% 3 1 1.18

Resource Timing RT 433 0% 98% 3 0 0.10

Fullscreen API FULL 229 0% 95% 3 1 0.12

Beacon BE 2302 0% 100% 2 0 0.23

DOM Level 1 DOM1 9113 63% 96% 2 2 1.66

DOM Parsing and Serialization DOM-PS 2814 0% 83% 2 1 0.31

DOM Level 2: Events DOM2-E 9038 34% 96% 2 0 0.35

DOM Level 2: Style DOM2-S 8773 31% 93% 2 1 0.69

Fetch F 63 <1% 90% 2 0 1.14 [28, 59, 60]

CSS Object Model CSS-OM 8094 5% 94% 1 0 0.17 [46]

DOM DOM 9050 36% 94% 1 1 1.29

HTML: Plugins H-P 92 0% 100% 1 1 0.98 [13, 15]

File API FA 1672 0% 83% 1 0 1.46

Gamepad GP 1 0% 71% 1 1 0.07

Geolocation API GEO 153 0% 96% 1 0 0.26 [35, 63]

High Resolution Time Level 2 HRT 5665 0% 100% 1 0 0.02 [16, 28, 30, 31, 34, 38, 49, 59]

HTML: Channel Messaging H-CM 4964 0% 0.025 1 0 0.40 [55, 62]

Navigation Timing NT 64 0% 98% 1 0 0.09

Web Notifications WN 15 0% 100% 1 1 0.82

Page Visibility (Second Edition) PV 0 0% - 1 1 0.02

UI Events UIE 1030 <1% 100% 1 0 0.47

Vibration API V 1 0% 100% 1 1 0.08

Console API CO 3 0% 100% 0 0 0.59 [34]

CSSOM View Module CSS-VM 4538 0% 100% 0 0 2.85 [13]

Battery Status API BA 2317 0% 100% 0 0 0.15 [15, 26, 46, 48]

CSS Conditional Rules Module Lvl 3 CSS-CR 416 0% 100% 0 0 0.16

CSS Font Loading Module Level 3 CSS-FO 2287 0% 98% 0 0 1.24 [13, 15]

DeviceOrientation Event DO 0 0% - 0 0 0.06 [15, 23]

DOM Level 2: Core DOM2-C 8896 89% 97% 0 0 0.29

DOM Level 3: Core DOM3-C 8411 4% 96% 0 0 0.25

DOM Level 3: XPath DOM3-X 364 1% 97% 0 0 0.16

Encrypted Media Extensions EME 9 0% 100% 0 0 1.91

HTML: Web Storage H-WB 7806 0% 83% 0 0 0.55 [15, 34, 63]

Media Source Extensions MSE 1240 0% 95% 0 0 1.97

Selectors API Level 1 SLC 8611 15% 89% 0 0 0.00

Script-based animation timing control TC 3437 0% 100% 0 0 0.08 [46]

Ambient Light Sensor API ALS 18 0% 89% 0 0 0.00 [46, 47]

Table 4: This table includes data on all 74 measured Web API standards, excluding the 20 standards with a 0% break rate, 0 associated CVEs and accounting for

less than one percent of measured effective lines of code:

(1) The standard’s full name

(2) The abbreviation used when referencing this standard in the paper

(3) The number of sites in the Alexa 10k using the standard, per [54]

(4) The portion of measured sites that were broken by disabling the standard. (see Section 4.4)

(5) The mean agreement between two independent testers’ evaluation of sites visited while that feature was disabled (see Section 4.4)

(6) The number of CVEs since 2010 associated with the feature

(7) The number of CVEs since 2010 ranked as “high” or “severe”

(8) The percentage of lines of code exclusively used to implement this standard, expressed as a percentage of all 75,650 lines found using this methodology

(see Section 4.5.2).

(9) Citations for papers describing attacks relying on the standard