Pixel Perfect: Fingerprinting Canvas in HTML5

Keaton Mowery and Hovav Shacham

Department of Computer Science and Engineering

University of California, San Diego

La Jolla, California, USA

ABSTRACT

Tying the browser more closely to operating system func-

tionality and system hardware means that websites have

more access to these resources, and that browser behavior

varies depending on the behavior of these resources.

We propose a new system ﬁngerprint, inspired by the ob-

servation above: render text and WebGL scenes to a <can-

vas> element, then examine the pixels produced. The new

ﬁngerprint is consistent, high-entropy, orthogonal to other

ﬁngerprints, transparent to the user, and readily obtainable.

1. INTRODUCTION

Browsers are becoming increasingly sophisticated applica-

tion platforms, taking on more of the functionality tradition-

ally provided by an operating system. Much of this increas-

ing sophistication is driven by the HTML5 suite of speciﬁ-

cations, which make provisions for a programmatic drawing

surface (<canvas>), three-dimensional graphics (WebGL),

a structured client-side datastore, geolocation services, the

ability to manipulate browser history and the browser cache,

audio and video playback, and more.

The natural way for browsers to implement such features

is to draw on the host operating system and hardware. Using

the GPU for 3D graphics (and even for 2D graphics com-

positing

) provides substantial performance improvements,

as well as battery savings on mobile devices. And using

the operating system’s font-rendering code for text means

that browsers automatically display text in a way that is

optimized for the display and consistent with the user’s ex-

pectations.

This paper proceeds from the following simple observa-

tion: Tying the browser more closely to operating system

functionality and system hardware means that websites have

more access to these resources, and that browser behavior

varies depending on the behavior of these resources. The

ﬁrst part of this observation has security implications: code-

bases not designed to handle adversarial input can now be

exposed to it.

The second part of the observation, which

For example, IE9 uses the GPU for compositing, and recent

releases of Chrome use the GPU to accelerate 2D operations

on the canvas.

By contrast, the ﬁrst release of Safari for Windows im-

ported font rendering code from Mac OS X, which oﬀended

some users; see http://www.joelonsoftware.com/items/

2007/06/12.html.

Indeed, one test in the WebGL conformance suite induces

a hard system crash on many systems [9]; and the TrueType

font handling code in Windows and OS X, which is exposed

we focus on, has privacy implications: diﬀerent behavior can

be used to distinguish systems, and thereby ﬁngerprint the

people using them.

Our results.

We exhibit a new system ﬁngerprint based on browser font

and WebGL rendering. To obtain this ﬁngerprint, a website

renders text and WebGL scenes to a <canvas> element, then

examines the pixels produced. Diﬀerent systems produce

diﬀerent output, and therefore diﬀerent ﬁngerprints. Even

very simple tests — such as rendering a single sentence in a

widely distributed system font — produce surprising varia-

tion. The new ﬁngerprint has several desirable properties:

• It is consistent. In our experiments, we obtain pixel-

identical results in independent trials from the same

user.

• It is high-entropy. In 294 experiments on Amazon’s

Mechanical Turk, we observed 116 unique ﬁngerprint

values, for a sample entropy of 5.73 bits. This is so

even though the user population in our experiments

exhibits little variation in browser and OS.

• It is orthogonal to other ﬁngerprints. Our ﬁngerprint

measures graphics driver and GPU model, which is in-

dependent of other possible ﬁngerprints discussed be-

low.

• It is transparent to the user. Our tests can be per-

formed, oﬀscreen, in a fraction of a second. There is

no indication, visual or otherwise, that the user’s sys-

tem is being ﬁngerprinted.

• It is readily obtainable. Any website that runs Java-

Script on the user’s browser can ﬁngerprint its ren-

dering behavior; no access is needed besides what is

provided by the usual web attacker model.

Our ﬁngerprint can be used as a black box or as a white

box. A website could render tests to a <canvas>, extract the

resulting pixmap, then use a cryptographic hash to obtain

a short, convenient ﬁngerprint. Because the ﬁngerprint is

consistent, the pixmap (and therefore its hash) will be iden-

tical in multiple runs on one machine, but take on diﬀerent

values depending on hardware and software conﬁguration.

This is a black-box use of the ﬁngerprint, since it extracts

to attackers by the WebFont speciﬁcation, was patched to ﬁx

an exploitable parsing vulnerability as recently as December

of last year [2, 1].

distinguishing entropy without being concerned with the im-

plementation details.

Alternatively, a website could use a particular test pixmap

as evidence that a user is running some particular conﬁgu-

ration of browser, operating system, graphics driver, GPU,

and, perhaps, display. To identify a user system, the site

can compare the pixmap it produces against a labeled cor-

pus, such as the corpus we obtained using Mechanical Turk.

An intriguing possibility is that GPU quirks could be used

to identify a pixmap without comparing against a corpus.

However it is performed, such a white-box use of our ﬁn-

gerprint in this way reveals private information about users’

systems.

It could also be used to target an attack more

precisely, by identifying speciﬁc vulnerable system conﬁgu-

rations. Trying to exploit only those systems that appear

likely to be vulnerable could reduce the number of crashes

caused by the attack, and therefore the likelihood that it is

detected by the operating system vendor.

Fingerprints on the web have constructive and destructive

uses [14]. A use is constructive if users beneﬁt from being

ﬁngerprinted. For example, a bank could ﬁngerprint a user’s

machine, then require additional authentication for login at-

tempts from systems whose ﬁngerprint does not match. A

use is destructive if users do not beneﬁt from being tracked,

or do not wish to be tracked. Users can attempt to avoid

tracking by using their browsers’“private browsing”modes [3]

or the Tor anonymity service [6].

Users of Tor may be willing to endure a slower, less at-

tractive browsing experience to avoid being tracked. (Note

that, although Torbutton disables WebGL, it allows text

rendering to a <canvas>, and is thus at present partly vul-

nerable to our ﬁngerprint.) For mainstream browser users,

however, the possibility of ﬁngerprinting might be an un-

avoidable consequence of browsers’ closer ties to operating

system functionality and system hardware.

Related work: Fingerprints on the web.

The earliest mentions known to us of using diﬀerences in

GPU rendering to ﬁngerprint users are in 2010 discussions on

the WebGL mailing list about whether the WebGL renderer

information available to JavaScript should provide informa-

tion about the GPU and driver. Steve Baker argued [4] that

it is possible to identify a GPU without this information: “I

bet that if I wrote code to read back every glGet result and

built up a database of the results - and wrote code to time

things like vertex texture performance - then I bet I could

identify most hardware fairly accurately.” Benoit Jacob later

observed [11] that

We haven’t yet started accounting for GPU ren-

dering analysis (not just WebGL: in the upcom-

ing generation of browsers, most rendering goes

through the GPU and is subject to GPU/driver/

conﬁg-based rendering diﬀerences.

Jacob also suggests the ﬁngerprinting approach we take:

“Rendering analysis could proceed by rendering stuﬀ into

a canvas 2D and getting its ImageData.” One way to view

our research is as demonstrating experimentally that Baker

and Jacob were correct in expecting substantial additional

As evidence that such information is private, we note that

Chrome knows a great deal about the graphics subsystem —

see chrome://gpu — but does not expose this information to

JavaScript.

leakage from GPU-based rendering. In addition, we show

that there is substantial information leakage from font ren-

dering to <canvas>.

Many other researchers have proposed techniques to ﬁn-

gerprint web users. These techniques rely on many browser

features, including the history and ﬁle cache [12], informa-

tion in HTTP headers and available plugins [13, 7], diﬀer-

ences in JavaScript and DOM API support [8], JavaScript

performance [14], available fonts [5], and deviations from

JavaScript standards conformance [16].

2. HTML5 AND CSS3

In this section, we introduce the emerging web technolo-

gies used in our experiments. First, we present information

about the <canvas> element, a major portion of what is

termed HTML5

, along with its support for text render-

ing. Next, we examine WebFonts, part of the CSS3 speci-

ﬁcation

. Lastly, we brieﬂy discuss WebGL, an experimen-

tal speciﬁcation

currently managed by the Khronos Group

(which also maintains the OpenGL speciﬁcation).

These three speciﬁcations are not ﬁnalized, and so could

change in ways that beneﬁt or hinder ﬁngerprinting success.

However, our ﬁngerprinting mechanisms use extremely ba-

sic features of these platforms, such as rendering text and

inspecting pixels — removal of these features would be dra-

matic indeed.

2.1 HTML5 Canvas

One of the most interesting new elements in HTML5,

<canvas> provides an area of the screen which can be drawn

upon programmatically. It enjoys widespread support, be-

ing available in the most recent versions of Chrome, Firefox,

Internet Explorer, Opera, and Safari as well as Mobile Safari

and Android Browser.

The basic approach to drawing on a canvas is simple: ac-

quire a graphics context, and use the context’s API to eﬀect

your changes. In the current HTML5 speciﬁcation, the only

deﬁned context is “2d”. The 2d context provides basic draw-

ing primitives such as fillRect, lineTo, and arc, as well

as more complicated features such as B´ezier curves, color

gradients, and copying in an existing image.

2.1.1 Canvas Text

We chose to focus on the text support found in the 2d con-

text. Given a font size, family, and baseline, the 2d context

can draw any arbitrary text string to the canvas. No wrap-

ping is performed; the 2d context will happily draw text

directly oﬀ the edge of the canvas. Lastly, <canvas> sup-

ports CSS-like text styling, allowing for any combination of

font and size. For an example of how text is rendered, see

Figure 1.

2.1.2 Pixel Extraction

In order for <canvas> to be a useful ﬁngerprint, there must

be some way to examine its behavior. Fortunately, <canvas>

makes this extremely easy, providing several ways to inspect

its data with pixel accuracy.

http://www.whatwg.org/specs/web-apps/

current-work/

http://www.w3.org/TR/css3-fonts/

http://www.khronos.org/registry/webgl/specs/1.0/

var canvas = document.getElementById("drawing");

var context = canvas.getContext("2d");

context.font = "18pt Arial";

context.textBaseline = "top";

context.fillText("Hello, user.", 2, 2);

</script>

Figure 1: Render text on a canvas

First, the 2d context provides the method getImageData().

Given a rectangular region of the canvas, this method re-

turns an ImageData object. Contained in this object are the

RGBA values (as integers) for every pixel in the requested

region.

Second, the canvas object itself provides a toDataURL(type)

method. When passed “image/png”, this method returns a

data url consisting of the Base64 encoding of a PNG image

containing the entire contents of the canvas. As this is a

very convenient canvas-level method, we used this approach

to extract data in our experiments. During black-box use

of these ﬁngerprints, the test suite could simply hash these

data URLs, thereby removing the need to upload entire im-

ages from each client.

It is worthwhile to note that these methods do preserve the

same origin policy — if an image from a diﬀerent origin has

been drawn on this canvas, they will throw a SecurityError

exception instead of returning pixel data. Therefore, our

<canvas> ﬁngerprints must only contain image resources

that are under our control.

2.2 WebFonts

WebFonts, speciﬁed in CSS3, allow web designers to load a

font face on-demand, rather than relying solely on the fonts

installed on each client machine. To include a font, the web

designer inserts a @font-face CSS rule with a src attribute

pointing to a font in an appropriate format. The browser

then downloads the font and makes it available for use on

the page. Fortunately for us, web fonts can be used when

writing to a <canvas> as well.

To include WebFonts, we depend on the WebFont Loader

co-developed by Google and Typekit. With this library,

WebFonts can be loaded solely through the use of Java-

Script, and callbacks can be established for certain events

(such as the font becoming available or, conversely, failing

to load). By attaching our rendering to a successful load,

we are guaranteed to use the correct font while writing to

the canvas.

2.3 WebGL

WebGL provides a JavaScript API for rendering 3D graph-

ics in a <canvas> element. Modeled after OpenGL ES 2.0,

WebGL is currently a draft speciﬁcation and implemented

and enabled in Chrome, Firefox, and Opera, as well as im-

plemented but disabled in Safari. Each of these browsers

provides a hardware-accelerated implementation, using the

installed graphics hardware to render each frame. To miti-

gate serious misbehaviour and crashes, all of these browsers

enable WebGL only for a whitelisted set of graphics cards

and drivers.

https://developers.google.com/webfonts/docs/

webfont_loader

Current WebGL implementations expose their function-

ality through a separate canvas context (which will even-

tually be named “webgl”). The WebGL API is too com-

plex to describe here in suﬃcient detail, but is stylistically

similar to the desktop OpenGL API. It provides for ver-

tex and fragment shaders, written in OpenGL Shading Lan-

guage (GLSL), that, after compilation, run directly on the

graphics card. WebGL also provides for OpenGL-style tex-

tures, as well as diﬀerent lighting primitives. More advanced

techniques, such as specular highlighting, bump mapping,

and transparency, can be achieved through custom GLSL

shaders.

2.4 Security Implications

These new capabilities, while providing more and more

ways for developers to produce interesting and useful web

content, do come at a cost. For eﬃciency’s sake, inputs from

the web are passed farther and farther down the software

stack: for example, GLSL shaders are compiled directly from

web pages and run on the graphics card, allowing arbitrary

data to pass between the JavaScript execution engine and

the kernel-level graphics driver. Other attack surfaces are

possible: malicious or misguided GLSL shaders can crash or

hang the entire operating system on OSX and Windows XP

or cause GPU resets on Windows 7[9].

WebFonts, while appearing more innocent, can also be

a security concern. Remote code execution vulnerabilities

while parsing TrueType fonts have been discovered in Win-

dows[2], OSX, Debian, Red Hat, and iOS[1].

While we do not use these exploits in this paper, we take

advantage of the fact that these new web technologies, for

eﬃciency’s sake, push untrusted web content deep into the

operating system stack. In our case, however, we simply

examine the results of these operations, exposing diﬀerences

in implementation (however slight).

3. EXPERIMENTS

In this section, we discuss the tests that underly our ﬁn-

gerprinting scheme, as well as the support infrastructure we

built in order to deliver the tests and inspect their results.

We will also detail the process of ﬁngerprint collection from

a large number of disparate users on the web.

3.1 Tests

For our ﬁngerprints, we use six tests: text_arial, text-

_arial_px, text_webfont, text_webfont_px, text_nonsense,

and webgl. Each test follows the same basic outline: render

test data to a canvas and extract its contents as an encoded

PNG.

3.1.1 Arial Text

In our ﬁrst two tests, we render a short sentence in Arial,

a font known for its ubiquity on the web. To exercise each

letterform, we use the pangram “How quickly daft jumping

zebras vex.”, along with some added punctuation.

For text_arial, the text is rendered to the canvas in 18pt

Arial. In text_arial_px, we change the font speciﬁcation

to 20px Arial. The actual code for these two tests is almost

identical to the snippet in Figure 1 — complicated tests

aren’t needed for ﬁngerprinting!

Example images produced by these two tests are shown

in Figure 2.

Figure 2: text_arial (top) and text_arial_px

Figure 3: text_webfont (top) and text_webfont_px

Figure 4: text_nonsense

3.1.2 WebFont Text

These two tests are extremely similar to the Arial tests,

with the added complexity of loading a new font from a web

server. In a more sophisticated or targeted ﬁngerprint, the

delivered font could be carefully tuned by the ﬁngerprinter

to exercise corner cases in font loading.

In our case, however, we use the WebFont Loader to load

“Sirin Stencil” from the Google Web Fonts server

. Once

it loads, we render the same pangram as in our Arial tests.

For text_webfont, the text is set in 12pt Sirin Stencil, while

text_webfont_px uses 15px Sirin Stencil.

Example images are shown in Figure 3.

3.1.3 Nonsense Text

Code-wise, this test is nearly identical to the two Arial

tests. However, instead of a valid font speciﬁcation, we set

the 2d font speciﬁcation to “not even a font spec in the slight-

est”. This exercises the fallback handling mechanisms in the

browser: what does it do with an invalid font request? The

browser’s choice of fallback font, as well as its positioning

and spacing, can be quite telling.

Also, note that this behavior is also the fallback font han-

dling mechanism for when the browser is presented with a

valid font speciﬁcation for an unavailable font. Using this

technique, tests can be written to probe for the existence of

a particular font on target machines. If enough of these tests

are run, the ﬁngerprinter can derive a fairly comprehensive

list of the installed fonts on the target machine.

An example output is shown in Figure 4.

3.1.4 WebGL

webgl is our only test whose code spans more than a few

lines. As WebGL scenes go, however, this scene is almost

minimal. We create 200 polygons, approximating the hy-

perbolic paraboloid z =

−

, with −3 ≤ y ≤ 3 and

−3 ≤ x ≤ 3. Over this surface, we apply a single tex-

ture: a 512 by 512 pixel rasterized version of ISO 12233,

the ISO standard for measuring lens resolution. Designed

for measuring sharpness and resolution in electronic still-

picture cameras, this texture contains many areas with high

detail. We then add an ambient light with color (0.1, 0.1,

0.1) and a directional light of color (0.8, 0.8, 0) and direc-

http://www.google.com/webfonts

Figure 5: An example run of the webgl test

tion (2,4,9). Placing our surface at z = −10, we render this

simple tableau.

A example, rendered on OS X 10.7.3 with Chrome 18 on

a AMD Radeon HD 6490M, is shown in Figure 5.

3.1.5 Test Speed

Speed is an important characteristic for ﬁngerprints. Tests

that take minutes are categorically less useful than tests that

take seconds, especially if they are deployed to protect online

accounts (imagine waiting even twenty seconds to log into

your webmail!). In our case, each test takes a mere fraction

of a second to run — indeed, the longest delays occur while

fetching the image assets. Consisting of a 76 KiB PNG

image and a 24 KiB WOFF font, these fetches would not

be out of place during any page load on today’s web. For

comparison, once it has loaded, the Quake 3 WebGL Demo

runs at 60 FPS with around 15% CPU utilization in Chrome

18 with a 2 GHz Core i7 and an AMD Radeon HD 6490M.

There is room for a substantial number of <canvas>-based

ﬁngerprints to run before adversely aﬀecting user experience.

3.2 Infrastructure

In general, web designers can depend on their sites ren-

dering in a consistent manner across various browsers and

operating systems. Therefore, we expected that any ﬁnger-

printable diﬀerences will be subtle, perhaps not even visible

to a human observer.

To view these trace diﬀerences, we built a small webapp

which can administer the tests and examine their results.

Experiments are served as pure JavaScript, and results are

collected as data URL-encoded PNGs. Our framework then

compares these results as images, allowing it to group iden-

tical results and display pixel-level diﬀerences between these

groups.

We use two types of image comparison: pixel-level dif-

ference and diﬀerence maps. When constructing a pixel-

level diﬀerence, the framework ﬁrst creates a new image of

the appropriate size. Then, each pixel’s color is set to the

channel-wise diﬀerence between the two images at that lo-

cation. If this color is anything other than transparent pure

black (which indicates that there is no diﬀerence between

the two images at this pixel), we set the alpha value of the

diﬀering pixel to 255, rendering it fully opaque. For diﬀer-

ence maps, each pixel in the map is set to either white or

Quake 3 Demo: http://media.tojicode.com/q3bsp/

black, depending on whether the original images diﬀer. A

purely white diﬀerence map indicates identical images, while

perfectly black indicates diﬀerence in every pixel.

Unfortunately, we do not have ready access to several hun-

dred distinct consumer-level computer systems. To collect

enough data to demonstrate the applicability of our ﬁnger-

prints, we turned to Amazon Mechanical Turk. We modi-

ﬁed our framework to deliver multiple tests on a single page,

along with extended instructions for the human workers on

Mechanical Turk. The next section explains our process and

results more thoroughly.

3.3 Data Collection

We collected samples from 300 distinct members of the

Mechcanical Turk marketplace, paying each a small sum

to report their graphics card and graphics driver version.

Meanwhile, our ﬁve ﬁngerprinting tests ran in the back-

ground. We also collected various metadata, such as the

browser’s user agent string and the WebGL-reported ren-

derer, vendor, and version.

In Safari, acquiring information on the user’s graphics

card and driver is trivial: simply ask the WebGL canvas

context. For example, given a WebGL context gl, calling

gl.getParameter(gl.RENDERER) on Safari 5.1.3 might re-

turn “AMD Radeon HD 6490M OpenGL Engine”, while call-

ing gl.getParameter(gl.VERSION) might return “WebGL

1.0 (2.1 ATI-7.18.11)”, which includes the version number of

the current graphics driver. Currently, however, WebGL is

disabled by default in Safari, and must be manually enabled

through the Developer menu.

In all three browsers which ship with WebGL enabled,

however, these values are redacted. For example, in Chrome

18.0.1025.39, asking for the WebGL renderer returns “We-

bKit WebGL”, while the version is “WebGL 1.0 (OpenGL

ES 2.0 Chromium)”. Firefox and Opera Next are similarly

unhelpful, returning generic statements about the version

of WebGL, without reference to the installed hardware. We

conclude that browser vendors consider hardware and driver

version to be identifying information, and any information

our ﬁngerprints extract about them can be considered a loss

of privacy.

Owing to these constraints, the user-facing portion of our

survey asked users of Chrome, Firefox, and Opera to man-

ually report their graphics card and driver. For Chrome

and Firefox, the user was instructed to copy text from the

browser pages chrome://gpu and about:support, respec-

tively. Opera does not appear to have any such mechanism

for hardware discovery, and so these users were asked to

discover the information through other means.

3.3.1 Platform Representation

Windows represents the lion’s share of user platforms,

with 276 samples. A full 226 of these are from Windows

7, with 9 Windows Vista, 40 Windows XP, and 1 Windows

8 rounding out the total. We also have 13 samples from

OS X, ranging from 10.5.8 to 10.7.3, and 11 samples from

Linux.

Chrome is overwhelmingly present in our data set, with

222 samples ranging from version 10 to 19. Firefox comprises

almost all of the rest, with 71 samples between versions 8

and 11. We also have 4 samples from Opera 9.8, 2 from

Safari 5, and 1 from Android.

These numbers do not represent the current software us-

age of the internet as a whole. We attribute this to text in

the survey, asking users to use a WebGL-enabled browser

to complete the task. Notably, since Internet Explorer does

not support WebGL, we posit that every Mechanical Turk

user using IE either skipped our survey, or returned in either

Chrome or Firefox. The overwhelming prevalence of Win-

dows 7 is also correlated with WebGL capability — users

who have up-to-date browsers might also be more likely to

have up-to-date operating systems.

3.3.2 Persistence

During the course of data collection, twenty-three distinct

users performed our survey twice. Due to our setup, we col-

lected results for text_arial, text_webfont, text_nonsense,

and webgl when they ﬁrst performed the survey. However,

for all twenty-three users, each of these tests were identical

to their later submissions. This suggests that our ﬁnger-

prints are consistent — for a given browser/OS/graphics

card platform, performing the same test will always give

identical results.

To further test this hypothesis, we ran all of our tests on 5

identically-provisioned lab computers, running Firefox 11 on

Windows XP. As expected, all ﬁve computers produced iden-

tical results on each test, providing further evidence that our

ﬁngerprints are stable across identical hardware and soft-

ware stacks. Additionally, we note that our ﬁngerprints are

unable to distinguish between users who use the exact same

hardware and software.

3.3.3 Errors

While running the experiment, six users experienced fail-

ures in the text_webfont and text_webfont_px tests, re-

turning a blank PNG instead of one containing text. Upon

investigation, we attribute these failures to a known race

condition in the WebFont Loader library. Since the race

condition is a transient error, we ignore these six samples

whenever they aﬀect our ﬁngerprint information leakage, as

including them will improve diﬀerentiation.

3.3.4 Data Quality

We treat the user’s report and user agent string as ground

truth. While examining the data, we saw no evidence of

any forgery, either of user agent strings or graphics card

information.

Since we conducted the survey on Mechanical Turk, how-

ever, some level of imperfection is to be expected. Indeed,

twenty-four users did not submit their graphics card infor-

mation, either by copying unrelated text into the survey box

or failing to ﬁll in the box at all. In the authors’ favorite

submission, the worker simply entered “It was very nice.”

into the text ﬁeld. These unclassiﬁed samples are included

in our results, since they represent the state of a <canvas>

ﬁngerprint in the wild, with no inside information about

hardware.

4. RESULTS

The most important feature of any ﬁngerprint is diﬀeren-

tiation: if every system ﬁngerprinted performs identically,

what use is the ﬁngerprint? With this goal in mind, we now

examine the results of our tests as applied to Mechanical

Turk users.

Windows:

OS X:

Linux:

Figure 6: 13 ways to render 20px Arial

4.1 Arial Font Rendering

In general, we ﬁnd a surprising amount of diﬀerentiation

in the ways that fonts are rendered. Even Arial, a font

which is 30 years old, renders in new and interesting ways

depending on the underlying operating system and browser.

In the 300 samples collected for the text_arial test, there

are 50 distinct renderings. For text_arial_px, this number

drops to 43. This amount of diversity is astounding, show-

ing diﬀerences even between computers running the same

operating system and browser version. In Figure 6, you can

see some of the diﬀerent results that appear. Interestingly,

some of the Linux samples shown are not using Arial at all,

but are substituting an unidentiﬁed yet similar font. Font

subsitutions such as these provide an extra dimension of dis-

tinguishability between otherwise matching computers.

The largest cluster of identical renderings on text_arial

contains 172 samples, taken in versions of Chrome ranging

from 15 to 18 on Windows XP, Vista, or 7. We attribute

the size of this group to the relative popularity of this brow-

ser/OS combination in our data set. However, seven other

groups contain samples taken on this platform as well, indi-

cating that other, more hidden variables might be discover-

able in this test.

4.1.1 Classiﬁcation

While a repeatable, trivial ﬁngerprint borne out of sim-

ple text rendering is quite promising, even more information

can be derived with this test. 10 of 50 groups contain sam-

ples taken on Linux machines, while 5 contain samples from

OS X. Each of the ﬁfty groups contains samples from only a

single operating system family, implying that this ﬁngerprint

alone is suﬃcient to distinguish operating systems!

Similarly, almost every group contains samples from only a

single browser family. The single exception occurs on OS X,

where Chrome and Safari can produce identical renderings.

Otherwise, the font handling in each browser is distinctive

enough to leave a usable ﬁngerprint.

Given these results, we conclude that rendering a simple

pangram in Arial on a <canvas> is enough to leak the user’s

operating system family and (almost always) browser family.

4.1.2 Differences

Collecting text samples from such a wide variety of sources

allows us to ﬁnd slight diﬀerences among rendering engines,

which could be exploited for better and more precise ﬁnger-

prints. In Figure 7, we present the original rendering for

the 172-member Windows/Chrome group, along with sev-

eral diﬀerence maps. The most obvious diﬀerence occurs

across platforms, where we see a marked diﬀerence in the

kerning of the text, leading to the text rendering at two

diﬀerent lengths. For samples on the same platform, the

diﬀerence map shows the outline of each letter, indicating

that antialiasing or subpixel hinting (such as ClearType)

was used. From this, a ﬁngerprinter might be able to de-

duce information regarding the user’s display or ClearType

settings. Finally, the most interesting diﬀerence map comes

from a single sample, claiming to be Chrome 17.0.963.56 on

Windows 8. Here, we see only a few pixels’ diﬀerence, lo-

cated solely near round edges, indicating subtle diﬀerences

in the font rendering engine in this system. Such diﬀerences

might be found in currently deployed systems by using other

fonts and glyphs, rendering this sort of ﬁngerprint even more

potent.

More generally, our technique is capable enough to ﬂush

out any diﬀerences between two font handling stacks. Dur-

ing our experiments, we observed that at least operating

system, browser version, graphics card, installed fonts, sub-

pixel hinting, and antialiasing all play a part in generating

the ﬁnal user-visible bitmap. Additionally, our ﬁngerprint

can recognize the impact of any other variables that impact

font rendering, such as the exact placement of pixels on a

physical LCD screen (which ClearType might take into ac-

count). More data and better platform characteriziation is

necessary for identiﬁcation and individual classiﬁcation of

these more subtle variables.

Lastly, in both Figure 7 and Figure 6, there is a surpsris-

ing amount of diversity in the length of rendered text. This

suggests an even simpler ﬁngerprinting mechanism: create

specially crafted sentences as DOM elements and measure

their length via JavaScript. When implemented as a proof-

of-concept, this technique shows a measurable and repeat-

able diﬀerence in the length of text between Firefox 10 and

Chrome 18 on OSX. This simpler ﬁngerprint should reveal

a strict subset of the information that our <canvas>-based

text rendering does, but does so using far simpler methods

(and thus will be much more diﬃcult to defend against).

4.1.3 Entropy

Fingerprints are useful only inasmuch as they diﬀerenti-

ate users. Since our ﬁngerprints reveal diﬀerences in hard-

ware and software stacks, popular hardware conﬁgurations

reduce the identifying power of the tests. Conversely, how-

ever, some setups might produce unique results, identifying

their user precisely. To estimate the tests’ overall eﬀective-

ness, we will compute the distribution entropy of our group-

ings. This metric indicates how many predictive bits the

test reveals, or, more precisely, the diﬀerential loss of user

Original Image:

Linux:

OSX:

Windows (XP, Vista, 7):

Windows 8:

Figure 7: Diﬀerence maps for a group on text_arial

privacy resulting from the test. However, since we do not

believe that the hardware and software in our 300 samples

is a representative sample of the internet as a whole, these

metrics should be treated as rough guidelines at best.

To measure distribution entropy, we use the formula

E = −

i=1

p(x

)log

p(x

)

where p(x

) is the size of the ith group divided by the number

of samples. text_arial, across 50 groups, shows a distribu-

tion entropy of 3.05 bits. text_arial_px, having only 43

distinct groups, reveals 2.86 bits. We note that these num-

bers do not represent the true entropy of these tests, as we

do not have enough data to accurately model the distribu-

tion of platforms in the wild.

4.2 WebFont Rendering

Using WebFonts allows us to standardize the font under

test. Unlike in the Arial tests, where slight diﬀerences in

the installed font could conceivably exist, any diﬀerences in

the WebFont test must be a direct consequence of the font

engine used to render the text.

In general, text_webfont shows a similar distribution to

the Arial tests. From the 294 properly completed tests, there

are 45 distinct ways to render our sample sentence. 10 of

these are presented in Figure 8. As in the Arial tests, each

group consists of a single OS family/browser family pair,

with the sole exception of Safari and Chrome on OS X,

lending further evidence that text rendering can uniquely

identify platform details.

Interestingly, as is visible in the last Windows sample,

some clients did not use Sirin Stencil at all; rather, they

substituted in a font of their own. In our data, we found

ﬁve of these samples: four (Chrome 16 and 17, Firefox 10

and 11) using Times New Roman, the ﬁfth (Opera 9.8) using

what appears to be Arial. Samples containing the correct

webfont exist for each of these browsers, so we must assume

that these ﬁve users have disabled WebFonts for security

reasons, or that there was an error loading the font. If the

Windows:

OS X:

Linux:

Figure 8: 10 ways to render 12pt Sirin Stencil

Figure 9: Sirin Stencil

former, these users may be doing themselves a disservice:

their browsers stand out quite strongly in our ﬁngerprints.

Indeed, three of these samples are unique, with only the

Chrome pair sending identical results.

text_webfont_px shows almost identical results, with 44

groups from 294 samples. Therefore, we shall focus only on

text_webfont from now on.

As in our Arial tests, the largest group consists solely of

Chrome on Windows, with 164 identical samples. Oddly, the

Windows 8 sample appears in this group, along with many

of the samples from the large Arial group. This suggests

that the font handling in Windows 8 has not been entirely

changed, and similar subtle diﬀerences might exist in other,

currently indistinguishable font engines.

Another interesting render is shown in Figure 9. 13 sep-

arate users submitted this result, each using Chrome (17,

18) on Windows (XP, Vista, 7). After being surprised at

the relative poor quality of this text, we were able to re-

produce it exactly by disabling the option “Smooth edges of

screen fonts” in the Windows 7 Performance Options prefer-

ences, which disables Microsoft’s ClearType subpixel hint-

ing, as well as any antialiasing on fonts system-wide. Our

text_webfont test, therefore, leaks this setting to an online

ﬁngerprinter, and this leakage suggests that other ClearType

conﬁguration might be detectable as well. For example, if

ClearType performs diﬀerently with distinct screen DPIs or

LCD pixel layouts, these subtle diﬀerences will reveal them-

selves to this very simple ﬁngerprinting technique, leaking

even more information about the user’s hardware.

4.2.1 Entropy

text_webfont, with 294 samples in 44 groups, shows a dis-

tribution entropy of 2.93 bits. text_webfont_px is similar,

at 2.95 bits.

4.3 WebGL

When we ﬁrst started this project, we predicted that we

would need to try quite a few underhanded tricks in order

to see diﬀerences between graphics cards. Surprisingly, this

is not the case. Our experiments show that graphics cards

leave a detectable ﬁngerprint while rendering even the sim-

plest scenes.

As described in Section 3.1.4, our WebGL test creates a

single surface, comprised of 200 polygons. It applies a sin-

gle black and white texture to this surface, and uses simple

ambient and directional lights. We also enable antialiasing.

Of the 300 users who participated in our study, 30 sub-

mitted no data for this test. In our framework, this absence

indicates either that WebGL is disabled or that an error

occurred during the test.

Under visual inspection, the 270 remaining images appear

identical. When examined at the level of individual pixels,

however, we discovered 50 distinct renders of the scene.

This level of heterogeneity is, frankly, quite surprising.

Our scene is rendered with basic matrix operations, and

we expected far more consistency among graphics cards.

One possible explanation suggests that graphics cards, in

the name of eﬃciency, cut corners with respect to graph-

ics processing. Perhaps renders are nondeterministic, but in

such minor ways as to be undetectable for humans.

Looking at the subset of our data in Table 1, we see that

this is not the case: most graphics cards produce pixel-

perfect output as compared to others of their model. There

is also a resemblance among the members of the same line

(note groups 1, 5, and 24), suggesting that graphics card

manufacturers perhaps share hardware or driver implemen-

tations between coexisting and evolving product lines.

The graphics cards, browsers, and operating systems present

in all 51 groups can be found in Appendix A.

4.3.1 Classiﬁcation

Of course, simply knowing that two implementations diﬀer

is useful, but understanding how might give clues as to why.

In Figure 10, we see the original image for group 24, our

largest, as well as its diﬀerence maps against several other

renders.

Examining these in detail, there are several diﬀerent ways

in which these groups diﬀer. In the group 1 and group 36 dif-

ference maps, we see that most of the diﬀerence is located at

the edges of color regions and polygons. This suggests that

these graphics cards are performing antialiasing slightly dif-

ferently, or perhaps simply linearly interpolating textures in

almost imperceptably diﬀerent ways. In contast, we see that

the renderers in Group 20 produced slightly diﬀerent colors

when lighting the white portions of the texture, as compared

to group 24. However, group 23 diﬀers at almost every single

non-background pixel. The two renders are visually indistin-

guishable, suggesting that the diﬀerences occur in the very

least signiﬁcant bits of each color.

The most interesting diﬀerence, however, appears between

group 24 and group 25. These renders diﬀer by only a

few pixels! Indeed, the hardware used to produce these

images is extremely similar: group 24 consists mainly of

Intel G41 (device ID 0x2e32), Intel HD Graphics (device

IDs 0x0042, 0x0046, 0x0df1), and Mobile Intel 4 Series (de-

vice ID 0x2a42), while group 25 consists solely of Intel HD

Graphics systems (device IDs 0x0102 and 0x0116). If we

assume that distinct device ID numbers indicate distinct

products, these few pixels strongly suggest that even ex-

tremely similar graphics systems can be diﬀerentiated sim-

ply through rendering the right images!

Also, it is worth noting that out of 50 total groups, 49 con-

tain samples from a single operating system family. Group

42 (in 1 is the only exception, containing both Linux and

OS X. However, given the relative lack of samples from

Linux and OS X, we cannot determine whether this delin-

eation is due to signiﬁcant diﬀerences in each operating sys-

tem’s graphics handling, or whether we simply do not have

enough samples comparing identical graphics cards across

diverse software stacks.

4.3.2 Entropy

Due to the large number of unique graphics cards and

their consistent eﬀects, webgl gives a distribution entropy of

4.30 bits, over 300 samples in 51 groups. Again, the actual

entropy revealed by this test depends upon the frequency of

each graphics card as deployed in the wild, which we can not

extrapolate from our data. Therefore, this entropy should

be considered a rough estimate, at best.

4.4 Comprehensive Fingerprinting

Given the relative success of each individual test, we shall

now examine their eﬃcacy when combined. If their predic-

tive power lies solely in browser and operating system family,

we will expect a relatively similar number of distinct groups

once all ﬁngerprints are combined. With this approach, each

group consists of samples for which all six tests are identical.

Among the 294 samples which successfully completed all

six tests, there are 116 distinct groups. The largest of these

contains 51 samples, and consists almost solely of Chrome

17.0.963.56 on Windows 7, with a single Windows Vista

mixed in. As for graphics cards, it contains Intel G41 Ex-

press Chipsets (DID 0x2e32), Intel Graphics Media Acceler-

ator HD 0x0046), Intel HD Graphics (DID 0x0042, 0x0046,

0x0df1), Intel 4 Series (DID 0x2a42), and Intel 45 Express

(DID 0x2a42). As mentioned in Section 4.3.1, further and

more sophisticated WebGL ﬁngerprints may be able to dif-

ferentiate these graphics systems.

4.4.1 Entropy

Overall, our ﬁngerprints do combine beneﬁcially: among

the 116 groups, our ﬁve extremely simple tests show a dis-

tribution entropy of 5.73 bits. We believe that more spe-

cialized and targeted tests could reveal even more, perhaps

down to the exact installed graphics card, operating system,

and browser family.

5. DEFENSES

In this section, we propose several methods of preventing

<canvas>-based ﬁngerprinting and consider their impact.

First, browser vendors could completely disable canvas

pixel extraction. While obviously preventing any poten-

tial <canvas>-based ﬁngerprinting, this ﬁx removes a use-

ful capability of the platform — imagine building a webapp

for photo editing or drawing. Therefore, let us only con-

sider defends that do not overly undermine the potential of

<canvas>.

One might imagine a defense whereby the browser adds

random pixel noise whenever pixels are extracted. Under

this regime, directly comparing image results becomes far

more diﬃcult. However, slight noise can be easily circum-

Table 1: Selected groupings of identical webgl renders. Each group corresponds to a single pixmap.

Group # Graphics Cards Browsers OS

1 3 ATI Mobility Radeon HD 4250 (Device 9712) Chrome 17 Windows 7

1 ATI Radeon HD 2400 Pro (Device 94c1) Chrome 17 Windows 7

1 ATI Radeon HD 2600 Pro (Device 9589) Chrome 17 Windows 7

3 ATI Radeon HD 3200 Graphics (Device 9612) Chrome 17 Windows 7

1 ATI Radeon HD 3800 Series (Device 9505) Chrome 19 Windows 7

2 ATI Radeon HD 4200 (Device 9710) Chrome 17 Windows 7

5 1 ATI Mobility Radeon HD 4300 Series (Device 9552) Chrome 17 Windows 7

1 ATI Mobility Radeon HD 4330 (Device 9552) Chrome 17 Windows 7

1 ATI Mobility Radeon HD 4530 (Device 9553) Chrome 17 Windows 7

1 ATI Mobility Radeon HD 4670 (Device 9488) Chrome 17 Windows 7

1 ATI Mobility Radeon HD 545v (Device 9553) Chrome 17 Windows 7

1 ATI Mobility Radeon HD 550v (Device 9480) Chrome 17 Windows 7

1 ATI Radeon HD 4350 (Device 954f) Chrome 17 Windows 7

1 ATI Radeon HD 4550 (Device 9540) Chrome 17 Windows 7

20 7 Intel(R) 82945G Express Chipset Family (Device 2772) Chrome 17 Windows 7

1 Intel(R) 82945G Express Chipset Family (Device 2772) Chrome 17 Windows Vista

1 Intel(R) 82945G Express Chipset Family (Device 2772) Chrome 18 Windows 7

1 Intel(R) 82945G Express Chipset Family (Device 2772) Firefox 10 Windows XP

1 Intel(R) 82945G Express Chipset Family (Device 2772) Firefox 8 Windows 7

1 Intel(R) HD Graphics Family (Device 0102) Firefox 10 Windows 7

2 Mobile Intel(R) 945 Express Chipset Family (Device 27a2) Chrome 17 Windows 7

23 1 Intel(R) G33/G31 Express Chipset Family (Device 29c2) Firefox 10 Windows 7

24 1 Intel(R) G41 Express Chipset (Device 2e32) Chrome 15 Windows 7

7 Intel(R) G41 Express Chipset (Device 2e32) Chrome 17 Windows 7

2 Intel(R) G41 Express Chipset (Device 2e32) Chrome 19 Windows 7

1 Intel(R) Graphics Media Accelerator HD (Device 0046) Chrome 17 Windows 7

1 Intel(R) HD Graphics (Device 0042) Chrome 15 Windows 7

1 Intel(R) HD Graphics (Device 0042) Chrome 16 Windows 7

2 Intel(R) HD Graphics (Device 0042) Chrome 17 Windows 7

1 Intel(R) HD Graphics (Device 0042) Firefox 10 Windows 7

2 Intel(R) HD Graphics (Device 0046) Chrome 16 Windows 7

23 Intel(R) HD Graphics (Device 0046) Chrome 17 Windows 7

1 Intel(R) HD Graphics (Device 0046) Chrome 17 Windows 8

5 Intel(R) HD Graphics (Device 0046) Firefox 10 Windows 7

1 Intel(R) HD Graphics (Device 0046) Firefox 10 Windows XP

1 Intel(R) HD Graphics (Device 0046) Firefox 11 Windows 7

2 Intel(R) HD Graphics (Device 0046) Firefox 9 Windows 7

3 Intel(R) HD Graphics (Device 0df1) Chrome 17 Windows 7

1 Intel(R) HD Graphics (Device 0df1) Chrome 19 Windows 7

2 Mobile Intel(R) 4 Series Express Chipset Family (Device 2a42) Chrome 16 Windows 7

9 Mobile Intel(R) 4 Series Express Chipset Family (Device 2a42) Chrome 17 Windows 7

1 Mobile Intel(R) 4 Series Express Chipset Family (Device 2a42) Chrome 17 Windows Vista

1 Mobile Intel(R) 4 Series Express Chipset Family (Device 2a42) Firefox 10 Windows 7

1 Mobile Intel(R) 4 Series Express Chipset Family (Device 2a42) Firefox 10 Windows XP

7 Mobile Intel(R) 45 Express Chipset Family (Device 2a42) Chrome 17 Windows 7

1 Mobile Intel(R) 45 Express Chipset Family (Device 2a42) Chrome 18 Windows 7

1 UNKNOWN Chrome 17 Windows 7

1 UNKNOWN Chrome 17 Windows Vista

1 UNKNOWN Chrome 18 Windows 7

25 1 Intel(R) HD Graphics Family (Device 0102) Firefox 10 Windows XP

1 Intel(R) HD Graphics Family (Device 0116) Firefox 8 Windows 7

3 Intel(R) HD Graphics Family (Device 0116) Firefox 9 Windows 7

36 1 NVIDIA GeForce 6150SE nForce 430 (Device 03d0) Chrome 17 Windows 7

1 NVIDIA GeForce 6200 (Device 0221) Firefox 10 Windows XP

1 NVIDIA GeForce 7100 / NVIDIA nForce 630i (Device 07e1) Firefox 10 Windows 7

1 NVIDIA GeForce 7150M / nForce 630M (Device 0531) Chrome 17 Windows 7

1 NVIDIA GeForce 7300 SE/7200 GS (Device 01d3) Chrome 17 Windows 7

1 UNKNOWN Chrome 15 Windows XP

42 1 NVIDIA GeForce 8600 Chrome 17 Linux

1 NVIDIA GeForce 9400 Chrome 17 OSX 10.7.3

1 NVIDIA GeForce 9800 Chrome 17 Linux

1 NVIDIA GeForce 320M (Device 08a0) Firefox 10 OSX 10.6

(a) Original

(Intel G41)

(b) Group 1

(Radeon HD 2400)

(Intel 82945G)

(d) Group 23

(Intel G33/G31)

(e) Group 25

(Intel HD Graphics)

(f) Group 36

(GeForce 6200)

Figure 10: Original render and diﬀerence maps for Group 24

vented: simply repeat the test a few times and compare the

results (perhaps by averaging or selecting the most common

pixel color). While increasing the noise combats this, it also

degrades the performance of <canvas> signiﬁcantly for le-

gitimate applications. Applying the same noise on multiple

runs would only aid in ﬁngerprinting. Therefore, we con-

clude that adding noise is not a feasible defense against our

ﬁngerprinting methods.

Thinking further, we note that our ﬁngerprints measure

functional diﬀerences in both the hardware and software

running on the device. A sure-ﬁre way to defend against

leaking this information, then, is for every system to pro-

duce identical results. To do so, browser vendors will need to

agree on a list of “<canvas>-safe” fonts, and then ship these

fonts, along with text rendering libraries such as Pango, as

a supplement to the browser. To support WebGL, browsers

would ignore the graphics card entirely and render scenes in

a generic software renderer such as Mesa 3D. While this ap-

proach might be acceptable where privacy is of the utmost

importance, the performance impact would be unacceptable

in a shipping browser. Note that performing this emulation

is a signal in and of itself, revealing that the user is taking

precautions to be anonymous.

The easiest eﬀective defense, then, is to simply require

user approval whenever a script requests pixel data. Modern

browsers already implement this type of security — for ex-

ample, user approval is required for the HTML5 geolocation

APIs. This approach continues the existing functionality of

<canvas> while disallowing illegitimate uses, at the cost of

yet another user-facing permissions dialog.

More complicated defense schemes can certainly be imag-

ined. Imagine, perhaps, a <canvas> implementation that

uses hardware acceleration to produce the pixels displayed

to the user, but regenerates the entire image with an emu-

lated implementation whenever the site requests pixel data.

Such complicated schemes might sucessfully defend against

a <canvas> ﬁngerprint, but add signiﬁcant complexity to

HTML5 APIs and behavior.

6. CONCLUSIONS

We have demonstrated that the behavior of <canvas> text

and WebGL scene rendering on modern browsers forms a

new system ﬁngerprint. The new ﬁngerprint is consistent,

high-entropy, orthogonal to other ﬁngerprints, transparent

to the user, and readily obtainable.

We believe that such ﬁngerprints are inherent when the

browser is — for performance and consistency — tied closely

to operating system functionality and system hardware.

We do not yet have the data necessary to estimate the

entropy of our ﬁngerprint over the entire population of the

web, but given our preliminary ﬁndings, 10 bits is a (possi-

bly very) conservative estimate. Indeed, Benoit Jacob has

estimated the entropy of just the GPU model at 9 bits [10].

We were surprised at the amount of variability we ob-

served in even very simple tests, such as rendering a sen-

tence in 12-point Arial. We conjecture that it is possible to

distinguish even systems for which we obtained identical ﬁn-

gerprints, by rendering complicated scenes that come closer

to stressing the underlying hardware. Note that an attacker

could reﬁne a ﬁngerprint in a black-box way by having some

victims render experimental scenes in addition to the ones

used for ﬁngerprinting. Those scenes that allow otherwise

identical systems to be distinguished should be added to the

ﬁngerprint.

We are pessimistic about the possibility of eliminating the

ﬁngerprints we identiﬁed without seriously degrading brow-

ser functionality and performance, or require yet more user

approval dialogs to enable basic functionality. Perhaps the

time has come to acknowledge that ﬁngerprints are unavoid-

able on the modern web.

For browsers speciﬁcally designed to limit the ability of

attackers to ﬁngerprint users, such as Tor’s modiﬁed Firefox

with Torbutton [15], more drastic steps may be necessary.

Torbutton already disables WebGL, and it likely should dis-

able GPU-based compositing and 2D canvas acceleration.

But even this step does not address the ﬁngerprint obtained

through font rendering. It may be necessary for Tor’s Fire-

fox to eschew the system font-rendering stack, and instead

implement its own — based, for example, on GTK+’s Pango

library.

Acknowledgments

We are grateful to

Ulfar Erlingsson, Eric Rescorla, Stefan

Savage, and Geoﬀ Voelker for helpful discussions about this

work. This material is based upon work supported by the

National Science Foundation under Grants No. CNS-0831532

and CNS-0964702, and by the MURI program under AFOSR

Grant No. FA9550-08-1-0352.

WebGL could perhaps be implemented in software. As an

example, Chrome 17 falls back on a software GL backend on

systems without a supported GPU.

Table 2: Groups of identical webgl renders. Number in parentheses indicate device IDs, where appropriate.

# Size Graphics Cards Browsers OS

1 11 ATI Mobility Radeon HD 4250; ATI Radeon HD 2400 Pro, 2600 Pro, 3200, 3800, 4200 Chrome (17, 19) Windows 7

2 8 AMD Radeon HD 6250, 6300, 6310, 6670, 6800; ATI Radeon HD 5450, 5670 Chrome (17, 18) Windows 7

3 4 AMD Radeon HD 6250; Mobility Radeon HD 5650; ATI Radeon HD 5670; Unknown Firefox (9) Windows 7

4 1 ATI HD 5850 Opera (9.8) Windows 7

5 8 ATI Mobility Radeon HD 4300, 4330, 4530, 4670, 545v, 550v; ATI Radeon HD 4350,

4500

Chrome (17) Windows 7

6 9 ATI Mobility Radeon HD 5470, 5730, 5700 Series; Intel HD Graphics (0116) Chrome (17) Windows 7

7 1 ATI Radeon 2100 Chrome (17) Windows 7

8 1 ATI Radeon HD 2600 Pro Chrome (17) OS X 10.6.8

9 1 ATI Radeon HD 4300/4500 Series (954f) Firefox (8) Windows 7

10 4 ATI Radeon HD 5700 Series (68be), 5800 Series (6899); Unknown Firefox (10, 11) Windows 7

11 1 ATI Radeon HD 6750M Firefox (10) OS X 10.7

12 1 Unknown Android 2.3.4 Android

13 1 Intel GMA 950 Chrome (18) OS X 10.7.3

14 1 Intel GMA X3100 Chrome (17) OS X 10.5.8

15 1 Intel GMA 950 Firefox (10) OS X 10.6

16 1 Intel HD Graphics 3000 Firefox (10) OS X 10.7

17 1 Intel HD Graphics 3000 Firefox (12) OS X 10.7

18 3 Intel 946GZ Express Chipset (2972), Mobile Intel 956 Express Chipset (2a02) Chrome (10, 17);

Firefox (10)

Windows (7, XP)

19 5 Intel 82845G (2562), G41 Express Chipset (2e32), 945GM/GU Express Chipset (27a2);

Unknown

Chrome (18) Windows XP

7. REFERENCES

[1] Cve-2010-3855. Online:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=

CVE-2010-3855, Dec. 2011.

[2] Microsoft security bulletin ms11-087. Online:

http://technet.microsoft.com/en-us/security/

bulletin/ms11-087, Dec. 2011.

[3] G. Aggarwal, E. Bursztein, C. Jackson, and D. Boneh.

An analysis of private browsing modes in modern

browsers. In I. Goldberg, editor, Proceedings of

USENIX Security 2010, pages 79–93. USENIX, Aug.

2010.

[4] S. Baker. Re: [public WebGL] about the VENDOR,

RENDERER, and VERSION strings. Public WebGL

mailing list, Nov. 2010.

https:

//www.khronos.org/webgl/public-mailing-list/

archives/1011/msg00221.html.

[5] K. Boda,

A. M. F

oldes, G. G. Guly´as, and S. Imre.

User tracking on the Web via cross-browser

ﬁngerprinting. In P. Laud, editor, Proceedings of

NordSec 2011, LNCS. Springer-Verlag, Oct. 2011.

[6] R. Dingledine and N. Mathewson. Tor: The

second-generation onion router. In M. Blaze, editor,

Proceedings of USENIX Security 2004, pages 303–19.

USENIX, Aug. 2004.

[7] P. Eckersley. How unique is your Web browser? In

M. Atallah and N. Hopper, editors, Proceedings of

PETS 2010, volume 6205 of LNCS, pages 1–18.

Springer-Verlag, July 2010.

[8] G. Fleischer. Attacking Tor at the application layer.

Presentation at DEFCON 2009, Aug. 2009. Online:

http://pseudo-flaw.net/content/defcon/.

[9] J. Forshaw. Webgl - a new dimension for browser

exploitation. Online:

http://www.contextis.com/resources/blog/webgl/,

May 2011.

[10] B. Jacob. Re: [public WebGL] about the VENDOR,

RENDERER, and VERSION strings. Public WebGL

mailing list, Nov. 2010.

https:

//www.khronos.org/webgl/public-mailing-list/

archives/1011/msg00229.html.

[11] B. Jacob. Re: [public WebGL] information leakage

and the extension regisrty. Public WebGL mailing list,

Dec. 2010.

http:

//www.khronos.org/webgl/public-mailing-list/

archives/1012/msg00083.html.

[12] A. Juels, M. Jakobsson, and T. N. Jagatic. Cache

cookies for browser authentication (extended

abstract). In V. Paxson and B. Pﬁtzmann, editors,

Proceedings of IEEE Security and Privacy (“Oakland”)

2006, pages 301–05. IEEE Computer Society, May

2006.

[13] J. R. Mayer. “Any person. . . a pamphleteer”: Internet

anonymity in the age of Web 2.0. Senior thesis,

Princeton University, Apr. 2009.

[14] K. Mowery, D. Bogenreif, S. Yilek, and H. Shacham.

Fingerprinting information in JavaScript

implementations. In H. Wang, editor, Proceedings of

W2SP 2011. IEEE Computer Society, May 2011.

[15] M. Perry. Torbutton design documentation, June

2010. Online: http://www.torproject.org/

torbutton/en/design/index.html.en.

[16] P. Reschl, M. Mulazzani, M. Huber, and E. Weippl.

Poster abstract: Eﬃcient browser identiﬁcation with

JavaScript engine ﬁngerprinting. In Poster Session of

ACSAC 2011, Dec. 2011. Online:

http://www.acsac.org/2011/program/posters/

Reschl.pdf.

APPENDIX

A. DATA CHARACTERIZATION

Table 2: Groups of identical webgl renders (cont.)

# Size Graphics Cards Browsers OS

20 14 Intel 82945G Express Chipset (2772); Intel HD Graphics (0102); Mobile

Intel 945 Express Chipset (27a2)

Chrome (17, 18);

Firefox (8, 10)

Windows (7, Vista,

XP)

21 2 Intel 82945G Express Chipset (2772) Firefox (8, 10) Windows (XP)

22 24 Intel G33/G31 Express Chipset (29c2); Intel Graphics Media Accelera-

tor 3150 (a011); Unknown

Chrome (13, 17, 18);

Firefox (8, 9, 10, 11)

Windows 7

23 1 Intel G33/G31 Express Chipset (29c2) Firefox (10) Windows 7

24 80 Intel G41 Express Chipset (2e32); Intel Graphics Media Accelerator

HD (0046); Intel HD Graphics (0042, 0046, 0df1); Mobile Intel 4 Series

(2a42); Mobile Intel 45 Series (0x2a42); Unknown

Chrome (15-19);

Firefox (9, 10, 11)

Windows (7, 8,

Vista, XP)

25 5 Intel HD Graphics (0102, 0116) Firefox (8, 9, 10) Windows (7, XP)

26 13 Intel HD Graphics (0102, 0116); Unknown Chrome (16, 17);

Firefox (10, 11)

Windows 7

27 1 Mesa DRI Intel Ironlake Desktop Chrome (17) Linux

28 10 Mobile Intel 965 Express Chipset (2a02, 2a12); Intel GMA X3100 (2a02) Chrome (14, 17, 18);

Firefox (8, 9, 10)

Windows (7, XP)

29 1 NVIDIA GeForce 7025 Firefox (10) Linux

30 1 NVIDIA GeForce 9400M Firefox (10) OS X 10.6

31 19 NVIDIA GeForce 210, 315M, 8400GS, 8500 GT, 8600M GT, 9200M GS,

9500 GT, 9600 GT, 9600M GT, G 105M, G 210M, GTS 250, GTS 360M,

GTX 295

Chrome (13, 17);

Firefox (10)

Windows (7, Vista)

32 2 NVIDIA GeForce 315M; Unknown Firefox (5, 6) Windows 7

33 1 NVIDIA GeForce 320M Safari (5) OS X 10.7.3

34 6 NVIDIA GeForce 410M, GT 425M, GTX 460, GTX 460 SE Chrome (17);

Firefox (10)

Windows (7, XP)

35 1 NVIDIA GeForce GTX 550 Chrome (17) Linux

36 6 NVIDIA GeForce 6150SE, 6200, 7100, 7150M, 7300 SE/7200GS; Un-

known

Chrome (15, 17);

Firefox (10)

Windows (7, XP)

37 1 NVIDIA GeForce 6200 Firefox (4) Windows 7

38 1 NVIDIA GeForce 6800 Series (00f9) Firefox (10) Windows 7

39 1 NVIDIA GeForce 7025 Chrome (18) Windows XP

40 1 NVIDIA GeForce 7300SE/7200GS Firefox (10) Windows 7

41 1 NVIDIA GeForce 7650 GS Chrome (17) Windows 7

42 4 NVIDIA GeForce 8600, 9800, 320M, 9400 Chrome (17);

Firefox (10)

Linux;

OS X (10.6, 10.7.3)

43 4 NVIDIA GeForce 8400 GS, 9500 GT, Quadro FX 1800M; Unknown Chrome (15, 17, 19);

Firefox (13)

Windows 7

44 1 NVIDIA GeForce GT 220 Firefox (10) Windows 7

45 1 NVIDIA GeForce GT 330M Chrome (19) OS X 10.7.3

46 1 NVIDIA GeForce GT 440 Opera (9.80) Windows 7

47 1 Intel 965GM Firefox (8) Linux

48 1 Intel 965GM Firefox (10) Linux

49 1 Mesa DRI Intel Ironlake Mobile Firefox (10) Linux

50 1 Mesa DRI Intel Sandybridge Mobile Firefox (10) Linux

WebGL

30 AMD Radeon HD 6670, 7450M; ATI Radeon HD 3200, X1200, X1900,

XPRESS 200; Intel GMA 3100; Intel 82865G; Intel G41; Intel HD

Graphics; NVIDIA GeForce 315M, 6150SE, 6200, FX 5500; NVIDIA

Quadro 6000; VIA Integrated; Unknown

Chrome (15, 16, 17);

Opera (9.80);

Safari (5)

Linux;

OSX (10.6.8);

Windows

(7, Vista, XP)