Web Browser History Detection as a Real-World
Privacy Threat
Artur Janc1 and Lukasz Olejnik2
artur@lingro.com,
lukasz.olejnik@man.poznan.pl

Abstract. Web browser history detection using CSS visited styles haslong been dismissed as an issue of marginal impact. However, due torecent changes in Web usage patterns, coupled with browser performance improvements, the long-standing issue has now become a signiﬁcant threat to the privacy of Internet users.
In this paper we analyze the impact of CSS-based history detection
and demonstrate the feasibility of conducting practical attacks with minimal resources. We analyze Web browser behavior and detectability ofcontent loaded via standard protocols and with various HTTP response
codes. We develop an algorithm for eﬃcient examination of large linksets and evaluate its performance in modern browsers. Compared to existing methods our approach is up to 6 times faster, and is able to detect
up to 30,000 visited links per second.
We present a novel Web application capable of eﬀectively detecting
clients’ browsing histories and discuss real-world results obtained from271,576 Internet users. Our results indicate that at least 76% of Internet
users are vulnerable to history detection, including over 94% of Google
Chrome users; for a test of most popular Internet websites we were able todetect, on average, 62.6 (median 22) visited locations per client. We also
demonstrate the potential to proﬁle users based on social news stories
they visited, and to detect private data such as zipcodes or search queries
typed into online forms.

1

Introduction

Web browsers function as generic platforms for application delivery and provide
various usability enhancements with implications for user privacy. One of theearliest such usability improvements was the ability to style links to Web pages
visited by the user diﬀerently from unvisited links, introduced by the original
version of the Cascading Style Sheets standard [1] and quickly adopted by all
major Web browsers. This mechanism was soon demonstrated to allow malicious
Web authors to detect links a client has visited and report them to the attacker[2].
Since then, a body of academic work has been published on this topic, describing history detection methods [3] and discussing the potential to detect visited
websites to aid in phishing [4]. Several countermeasures against such attacks
D. Gritzalis, B. Preneel, and M. Theoharidou (Eds.): ESORICS 2010, LNCS 6345, pp. 215–231, 2010.
c Springer-Verlag Berlin Heidelberg 2010


216

A. Janc and L. Olejnik

were proposed, including client-side approaches through browser extensions [5]and server-side solutions on a per-application basis [6], but such methods havenot been adopted by browser vendors or Web application developers. Simultaneously, several demonstration sites have been created to show the ability to detectknown popular websites, including Web 2.0 applications [7].
More recently, CSS-based history detection started to become applied as a
powerful component of privacy research, including work to determine the amountof user-speciﬁc information obtainable by ad networks [8] and as part of a scheme
for deanonymizing social network users [9]. However, there has been a notablelack of work examining several crucial aspects of history detection, including thetypes of browser-supported protocols and resource types which can be detected,
performance considerations, and the number of users aﬀected by such attacks.
In this paper, we provide a detailed examination of CSS-based history detection techniques and their impact on the privacy of Internet users. We provide an
overview of existing work, and discuss basic cross-browser implementations ofhistory detection using JavaScript as well as a CSS-only technique. We evaluate
the detectability of resources based on the browser-supported protocols used toretrieve them, analyze the eﬀect of loading content in frames and iframes, aswell as review the impact of HTTP redirects and other codes.
We demonstrate an optimized algorithm for detecting visited links and its
JavaScript implementation. We provide detailed performance measurements ofour technique and compare it to existing approaches. Our approach is up to 6
times faster than known methods, and allows for the examination of up to 30,000
links per second on modern hardware. We also provide the ﬁrst performance
analysis of the CSS-only history detection technique, demonstrating its value asan eﬃcient, though often neglected, alternative to the scripting approach.
Based on our work on a real-world testing system [10], we provide an overview
of the design of an eﬃcient history detection application capable of providing
categorized test of various website classes, and realizable with minimal resources.
We discuss approaches for the selection of links to be detected, and outline our
implemented solution based on primary links (as site entry points), secondary
resources, and enumeration elements.
Finally, we analyze history detection results obtained from 271,576 users. We
demonstrate that a large majority (76.1%) of Internet users are vulnerable tohistory detection attacks, including over 82% of Safari users and 94% of Google
Chrome users. We analyze the average number of primary and secondary links
found in a test of popular Internet locations; for vulnerable users our test found
an average of 62.6 visited links (22 median). We also provide an overview ofdetected outgoing links from social news sites and discuss the potential of oursystem to gather especially privacy-sensitive data.
Our results indicate that properly prepared history detection attacks havesigniﬁcant malicious potential and can be directed against the vast majority ofInternet users.

Web Browser History Detection as a Real-World Privacy Threat

2

217

Background

The CSS visited pseudoclass has been applied to links visited by client browsers
since the introduction of the CSS1 standard in 1996 [1]. The feature of applying
diﬀerent styles to “known” links quickly became accepted by users and wasrecommended by usability experts [11].
The ability to use the visited pseudoclass for detecting Web users’ browsing
history was ﬁrst reported to browser vendors as early as the year 2000 [2,12].
Since then, the technique has been independently rediscovered and disclosed
several times [4], and has become widely known among Web browser developers
and the security and Web standards communities. In fact, Section 5.11.2 of
the CSS 2.1 standard [13], a W3C recommendation since 1998, discusses thepotential for history detection using the visited pseudoclass, and explicitly allows
conforming User Agents to omit this functionality for privacy reasons, without
jeopardizing their compliance with the standard.
While initial discussions of CSS-based history detection were mostly conducted in on-line forums, the issue was also disclosed to the academic communityand discussed in the work of Felten et al. in conjuction with cache-based history
sniﬃng [3].
As a response, Jakobsson and Stamm discussed potential methods for implementing server-side per-application protection measures [14]; such techniques
would have to be implemented by every Web-based application and are thus anextremely unlikely solution to the problem. A viable client-side solution was a
proposed modiﬁcation to the algorithm for deciding which links are to be considered visited as described in [5] and implemented in the SafeHistory extension[15] for Mozilla Firefox. Unfortunately, no such protection measures were implemented for other Web browsers1, and the SafeHistory plugin is not available formore recent Firefox versions.
Other academic work in the area included a scheme for introducing voluntary privacy-oriented restrictions to the application of history detection[17]. Twomore recent directions were applications of history detection techniques to determine the amount of user-speciﬁc information obtainable by ad networks [8]and as part of a scheme for deanonymizing social network users [9].
CSS-based history detection was also discussed as a potential threat to Web
users’ privacy in several analyses of Web browser security [18,19].
Outside of the academic community, several demonstration sites were created
to demonstrate speciﬁc aspects of browser history detection. Existing applications include a script to guess a visitor’s gender by combining the list of detecteddomains with demographic information from [20], a visual collage of visited Web
2.0 websites [7], and an entertaining detector of adult websites [21]. However, all
known proof of concept sites focus on a single application, and do not explore
the full potential of history detection as a tool to determine user-speciﬁc private
information.
1

Since writing the original draft of this work, we have become aware of ongoing eﬀorts
to mitigate history detection attacks in the Gecko and WebKit rendering engines [16].

218

3

A. Janc and L. Olejnik

Analysis

In order to fully evaluate the implications of CSS-based history detection, it
is necessary to understand how and when Web browsers apply visited styles tolinks. In this section we analyze various browser behaviors related to visited links,
describe an eﬃcient algorithm for link detection and evaluate its performance inseveral major browsers2.
3.1

Basic Implementation

CSS-based history detection works by allowing an attacker to determine if aparticular URL has been visited by a client’s browser through applying CSS
styles distinguishing between visited and unvisited links. The entire state of theclient’s history cannot be directly retrieved; to glean history information, an
attacker must supply the client with a list of URLs to check and infer whichlinks exist in the client’s history by examining the computed CSS values on theclient-side. As noted in [12], there are two basic techniques for performing suchdetection.
The CSS-only method shown in Figure 1 allows an attacker’s server to learn
which URLs victim’s browser considers to be visited by issuing HTTP requests
for background images on elements linking to visited URLs. A similar, but less
known technique is to use the link CSS pseudoclass, which only applies if thelink speciﬁed as the element’s href attribute has not been visited; the techniques
are complementary.

< style ># foo : visited { background : url (/? yes - foo );}# bar : link { background : url (/? no - bar );}</ style ><a id = " foo " href = " http :// foo . org " > </a ><a id = " bar " href = " http :// bar . biz " > </a >Fig. 1. Basic CSS Implementation

A similar technique can be performed on the client side with JavaScript, by
dynamically querying the style of a link (<a>) element to detect if a particular
CSS style has been applied, shown in Figure 2. Any valid CSS property can beused to diﬀerentiate between visited and unvisited links. The scripting approachallows for more ﬂexibility on part of the attacker, as it enables ﬁne-grained
control over the execution of the hijacking code (e.g. allows resource-intensive
2

Browser behavior and performance results were gathered with Internet Explorer 8.0,
Mozilla Firefox 3.6, Safari 4, Chrome 4, and Opera 10.5 on Windows 7 using an Intel
Core 2 Quad Q8200 CPU with 6GB of RAM.

Web Browser History Detection as a Real-World Privacy Threat

219

tests to be run after a period of user inactivity) and can be easily obfuscated to
avoid detection by inspecting the HTML source. It can also be modiﬁed to utilize
less network resources than the CSS-only method, as discussed in Section 3.3.
Both techniques can be executed transparently to the user and do not require
any interaction other than navigating to a Web page.

<s c r i p t >var r 1 = ’ a { c o l o r : g r e e n ; } ’ ;var r 2 = ’ a : v i s i t e d { c o l o r : r e d ; } ’ ;document . s t y l e S h e e t s [ 0 ] . i n s e r t R u l e ( r1 , 0 ) ;document . s t y l e S h e e t s [ 0 ] . i n s e r t R u l e ( r2 , 1 ) ;var a e l = document . c r e a t e E l e m e n t ( ’ a ’ ) ;a e l . h r e f = ” http :// foo . org ” ;var a s t y l e = document . d e f a u l t V i e w . getComputedStyle ( a e l , ” ” ) ;i f ( a s t y l e . g e t P r o p e r t y V a l u e ( ” c o l o r ” ) == ’ r e d ’ )// l i n k was v i s i t e d</ s c r i p t >Fig. 2. Basic JavaScript Implementation

3.2

Resource Detectability

The CSS history detection technique has historically been applied almost exclusively to detect domain-level resources (such as http://example.org), retrieved
using the HTTP protocol. However, Web browsers apply the visited style toother kinds of links, including sub-domain resources such as images, stylesheets,
scripts and URLs with local anchors, if they were visited directly by the user.
In general, and with few exceptions, there exists a close correspondence between
the URLs which appeared in the browser’s address bar and those the browser
considers to be visited. Thus, visited URLs within protocols other than HTTP,
including https, ftp, and file can also be queried in all tested browsers, withthe exception of Chrome which does not apply visited styles to file:// links.
Because of the address bar rule outlined above, parameters in forms submittedwith the HTTP POST request method cannot be detected, whereas parametersfrom forms submitted using HTTP GET are susceptible to detection. The URLs
for resources downloaded indirectly, such as images embedded within an HTML
document, are usually not marked as visited. However, one exception is thehandling of frames and iframes in some browsers. A URL opened in a frame oriframe does not appear in the address bar, but the Firefox and Chrome browsers
still consider it to be visited.

220

A. Janc and L. Olejnik

While all major browsers apply visited styles to valid resources (ones returning HTTP 200 status codes), variations exist for other response types. Whenencountering an HTTP redirect code (status 301 or 302) Firefox, Chrome andOpera mark both the redirecting URL and the new URL speciﬁed in the Location HTTP header as visited, whereas Safari saves only the original URL, andInternet Explorer exhibits seemingly random behavior. When performing a meta
redirect, all browser except Internet Explorer consider both URLs to be visited;newer versions of Internet Explorer do not allow such redirects in the default
conﬁguration. When retrieving an invalid URL with a client or server error status (codes 4xx and 5xx), all browsers except Internet Explorer mark the link
as visited. The handling of various types of HTTP responses is summarized inTable 1.
The ability to detect links visited by any user depends on the existence of those
links in the browser’s history store and is aﬀected by history expiration policies.
This default value for history preservation varies between browsers, with Firefox
storing history for 90 days, Safari - 20 days, and IE - 20 days. Opera stores 1000
most recently visited URLs, whereas Chrome does not expire browsing history.
It is important to note that a potential adversary whose website is periodically
visited by the user (or whose script is linked from such a site) can query thehistory state repeatedly on each visit, maintaining a server-side list of the user’s
detected links; such an approach would allow the attacker to aggregate browsing
information, bypassing history expiration policies.
Table 1. Detectability for HTTP status codes and redirects
IE
200

3.3

yes

Firefox Safari Chrome Opera
yes

yes

yes

yes

301
random302
randommeta redirect n/a

both
both
both

original
original
both

both
both
both

both
both
both

404
500

yes
yes

yes
yes

yes
yes

yes
yes

no
no

Performance

CSS-based history detection is a viable technique for various privacy-related
attacks because of its simplicity and the ability to quickly check for a large
number of visited resources. In order to fully understand the implications of CSSbased history detection attacks, it is thus crucial to learn about its performance
characteristics using optimized scripts for each browsing environment.
Optimizing JavaScript Detection. To date, little eﬀort has been put into
the analysis of eﬃcient implementations of JavaScript-based history detection.
Several existing implementations use DOM a elements in a static HTML document to hold URLs which are later inspected to determine if the CSS visited rule

Web Browser History Detection as a Real-World Privacy Threat

221

applied to the corresponding URL, an approach signiﬁcantly slower than a fullydynamic technique. Additionally, due to browser inconsistencies in their internal
representations of computed CSS values (e.g. the color red can be internally represented as “red”, “#ﬀ0000”, “#f00”, or “rgb(255, 0, 0)“) most detection scripts
try to achieve interoperability by checking for a match among multiple of thelisted values, even if the client’s browser consistently uses one representation.
Another diﬀerence aﬀecting only certain browsers is that an a element must be
appended to an existing descendant of the document node in order for the style
to be recomputed, increasing script execution time.
For our detection code, we took the approach of creating an optimized technique for each major browser and falling back to a slower general detection
method for all other browsers. We then compared the execution time of the optimized test with the general method for each major browser. The diﬀerences in
execution times are shown in Figure 3.
For each browser the implementation varies slightly, depending on the way
CSS properties are represented internally and the available DOM mechanisms
to detect element styles. The general detection algorithm for lists of links is asfollows:
1. Initialize CSS styles and store URLs to check in a JavaScript array.
2. Detect browser version and choose appropriate detection function.
3. Invoke chosen detection function on URL array.
– Create <a> element and other required elements.
– For each URL in array:• Set <a> element href attribute to URL.
• (for some browsers) Append element to DOM or recompute styles.
• If computed style matches visited style, add URL to ”visited” array.
4. Send contents of visited array to server or store on the client-side.
Our approach has the advantage of avoiding a function call for each check,reusing DOM elements where possible, and is more amenable to optimization
by JavaScript engines due to a tight inner loop. Compared to a naive detection
approach using static <a> elements in the HTML source and less-optimized
style matching, our technique is between 1.8 and 6 times faster depending on
the browser.
CSS Performance. The CSS-only detection technique is a valuable alternative
to the scripting approach, as it allows to test clients with JavaScript disabled orones with security-enhancing plug-ins such as NoScript. Our results, provided in
Figure 4, show that CSS-based detection can perform on par with the scripting
approach, allowing an attacker to test for over 25,000 visited links per second
for small data sets of 50,000 links and fewer. An important drawback, however,is that CSS-based detection requires <a> elements with appropriate href attributes to be included in the static HTML source, increasing the page size andrequired bandwidth. Additionally, for larger link sets (HTML pages with over

222

A. Janc and L. Olejnik

JavaScript Performance
30000

Optimized
GeneralScanned links/second

25000
20000
15000
10000
5000
0
IE

FF

Safari

ChromeOpera

Fig. 3. JavaScript detection performance for diﬀerent browsers. The general approach
can be clearly seen as much slower.

50,000 elements), detection performance (and overall browser performance) decreases quickly with the increasing number of DOM elements included in the
page3 .
Network Considerations. While client-side detection eﬃciency is of the mostimportance, we observe that the overall goal of detecting visited URLs in theclient’s browsing history can require signiﬁcant network resources. Since manybrowsers on modern hardware are able to check tens of thousands of links per
second, the bandwidth necessary to sustain constant checking speed becomes
non-trivial.
In our test data set, the median URL lengths are 24 bytes for primary links(hostnames), and 60 bytes for secondary links (resources within each site). The
overhead of including a URL in a JavaScript script in our implementation was
3 bytes (for quoting and separating array elements). For CSS, the average size
overhead was 80 bytes due to the necessity of adding HTML markup and static
CSS styles. In our tests, transmitting 30,000 thousand URLs required approximately 1650 kB (170 kB with gzip compression) for JavaScript, and 3552 kB(337kB with gzip compression) for CSS tests.
For an average broadband user, available bandwidth could potentially be alimiting factor, especially for owners of modern systems which can execute thedetection code faster. To decrease the required bandwidth, transmitted links canomit common patterns (e.g. http:// or http://www.); enumerating resources
within a single domain can also signiﬁcantly reduce the required network bandwidth by only transmitting the variable URL component.
3

Test pages with more than 50 thousand elements caused errors and did not load inInternet Explorer.

Web Browser History Detection as a Real-World Privacy Threat

223

CSS Performance
50000

50k elements
75k elements
100k elements

Scanned links/second

40000

30000

20000

10000

0
IE

FF

Safari

ChromeOpera

Fig. 4. CSS detection performance. Due to the limitations of Internet Explorer, only
data for 50 thousand links is shown.

4

Methodology

A core goal of our work was to build a functional system to demonstrate thepossible privacy risks associated with browser history detection, including thedevelopment of categorized tests detecting various classes of online resources.
Our testing system was designed to maximize the number of URLs retrieved
from each visitor’s history and to present visitors with a visual representationof what can be inferred about their browsing habits.
4.1

System Overview

Our testing application was divided into multiple test categories, each of whichcontained several history detection tests. Test categories included:– General tests of popular websites selected from Web rankings [22],– On-line news and social news sites along with posted story links,– A ﬁnal category of miscellaneous tests (including a zipcode detection test
and a check of performed search engine queries).
The default test which executed when a user visited the site homepage was the”top5k” test, checking for 6,417 most popular Internet locations. Selected tests
are listed in Table 2.
When a user visited a test page, she was presented with a short test description, along with a list of primary links to check. When the page loaded, thebrowser automatically performed checks of all links in the list, continuously updating a progress bar to inform the user about the test status. When all links
were checked, the browser submitted the results to the server using an AJAX
request, and received in response the thumbnail images and descriptions for all

224

A. Janc and L. Olejnik

websites for which primary links were found, as well as a list of secondary links
for each such website. The browser then checked all links in the secondary list
and submitted the results to the server. The server’s ﬁnal reply contained an
overview of the data found in the user’s history, along with a detailed list of all
primary and secondary links found.
For some tests, the set of secondary links was accompanied by a list of enumeration elements such as usernames on a visited social news site (Digg, Reddit or Slashdot), popular search engine queries for the search query test, or US zipcodes for thezip code detector test. Enumeration elements were appended to one or more base
URLs supplied by the server (of the form http://reddit.com/user/username,with username as an enumeration element) and were checked similarly to primaryand secondary links. This mechanism added a semantic component to the test by
informing the server about the type of the link found in the user’s history (e.g. username or search term), as contrasted with a “generic” link. It also helped the system conserve network bandwidth, by omitting common URL preﬁxes for similar
resources.
If a user visited any test page with JavaScript disabled, the server automatically recognized that fact and redirected the client to a separate test page which
utilized the CSS-only method described in Section 3.1. The CSS-only test required more network resources, but tested for the same primary and secondary
links as the regular test and presented results in the same manner. An overview
of diﬀerences between results gathered from clients with and without JavaScript
is provided in Table 3.
4.2

Link Selection

The selection of URLs to check for in each client’s history is of paramount importance in any project utilizing CSS-based history detection, as it determines
how much browsing data can be gathered. However, if too much data is transferred to the user, both the page load and test run times might increase to thepoint that the user will leave the page without completing the test. Large data
sets also limit the number of concurrent client a testing server can support due
to server-side network and computational limitations. In our system we tackled
this problem by both splitting tests into domain-speciﬁc categories, and dividing
our tests into two phases for checking primary and secondary links.
Primary Links. For each test we gathered primary links representing domainsof websites which contained resources of interest for the particular test. For thegeneral test category we used popular Web analytics services including Alexa[22], Quantcast [20] and Bloglines [23] to identify the most popular Internet
locations.
We retrieved the HTML source for each primary link and if any HTTP redirects occured, we kept track of the new URLs and added them as alternate
links for each URL (for example if http://example.org redirected to http://
example.org/home.asp both URLs would be stored). We also performed basic

Web Browser History Detection as a Real-World Privacy Threat

225

uniﬁcations if two primary links pointed to slightly diﬀerent domains but appeared to be the same entity (such as http://example.org and http://www.
example.org).
A total of 72,134 primary links were added to our system as shown in Table
2. To each primary link we added metadata, including the website title and ahuman-readable comment describing the nature of the site, if available. Primarylinks served as a starting point for resource detection in each test—if a primarylink (or one of its alternate forms) was detected in the client’s history, secondary
links associated with that primary link were sent to the client and checked.
Table 2. Number of links to be scanned per test is shown

top5k
top20kAll

Primary links Secondary links
6417
1416709
23797
405416572134
8598055

Secondary Links. Browser history detection has the potential for detecting avariety of Web-based resources in addition to just the hostname or domain nameof a service. In our tests, for each primary link we gathered a large number of
secondary links for resources (subpages, forms, directly accessible images, etc.)
within the domain represented by the primary link. The resources were gatheredusing several techniques to maximize the coverage of the most popular resources
within each site:
1. Search engine results. We utilized the Yahoo! BOSS [24] search engine API
and queried for resources within the domain of the primary link, taking
advantage of the fact that search engine results are sorted by relevance sothat the top results returned correspond to the most often visited pages.
For most primary links, we requested 100 results, but for the most popularInternet locations (sites in the Alexa 500 list) we retrieved 500 results.
2. HTML inspection. We retrieved the HTML source for each primary link
and made a list of absolute links to resources within the domain of the
primary link. The number of secondary links gathered using this method
varied depending on the structure of each site.
3. Automatic generation. For some websites with known URL schemes we generated secondary links from list pages containing article or website section
names; this behavior allowed us to quickly generate links for websites such
as Craigslist and Wikileaks.
We then aggregated the secondary links retrieved with each method, removing
duplicates or dubious URLs (including ones with unique identiﬁers which would
be unlikely to be found in any user’s history) and added metadata such as linkdescriptions where available.

226

A. Janc and L. Olejnik

For news site tests we also gathered links from the RSS feeds of 80 most popular news sites, updated every two hours4 . Each RSS feed was tied to a primarylink (e.g. the http://rss.cnn.com/rss/cnn_topstories.rss was associatedwith the http://cnn.com primary link). Due to the high volume of links insome RSS feeds, several news sites had tens of thousands of secondary links.
Resource Enumeration. In addition to secondary links, some primary links
were also associated with enumeration elements, corresponding to site-speciﬁc
resources which might exist in the browser’s cache, such as usernames on social
news sites, popular search engine queries, or zipcodes typed into online forms.
To demonstrate the possibility of deanonymizing users of social news sites wegathered lists of active users on those sites by screen scraping for usernames oflink submitters and comment authors. Enumeration elements were also usefulfor tests where similar resources might be visited by the user on several sites –in our search engine query test, the URLs corresponding to searches for popular phrases were checked on several major search engines without needing totransmit individual links multiple times.
4.3

Processing Results

For each visiting client, our testing system recorded information about the links
found in the client’s history, as well as metadata including test type, time of
execution, the User Agent header, and whether the client had JavaScript enabled.
Detected primary links were logged immediately after the client submitted ﬁrst
stage results and queried the server for secondary links. After all secondary links
were checked, the second stage of detection data was submitted to the test server.
All detected information was immediately displayed to the user.
For large-scale history detection systems, the amount of gathered data might
be aﬀected by server-side resource limits such as bandwidth and processing
power. Our application was deployed on a single virtual server in a shared VM
environment [25] using a basic $20/month plan, which aﬀected the amount of
information we could gather and process. Organizations with more resources
would be able to perform more extensive history detection tests, posing a more
serious threat to user privacy.

5

Results

The testing application based on this work was put into operation in early
September 2009 and is currently available at [10]. Results analyzed here span
the period of September 2009 to February 2010 and encompass data gatheredfrom 271,576 users who executed a total of 703,895 tests. The default top5k
4

Due to high interest in our testing application and associated resource constraints,
we were forced to disable automatic updating of RSS feeds for parts of the durationof our experiment.

Web Browser History Detection as a Real-World Privacy Threat227

test, checking for 6,417 most popular Internet locations and 1,416,709 secondary
URLs within those properties was executed by 243,068 users5 .
5.1

General Results

To assess the overall impact of CSS-based history detection, it is important todetermine the number of users whose browser conﬁguration makes them vulnerable to the attack. Table 3 summarizes the number of users for whom the top5k
test found at least one link, and who are therefore vulnerable. We found that
we could inspect browsing history in the vast majority of cases (76.1% connecting clients), indicating that millions of Internet users are at risk. A somewhat
smaller number of users with found results for the All test might be attributed
to the fact that users who recently cleared their browsing history or used private
browsing modes executed the most extensive test to determine if they are at any
risk.
Table 3. Aggregate results for popular tests for JavaScript and CSS-only techniques
Test

Tests Ran Found Primary Primary/user (avg) Secondary/user (avg)
JS CSS JS
CSS
JS
CSS
JS
CSS

top5k 206437 8165 76.1% 76.9% 12.7
top20k 31151 1263 75.4% 87.3% 13.6
All32158 1325 69.7% 80.6% 15.3

9.8
15.1
20.0

49.9
48.1
49.1

34.6
51.0
61.2

An analysis of relative diﬀerences in susceptibility to history detection basedon the user agent is shown in Table 4. For all browsers, the number of clients
who were found vulnerable was above 70%. Browsers such as Safari and Chrome
reported higher rates of susceptible clients (82% and 94% average), indicatingthat history detection can aﬀect a signiﬁcant number of Internet power users.
For users with at least one detected link tested with the JavaScript technique
we detected an average of 12.7 websites (8 median) in the top5k list, as well as
49.9 (17 median) secondary resources. Users who executed the more-extensive
JavaScript top20k test, were detected to have visited an average of 13.6 (7)pages with 48.2 (15) secondary resources. Similar results were returned for clients
who executed the most elaborate all test, with 15.3 (7) primary links and 49.1
(14) secondary links. The distribution of top5k results for JavaScript-enabledbrowsers is shown in Figure 5. An important observation is that for a signiﬁcantnumber of users (9.5%) our tests found more than 30 visited primary links;
such clients are more vulnerable to deanonymization attacks and enumerationof user-speciﬁc preferences.
5

Our testing system was featured on several social news sites and high-readership
blogs, which increased the number of users who visited our website and helped in
the overall data acquisition.

228

A. Janc and L. Olejnik
Table 4. Percentage of clients with detected links by User Agent
Test

IE
Firefox Safari Chrome Opera
JS CSS JS CSS JS CSS JS CSS JS CSS

top5k 73 92 75 77 83 79 93 100 70 82
top20k 81 95 69 86 89 97 90 100 88 95
All
78 97 62 79 85 89 87 98 85 83

Due to the fact that our testing site transparently reverted to CSS-only tests
for clients with scripting disabled, we are also able to measure the relative differences in data gathered from clients with JavaScript disabled or unavailable. A
total of 8,165 such clients executed the top5k test; results were found for 76.9%
of clients, with a median of 5 visited primary URLs and 9 secondary URLs.
Results for the top20k test executed in CSS yielded results similar to JavaScript
clients, with 15.1 (8) websites and 51.0 (13) secondary links.
Interestingly, it seems that for certain tests, users without JavaScript appear
more vulnerable due to a higher number of clients with at least one found link,
and more detected links per client. This result should be an important consideration for organizations which decide to disable scripting for their employees forsecurity reasons, as it demonstrates that such an approach does not make them
any more secure against history detection attacks and associated privacy loss.

Fig. 5. Cumulative distribution of top5k primary and secondary links

Web Browser History Detection as a Real-World Privacy Threat

5.2

229

Social News Site Links

An important overall part of our test system were tests of visited links fromsocial news sites. We investigated three popular social news sites: Digg, Reddit
and Slashdot. For each site, in addition to secondary links representing popular pages within that website, we also gathered all links to external destinations from the site’s main RSS feed. We also checked for visits to the proﬁlepages of active users within each site using the enumeration strategy outlined in
Section 4.2.
We found that for users whose browsing history contained the link of the tested
social news site, we could, in a signiﬁcant majority of cases, detect resources
linked from that site. History detection techniques could be used to measure user
engagement on social news sites by comparing the average number of visited news
stories; such analysis can be done both for individual users, and on aggregate, asa tool to compare social news site popularity. Additionally, for 2.4% of Reddit
users we found that they visited the proﬁle of at least one user of their social newssite. Such data demonstrates that it is possible to perform large-scale information
gathering about the existence of relationships between social news site users, andpotentially deanonymize users who visit their own proﬁle pages.
Table 5. Average and median numbers of found secondary links from social news sites

Digg
RedditSlashdot

Average secondary Median secondary
51.8
7
163.3
26
15.2
3

It is important to note that the speciﬁed architecture can potentially be used
to determine user-speciﬁc preferences. Inspecting detected secondary links canallow a determined attacker to not only evaluate the relationship of a user with aparticular news site, but also make guesses about the type of content of interest
to the particular user.
5.3

Uncovering Private Information

For most history tests our approach was to show users the breadth of information
about websites they visit which can be gleaned for their browsing history. However, we also created several tests which used the resource enumeration approachto detect common user inputs to popular web forms.
The zipcode test detected if the user typed in a valid US zipcode into a form onsites requiring zipcode information (there are several sites which ask the user toprovide a zipcode to get information about local weather or movie showtimes).
Our analysis shows that using this technique we could detect the US zipcode
for as many as 9.2% users executing this test. As our test only covered several
hand-picked websites, it is conceivable that with a larger selection of websites

230

A. Janc and L. Olejnik

requiring zip codes, the attack could be easily improved to yield a higher successrate.
In a similar test of queries typed into the Web forms of two popular searchengines (Google and Bing) we found that it is feasible to detect some user inputs.
While the number of users for whom search terms were detected was small (about
0.2% of users), the set of terms our test queried for was small (less than 10,000
phrases); we believe that in certain targeted attack scenarios it is possible toperform more comprehensive search term detection.
While limited in scope due to resource limitations, our results indicate that
history detection can be practically used to uncover private, user-supplied information from certain Web forms for a considerable number of Internet users andcan lead to targeted attacks against the users of particular websites.

6

Conclusions

This paper describes novel work on analyzing CSS-based history detection techniques and their impact on Internet users. History detection is a consequence ofan established and ubiquitous W3C standard and has become a common tool
employed in privacy research; as such, it has important implications for the privacy of Internet users. Full understanding of the implementation, performance,and browser handling of history detection methods is thus of high importanceto the security community.
We described a basic cross-browser implementation of history detection inboth CSS and JavaScript and analyzed Web browser behavior for content returned with various HTTP response codes and as frames or iframes. We provided an algorithm for eﬃcient examination of large link sets and evaluated its
performance in modern browsers. Compared to existing methods our approach is
up to 6 times faster, and is able to detect up to 30,000 links per second in recent
browsers on modern consumer-grade hardware. We also provided and analyzed
results from our existing testing system, gathered from total number 271,576 ofusers. Our results indicate that at least 76% of Internet users are vulnerable tohistory detection; for a simple test of the most popular websites, we found, on
average 62.6 visited URLs.
Our ﬁnal contribution is the pioneering the data acquisition of history-baseduser preferences. Our analysis not only shows that it is feasible to recover suchdata, but, provided that it’s large-scale enough, enables enumeration of privacyrelevant resources from users’ browsing history. To our knowledge, this was theﬁrst such attempt. Our results prove that CSS-based history detection does workin practice on a large scale, can be realized with minimal resources, and is ofgreat practical signiﬁcance.
Acknowledgements. L.O. gratefully acknowledges ﬁnancial support for thiswork from the European Organization for Nuclear Research (CERN) and, inparticular, N. Neufeld for the help, support and fruitful discussions.

Web Browser History Detection as a Real-World Privacy Threat

231

References
1. W3C: Cascading style sheets, level 1, http://www.w3.org/TR/REC-CSS1/
2. Bugzilla: Bug 57351 - css on a: visited can load an image and/or reveal if visitor
been to a site (2000), https://bugzilla.mozilla.org/show_bug.cgi?id=57531
3. Felten, E.W., Schneider, M.A.: Timing attacks on web privacy. In: CCS 2000: Proceedings of the 7th ACM Conference on Computer and Communications Security,
pp. 25–32. ACM, New York (2000)
4. Jagatic, T.N., Johnson, N.A., Jakobsson, M., Menczer, F.: Social phishing. ACM
Commun. 50(10), 94–100 (2007)
5. Jackson, C., Bortz, A., Boneh, D., Mitchell, J.C.: Protecting browser state from web
privacy attacks. In: WWW 2006: Proceedings of the 15th International Conferenceon World Wide Web, pp. 737–744. ACM, New York (2006)
6. Jakobsson, M., Stamm, S.: Web camouage: Protecting your clients from browsersning attacks. IEEE Security and Privacy 5, 16–24 (2007)
7. Webcollage: Web 2.0 collage, http://www.webcollage.com/
8. Wills, C.E., Zeljkovic, M.: A personalized approach to web privacy–awareness,
attitudes and actions. Technical Report WPI-CS-TR-10-07, Computer Science Department, Worcester Polytechnic Institute (2010),
http://www.cs.wpi.edu/~cew/papers/whattheyknow.pdf
9. Wondracek, G., Holz, T., Kirda, E., Kruegel, C.: A practical attack to de-anonymizesocial network users, IEEE security and privacy. In: IEEE Security and Privacy,
Oakland, CA, USA (2010)
10. Janc, A., Olejnik, L.: What the internet knows about you,
http://www.wtikay.com/
11. Nielsen, J.: Change the color of visited links,
http://www.useit.com/alertbox/20040503.html
12. Bugzilla: Bug 147777 - :visited support allows queries into global history (2002),
https://bugzilla.mozilla.org/show_bug.cgi?id=147777
13. W3C: Cascading style sheets level 2 revision 1 (css 2.1) speci cation, selectors,
http://www.w3.org/TR/CSS2/selector.html#link-pseudo-classes
14. Jakobsson, M., Stamm, S.: Invasive browser sniﬃng and countermeasures. In:
WWW 2006: Proceedings of the 15th International Conference on World Wide
Web, pp. 523–532. ACM, New York (2006)
15. Jackson, C., Andrew Bortz, D.B.J.M.: Stanford safehistory, http://safehistory.
com/
16. Baron, L.D.: Preventing attacks on a user’s history through css : visited selectors(2010), http://dbaron.org/mozilla/visited-privacy
17. Jakobsson, M., Juels, A., Ratkiewicz, J.: Privacy-preserving history mining for web
browsers. In: Web 2.0 Security and Privacy (2008)
18. Zalewski, M.: Browser security handbook, part 2 (2009),
http://code.google.com/p/browsersec/wiki/Part2
19. König, F.: The art of wwwar: Web browsers as universal platforms for attacks on
privacy, network security and rbitrary targets. Technical report (2008)
20. Quantcast: Quantcast, http://www.quantcast.com/
21. Anonymous: Did you watch porn, http://didyouwatchporn.com
22. Alexa: Alexa 500, http://alexa.com
23. Bloglines: Bloglines top feeds, http://www.bloglines.com/topblogs
24. Yahoo!: Yahoo! boss, http://developer.yahoo.com/search/boss/
25. Linode: Linode vps hosting, http://linode.com