# Tracking on the Web, Mobile and the Internet-of-Things

Reuben Binns<EMAIL_ADDRESS>University of Oxford, UK

###### Abstract

‘Tracking’ is the collection of data about an individual’s activity across
multiple distinct contexts and the retention, use, or sharing of data derived
from that activity outside the context in which it occurred. This paper aims
to introduce tracking on the web, smartphones, and the Internet of Things, to
an audience with little or no previous knowledge. It covers these topics
primarily from the perspective of computer science and human-computer
interaction, but also includes relevant law and policy aspects. Rather than a
systematic literature review, it aims to provide an over-arching narrative
spanning this large research space.

Section 1 introduces the concept of tracking. Section 2 provides a short
history of the major developments of tracking on the web. Section 3 presents
research covering the detection, measurement and analysis of web tracking
technologies. Section 4 delves into the countermeasures against web tracking
and mechanisms that have been proposed to allow users to control and limit
tracking, as well as studies into end-user perspectives on tracking. Section 5
focuses on tracking on ‘smart’ devices including smartphones and the internet
of things. Section 6 covers emerging issues affecting the future of tracking
across these different platforms.

###### Contents

  1. 1 Introduction
  2. 2 Tracking on the Web
    1. 2.1 Pre-Web Tracking
    2. 2.2 Surveillance-Based Advertising
    3. 2.3 Programmatic Advertising
    4. 2.4 Third-party Services
    5. 2.5 Cookies in Detail
      1. 2.5.1 Cookie Syncing, Disguising, and Hijacking
      2. 2.5.2 Non-HTTP Cookies
    6. 2.6 Fingerprinting
    7. 2.7 Email-based Tracking
  3. 3 Tracking the Trackers
    1. 3.1 Network Traffic Analysis
    2. 3.2 Inferring Tracker Data Flows from Ads Served
    3. 3.3 Cross-border Tracking Comparisons
    4. 3.4 Measuring Legal Compliance and Regulatory Effects
  4. 4 Tracking Countermeasures and End-User Perspectives
    1. 4.1 Tools for Notice and Consent
      1. 4.1.1 Tracking Preference Standards (P3P & DNT)
      2. 4.1.2 Privacy Policy Languages
    2. 4.2 First-party Limitations on Tracking
    3. 4.3 Tracker Blocking and Obfuscation
    4. 4.4 Privacy-preserving Alternatives
    5. 4.5 End-User Perceptions, Expectations, and Choices
  5. 5 Tracking on ‘Smart’ Devices
    1. 5.1 Smartphones and Apps
      1. 5.1.1 Apps vs Browsers
      2. 5.1.2 Mobile Advertising Identifiers
      3. 5.1.3 Third-party Mobile SDKs
      4. 5.1.4 Mobile Tracking Detection Methodology
      5. 5.1.5 Distribution of App Trackers
      6. 5.1.6 Comparing App Tracking Against Web Tracking
      7. 5.1.7 App Tracking and the Law
      8. 5.1.8 App Developer Incentives
    2. 5.2 Internet-of-Things and Smart Homes
    3. 5.3 Cross-device Tracking and ‘De-Anonymised’ Identifiers
  6. 6 Whither Tracking?
    1. 6.1 An Adtech Market Crash?
    2. 6.2 Data protection and privacy law
    3. 6.3 Competition and Antitrust
    4. 6.4 ‘Privacy-Preserving’ Tracking?
    5. 6.5 Concluding Remarks
  7. 7 Acknowledgements

##  1 Introduction

A working definition of tracking which aligns with the focus of this paper was
provided by the World Wide Web Consortium (W3C)’s Tracking Protection Working
Group in 2019 111https://perma.cc/3HXA-F47U:

> Tracking is the collection of data regarding a particular user’s activity
> across multiple distinct contexts and the retention, use, or sharing of data
> derived from that activity outside the context in which it occurred. A
> context is a set of resources that are controlled by the same party or
> jointly controlled by a set of parties.

While this definition is proposed within the context of the web, it could
meaningfully be applied to other technologies and platforms such as mobile
apps and other devices connected to the internet (the so-called Internet-of-
Things or IoT). As we shall see later, similar issues arise across all three.

Let us begin by unpacking this definition with an example. Imagine Alice
visits the website of a book shop and browses through their collection of
wildlife books. She then goes to her favourite search engine and to search for
articles about climate change policy. She sees a link to a speech made in
Parliament referring to the climate crisis, which she clicks on and reads.
Data about Alice’s activity — browsing the book site, entering search terms,
slowly scrolling through the parliamentary records — can be and almost
certainly is being collected in some form by the organisations behind these
websites and services. Such collection would not, by itself, be considered
‘tracking’, so long as data collected within one context stayed within that
context. But if an interested party somehow collates these different data
points — e.g. her book shop browsing is somehow connected to data about her
search terms, or what she was looking at on the parliament website — then this
would count as tracking according to the above definition.

There are many different ways this tracking could be happening; many different
parties that might be involved; and many different purposes for doing so.
Alice might be tracked by her own browser, which monitors her browsing
behaviour to personalise web content recommendations to her on the web and
target her on other platforms (e.g. sponsored posts on a social network). She
might be tracked by the search engine, which builds a picture of which search
results Alice actually clicks on, so that the kinds of sites she visits show
up higher in her personalised search results next time. Or she might be
tracked by an advertising technology (adtech) company, whose tracking
capabilities are bundled up in the code embedded by websites to display
adverts and generate revenue. This enables the adtech company, who Alice has
probably never heard of, to target ads to Alice based on her past behaviour on
multiple different websites. Some of these vectors for tracking — the browser,
the search engine, the adtech company — might also be owned and operated by
the same company, enabling it to track Alice’s activities in multiple ways.

With the advent of smartphones and internet-of-things devices, the vectors for
tracking have increased; now Alice might be tracked in physical space by the
apps (and operating system) accessing the GPS system on her phone, and her
conversations might be listened in on by the smart speaker in her living room.
All of this activity is increasingly tied together across these different
devices to build ever-more detailed and proliferating personal profiles.

The term ‘tracking’ is used to mean different things in a range of contexts,
including state surveillance, public health, policing and elsewhere. This
paper primarily focuses on tracking as a near-ubiquitous commercial practice
which emerged through a symbiotic (or arguably, parasitic) relationship with
websites, mobile apps and other internet-based services. The tracking
infrastructure embedded in modern devices provides deep, intimate portraits of
our lives which is already routinely used to persuade and discriminate between
consumers[1]. It goes further than the most intrusive forms of government
surveillance that existed before it, relying not on manual, human listening
but rather on automated data capture or what Roger Clarke calls
‘dataveillance’[2]. Tracking could well be considered the workhorse of what
some have called ‘surveillance capitalism’; without it, the vast wealth and
and power of large digital platforms would not have been possible [3, 4]. This
article focuses primarily on tracking in the European and north American
context, but tracking has developed differently in different parts of the
world[5, 6], and is more or less integrated within systems of state control
and surveillance under different regimes [7, 8, 9, 10].

The remainder of this article is structured as follows. Section 1 introduces
the concept of tracking. Section 2 provides a short history of the major
developments of tracking on the web. Section 3 presents research covering the
detection, measurement and analysis of web tracking technologies. Section 4
delves into the countermeasures against web tracking and mechanisms that have
been proposed to allow users to control and limit tracking, as well as studies
into end-user perspectives on tracking. Section 5 focuses on tracking on
‘smart’ devices including smartphones and the internet of things. Section 6
covers emerging issues affecting the future of tracking across these different
platforms.

##  2 Tracking on the Web

The kind of tracking covered in this article first began on the World Wide Web
(henceforth: the web), and it remains one of the main platforms on which
tracking occurs. This section provides a brief history and background
information on the development of web tracking.

###  2.1 Pre-Web Tracking

Early computers had little capability or reason to track users, because users
were generally also programmers, and their input was limited to running
programs from start to finish, as they could not be stored in memory. As
systems advanced and were capable of responding to dynamic user inputs, it
became useful to modify how software behaves in response to what the user had
done in the past. In particular, early work on natural language dialog systems
provided a variety of methods for personalising interactions with users. ‘User
modelling’ refers to the practice of generating a generic data schema in which
particular user profiles can be represented, or ‘the construction and use of
an explicit model of the user’s beliefs, goals and plans’ [11].

In some cases, this involved inferring what knowledge has already been
imparted to the user (e.g. KNOME: Modeling What the User Knows [12]), while in
others, it involved the construction of ‘stereotypes’ based on analysing which
user properties most often co-occur [12]. Other approaches allowed more
dynamic user profiles to be built over time in response to user behaviours
[13]. But these examples of user profiling did not involve user _tracking_ as
such, because the profile was only associated with the program in question. As
such, data was only collected within a single context, rather than combined
across multiple contexts, and typically directly served the user’s interests
and needs regarding the operation of the software.

This began to change with the rise of the web. The web was one of several
hypertext systems at the time[14], but rapidly grew to become the primary
means by which the vast majority of people accessed the internet for the
decades to come. Early website providers were in a very different position to
previous software providers. Users were no longer interacting with individual
pieces of software, but accessing many different websites over the internet
via a single web browser. The web presented new challenges for user modelling.
Since the early web was designed to exchange static documents, rather than
dynamic code, there was no way for a website to record anything about a user -
the website was retrieved by the user, but information about the user was
largely not collected by the website. Furthermore, even if websites had a way
to record user information, each individual website could only build a limited
user profile based on their activity on that site.

###  2.2 Surveillance-Based Advertising

As the web developed, technology was invented to support tracking. Web
developers wanted a way to be able to remember users. In 1994 John Montully, a
developer at Netscape, an early web browser, created the ‘cookie’; a way to
store a small amount of information associated with a user [15]. The cookie is
generated by the website and stored on the user’s browser. As the user goes
from one page on the website to another, the browser presents the same cookie
back to the web server, which can then tie the various page visits together
into a coherent user ‘session’. This gave websites the ability to remember
their visitors, with all kinds of useful applications; showing the user what
has changed since they last visited, remembering what items are in the user’s
shopping cart, giving the user a tailored experience, and more.

A cookie is a file containing a series of fields, including: a ‘name’ to
identify the cookie; an expiration date after which the cookie should not be
sent by the browser; a domain restricting where the cookie can be sent; a URL
‘path’ restricting where the cookie can be sent within that domain; amongst
other fields. Hosts (whether first or third-parties) send cookies in response
to HTTP requests from browsers, or via Javascript code. Unless the cookie is
blocked by the browser, the browser will store the cookie and add it to any
requests it makes to the domain defined in in the cookie, until the cookie has
expired as per its expiration date.

The original purpose of a cookie — to record a user’s state (e.g. what’s in
their virtual shopping basket, or whether they have visited a linked page
already) — doesn’t necessarily require the user to be identified. A cookie
could just describe something about the user’s state in a simple way. Indeed,
cookies were initially envisioned as simple key-value pairs to record basic
state information. For instance, a cookie designed to enable a user to resume
watching a video where they left off in a previous session might have the
format ‘resume = [time]’. But today, what is actually contained in cookies is
often much more complex.222For instance, rather than generic cookies which do
the same thing for different users, cookies can vary significantly between
users and their purpose and behaviour cannot always be inferred from their
name. This makes it harder for browsers and anti-tracking tool makers to
decide which cookies to block and which to allow. A 2017 study of network
traffic from real users examined the contents of cookies, finding it was often
quite sophisticated and varied between users, and in many cases, the Name
field differed between users, partly to act as a unique user identifier [16].

The news media soon picked up on this technology, with the first mention in
the press apparently in 1996 [17]. Around the same time, a new business model
began to develop, on which much of the web still depends: advertising.333For
details on this early history, see [18, 19] At first, advertising on the web
worked like advertising in a newspaper; the advertiser paid the website
operator to display a particular advert on their page. The same advert would
be placed in the same place on a web page, and seen by all visitors, for
however long the advertiser paid. But unlike paper, the increasingly complex
and dynamic technology of the web offered the ability to make advertising more
tailored. First, rather than giving their adverts to first-party websites to
distribute on their behalf directly, advertising agencies could have the
first-party website include a piece of code which would retrieve for the user
the latest version of the advert from the agency’s own server. This way, the
advertising agency had more control over their advert inventory, and could
build in mechanisms to more carefully manage their spending.

To get their money’s worth, advertisers would rather pay a website for each
time their ad is clicked on by a user (or shown to them), rather than a flat
fee for displaying the ad over a particular time period. But even better,
they’d pay more for ‘impressions’ (the term for when an ad is shown on a
loaded web page) shown to users who might actually engage with their advert.
If Alice has never seen an advert before, that impression may be worth more
than if she’s already seen the same advert 10 times before. Furthermore, if
Alice is more interested in ornithology than astronomy, the opportunity to
advertise to her may be more valuable to an advertiser trying to sell
binoculars than to one trying to sell telescopes. To this end, advertising
agencies augmented the code they gave to first-party websites for distributing
banner adverts, to allow them to better track who was seeing which ads. An
early adopter was the web advertising technology company DoubleClick, founded
in 1995; it went on to become the biggest ad serving platform, and was
acquired by Google in 2008. In setting up a direct third-party channel to
observe user behaviour, companies like DoubleClick set in motion a trend that
would come to dominate the web. The privacy implications of this were
significant, and discussed by web developers on mailing lists as early as
1995[19]. Further alarms were raised by privacy scholars and activists [20],
but their warnings largely went unheeded over the following decade.444As
explained by Arvind Narayanan: “Privacy scholars and activists were worried
about surveillance capitalism at least as far back as 1995, when DoubleClick
was founded. We tried to warn the public before it was too late, but mostly
failed, at least in the US” https://perma.cc/Z7YF-EY3C From their inception,
cookies were understood to involve tradeoffs between functionality and
surveillance capability[19].

From the distribution of third-party advertiser code on first-party websites,
it was a small step to the use of ‘third-party’ cookies. First party cookies
are created and set by the website being visited and stored in the browser
under the domain associated with that website. Third party cookies work much
the same as first-party cookies, but are set and read by third-parties via
scripts embedded in first-party websites. They allow the third-party adtech
firms not only to measure who sees their adverts on first-party sites, but
also _track_ those users from one site to the next. The privacy threats of
third-party cookies did not go unnoticed. The Internet Engineering Taskforce
(IETF) initially proposed to outright prohibit the use of third-party cookies,
or at least have them disabled by default.555See https://perma.cc/Q3X5-J9AX
However, they were already in significant use in the wild before the relevant
standard was adopted in 1997 (RFC 2109), and subsequent standardisation
efforts dropped this proposal. Cookies then came to be the primary technology
for tracking users as they browsed the web.

In the 2000s, two things changed the relationship between third-parties and
first-parties: the evolution of new programmatic advertising technology, and
the increasing reliance on third-party services and resources by first-party
websites. These developments are discussed in detail in the following
sections.

###  2.3 Programmatic Advertising

Around 2001, advertising technology intermediaries saw opportunities to make
the matching of buyers and sellers of ad space more dynamic. Rather than
advertisers negotiating with publishers directly to buy ad space, adtech
intermediaries could gather together multiple advertisers and publishers and
dynamically match them. This enabled publishers to make money from ‘remnant’
ad space which had not already been purchased directly by advertisers — i.e.
web pages with otherwise empty space which would be graced with valuable
consumer eyeballs.

But it was hard for advertisers to tell exactly where their ads were appearing
and how valuable the eyeballs on those remnant pages really were. By 2007, a
new kind of intermediary arrived: the programmatic ad exchange, coupled with
real-time bidding (RTB) and fine-grained personal information about the end
user [21, 22]. Ad exchanges run auctions for the ad space on a web page each
time the page loads; and advertisers bid to buy that impression. This promised
advertisers something quite unique; the ability to bid against each other for
the opportunity to show a particular advert to a particular user based on a
profile of that user. The advertiser’s bidding strategies are all programmed
ahead of time (often with the help of ‘demand-side’ platforms), meaning that
the auction can take place within the milliseconds which elapse between the
user requesting the page and the page loading. Within this tiny window, a
surprisingly large number of actors are involved in a complex, automatically
choreographed bidding war, involving the processing of lots of data from
multiple sources.

The precise details of the bidding process differ from one case to another,
however, on the web, there are now two main technical specifications for how
these automated auctions take place. One is controlled by Google, called
‘Authorized buyers’, and the other by the Interactive Advertising Bureau
(IAB), called ‘OpenRTB / AdCom’. Both processes consists of a few broad steps:

  1. 1.

First, the ad exchange lists the auction, by broadcasting a ‘bid request’,
which contains information including: the URL of the page being visited; the
site category; the user’s device and browser details; one or more user
identifiers that bidders can use to recognise a user from another context; the
ad exchange’s own cookie information about that user, which could include
inferred gender, interests, location (city, or even GPS co-ordinates), and
more.

  2. 2.

Then, the various competing advertisers’ programmatic bidding strategies are
automatically executed by their respective demand-side platform
intermediaries. These bidding strategies are typically informed by further
data about the user they have been able to glean from other tracking sources.
Most advertisers use intermediaries called ‘demand-side platforms’ to plan and
execute bidding strategies on their behalf; they may also use ‘data management
platforms’ which help manage the user data they collect and associated ad
targeting segments.

  3. 3.

Finally, the highest-bidding advertiser wins the auction, and has an advert
automatically chosen, retrieved from their ad inventory, and loaded on the
page for the user to see and perhaps click on (or perhaps, to ignore or block
- see section 4).

This new way of targeting ads led to a flourishing of new intermediaries for
tracking, to meet the demand of advertisers to know more about the users whose
attention they were paying to reach. The more data available to target the ad,
the more the advertiser may be willing to pay to extract the maximum value
from an advertising opportunity. It was therefore in the interests of various
third-parties to gather as much data as they could about individual users, so
as to better inform bidding strategies of advertisers, and for publishers to
increase the value of their ad space when high-value users visit their sites.
By building ever-more detailed profiles of increasing numbers of individuals,
intermediaries could convince advertisers to pay more for the supposedly more
accurate targeting opportunities. Of course, the advertisers also wanted to
know that their money was being well spent; this led to the creation of a
substantial sector of ad measurement providers, who assembled complex data
supply chains dedicated to following what people do after seeing an ad, to
establish how effective the targeted advertising actually was in driving sales
and other behaviours.

###  2.4 Third-party Services

The other key development through the 2000s was the increasing reliance on
third-party services and resources in web development. This came in part
because the web was moving from a largely read-only web of _documents_ , to a
web of interactive _applications_. This meant web developers were no longer
just formatting documents in HTML, they were now using increasingly complex
code to design interactive applications in Javascript. Rather than creating
all functionality of a website from scratch, it is far easier to take existing
snippets from other websites and incorporate them into your own. In itself,
such copying was not novel; from the very beginning of the web, developers
have always liberally copied from each other (indeed, it is one of the factors
which allowed the web to grow and attract users who also produced new
content[23]). However, traditionally, when web developers copied some code
from elsewhere, they would still _host_ it from their own domain, so that when
a user connects to example.com, all the HTML pages, images, Javascript files
and so on, would be served via example.com as a first-party. As a result,
whoever wrote the original code copied by example.com would not have any
direct connection to the user’s browser. As such, use of third-party code
didn’t facilitate third-party tracking.

However, web development increasingly came to rely on third-parties not just
for code and content itself, but also for its distribution; this allowed
first-parties to not worry about maintaining and hosting it all themselves.
This included everything from widgets for embedding and serving video content,
user analytics, the loading of special fonts, comment functions below news
articles, buttons which allowed content to be shared via the user’s account on
a social network, anti-spam measures which separate bots from genuine human
users, and much else besides. These services are typically made available
through Application Programming Interfaces (APIs), which are intermediary
pieces of software which allow two applications to work together. Web
development moved away from first-parties bringing together all the resources
for a website and hosting them themselves via their own domain and server,
towards first-parties being merely the co-ordinators of increasingly complex
tapestries of third-party code and content woven together and served from
their respective third-party APIs [24]. Referencing externally hosted third-
party resources had several advantages for first parties over hosting such
resources themselves, in addition to saving them upfront effort and cost.
These include latency (users can retrieve the third-party resource more
quickly from an optimally located server), better caching (if many first-
parties use the same third-party resource, users may have it cached in their
browser already), and less work for the first-party to update and secure a
variety of different elements.

However, while providing such benefits to first parties, third party resources
amassed a significant amount of power to ingest data [25]. Every function
outsourced to a third party opened up another network connection between the
user and a third-party server, giving the third-parties the opportunity — and
in some cases a seemingly legitimate excuse — to gather behavioural data about
the user. With a venture-capital driven charge for the mass collection of
personal data, these third-party services increasingly took up that
opportunity. As a result, users were not only being tracked directly via the
third-party scripts belonging to advertising technology providers, but also by
other third-parties who were providing other, non-advertising services to
first-party websites. But before long, those other third-parties also took up
the opportunity to become enmeshed in the digital advertising industry too,
for instance by operating as data management platforms, supplementing demand-
side platforms with additional personal data about individuals to better
inform ad targeting and bidding strategies. Third-parties shared some of the
profits of this data monetisation with the first-parties on whom they
depended, and soon the dependency was reversed; many websites came to rely on
these third-parties not only for functionality (analytics, content
distribution, interactive elements), but also as their main revenue source.

Among the third-party resources commonly referenced by first-parties are those
belonging to the largest web giants, the likes of Google, Amazon, Facebook,
Twitter, and Microsoft. This means that users of their services can be tracked
as they move around the web, often even when not logged in to the respective
service. This has further enriched the already rich profiles these platforms
had built on their users activities beyond their walled gardens. As a result,
a social network might be able to infer sensitive private information about a
user not because of what they do _on that social network_ , but as a result of
the websites they visit _outside_ of it. These trackers are sometimes called
‘personal trackers’ because while they are ‘third-parties’ in a technical
sense, the user may also have a personal account with them because they also
operate as user-facing first-party services like Google or Facebook [26].
Whether the average user would _expect_ or _consent_ to be tracked beyond each
respective service in this way is another matter. Even those without an
account on a social network might still have their activity on the web tracked
via its third-party tracking network; the term ‘shadow profile’ refers to the
profiles of individuals who have never created an account on a social network
but nonetheless have their activities monitored and collated by them [27]. The
same is true for all the other web giants with significant third-party
prevalence on websites.

Another complicating factor is that some third-party services may not
initially be designed for tracking, but can over time become trackers. For
instance, a third-party analytics service might initially be used in a way
that only combines user data within a session, or within a single website. The
analytics provider’s code might set a cookie via the first-party’s domain. But
at some point, the analytics code might be updated to enable multi-domain
tracking — either by owner of the first-party domain linking together
behaviour from multiple different websites, or by the third-party looking to
build user profiles themselves. Google Analytics, the most popular web
analytics service, gives website operators the option of linking together user
behaviour across multiple domains they own. At any point, website operators
could use this to track users across their sites, and Google Analytics itself
can also do the same thing, across all the websites who embed their analytics
code (estimated around 56% of websites as of 2021666As estimated by W3techs
https://perma.cc/QG6H-J4FY). As such, web users may find that their web
browsing activities are being tracked via Google Analytics and incorporated
into a profile about them, potentially even if they have never had an actual
Google account, and even if they don’t use Chrome (Google’s web browser).777In
response to an ongoing anti-trust / competition investigation by the UK
Competition and Markets Authority (CMA) in 2021, Google committed to restrict
the use of Chrome browsing history and Analytics data to track users for
targeting and measurement of ads on Google or non-Google websites
(https://perma.cc/Z5ZA-G6SN)

A study of the development of third-party trackers between 1996-2016 provides
a useful historical overview of how this phenomenon has evolved. The study
found that the number of third-party trackers rapidly increased on websites
during this period [26]. In the early 2000s, no single tracker was present on
more than 10% of top sites; but by 2016, google-analytics.com was present on
nearly a third of top sites. As mentioned above, it is now present on a
majority of websites. By 2016, 300 out of the 500 top websites were making
calls to at least four different APIs which could be used for tracking without
cookies, up from less than 50 in 2005 [26]. Another study of the development
of third-party web tracking from 2005-2014 found a five fold increase in the
number of external requests[28]. There are some silver linings for the
privacy-concerned, however, as some early forms of third-party tracking had
already diminished or died out by 2016. For instance, ‘forced trackers’, which
use automatic popup windows, peaked in the early 2000s, before browsers began
automatically blocking such popups by default around 2004 [26].

Such firms became a significant part of the US and other economies [29].
Internet-related advertising revenue was estimated at $326 billion during
2020, up from $294 billion in 2019.888’What does 2020 hold for ad markets?’
WPP https://perma.cc/6GJB-WZSK A large share of this revenue is accrued by
third-party trackers [30].

###  2.5 Cookies in Detail

The following sections detail several important developments in the use of
cookies, including cookie syncing, disguising and hijacking, and non-HTTP
cookies.

####  2.5.1 Cookie Syncing, Disguising, and Hijacking

While third-party cookies were not prohibited or disabled by default as the
IETF had initially proposed, one control that was in place to limit their
risks was the ‘SameOrigin’ policy. This is a policy enforced by browsers,
which limits access to cookies to the entity which set them. In this context,
entities are distinguished by the domain that set them — for instance, a
cookie set by firstparty.com cannot be accessed by thirdparty.com and vice-
versa — but also by the protocol they use (e.g. HTTP vs HTTPS) and the network
port from which the server is operating. This means that a cookie set by
thirdparty.com via HTTPS on port 80, could not be read by a host from the same
domain thirdparty.com operating over HTTP on port 81, and vice-versa [31],
because while the domain matches, the network protocol and port differ.

The SameOrigin policy places a barrier on third-party trackers, because in
order to track a user across multiple sites, a tracker needs to be able to
both set and read cookies on each of those sites, which means each of the
first-parties must include code enabling the third-party to initiate a network
connection. The SameOrigin policy is intended to make it impossible for third-
parties to read the cookies set by first-parties or other third-parties. So
third-parties should therefore only be able to track individuals within the
networks of first-party sites on which they are present.

However, SameOrigin can be circumvented by multiple trackers working together,
using a technique called ‘cookie syncing’ or ‘cookie matching’. If tracker A
is on abc.com, and tracker B is on xyz.com, they can collaborate together to
track a user across both sites. The trick is that tracker A’s code, which has
been embedded by abc.com, forces the user’s browser to make a network request
to tracker B. This network request includes a query parameter at the end of
the URL, which contains the ID of the cookie that tracker A set. For instance,
the request might look something like trackerB.com/cookieid?=12345. Tracker A
therefore causes the browser to reveal itself to tracker B, by leaking an
identifier (12345) in a request to tracker B that tracker A set. Then, tracker
A and tracker B can set up a back channel through which they combine what
personal data they have about the individual by matching up their respective
cookie identifiers for that individual. In this way, multiple trackers can
work together to expand their reach and collaboratively build more detailed
profiles of users.

Cookie syncing is one of the increasingly complex behaviours exhibited by
trackers in recent years [26]. Empirical studies of visible cookie matching
techniques by 53 firms suggest that such techniques are present in over 91% of
the pages a user visits [32]. An in-depth study of cookie syncing in the wild,
using a year-long weblog from 850 web users, found that 97% of them are
exposed to cookie syncing, mostly within 1 week of web browsing [33]. The user
ID gets leaked on average to 3.5 different domains. They also estimate that a
user is tracked by 6.75 times _more_ domains as a result of cookie syncing
activity than they would if third-parties were unable to collude in this way.
Other studies have utilised machine learning models to uncover forms of cookie
synching which are not directly observable from the client side, by observing
the adverts a user recieves [34] (such studies raise interesting
methodological questions which are addressed in more detail in section 3.2).

Another way the SameOrigin policy and other tracking protections are
circumvented is by third-parties convincing first-parties to allow them to
deliver cookies through the first-party’s domain, through the use of domain
redirection. This is often achieved through the configuration of CNAME
records, which allow external access to a domain name space [35]. This way,
the third-party is disguised; from the browser’s perspective it appears to be
the first-party. As a result, third-parties can track users via different
first-party domains, without violating SameOrigin, while being inconspicuous
in the network traffic. However, this also means the third-party may be able
to access the first-party’s cookies as well — including those used for login
and other functionality — raising security risks for the first-party as well
as privacy risks for the user. More broadly, disguising third-party cookies as
first-party cookies means that users, browser makers, and researchers, can’t
as easily tell who is really ‘behind’ a cookie just by looking at the domain
that set it.

Even if first-parties don’t grant third-parties access to users via domain
redirection, there are other ways in which cookies can inadvertently give away
sensitive information to third-parties. Until recently, many websites did not
use HTTPS, the secure version of the regular network protocol for the web, for
setting and reading cookies. In some cases, only some parts of a website would
be loaded over HTTPS, while other parts deemed less sensitive might be loaded
over HTTP (e.g. loading custom fonts). However, many websites also used HTTP
for setting and reading cookies used for user personalisation. For websites
using multiple cookies for different purposes and functionality, with complex
inter-dependencies, and unclear or imprecise access-control mechanisms, it was
easy to inadvertently expose cookies containing sensitive information over
HTTP. A study in 2016 found that an attacker exploiting this could obtain a
user’s home and work address and web browsing history from Google; Bing and
Baidu exposed the user’s search history; and Yahoo even allowed an attacker to
send an email from the user’s account [36]. Ad networks like Doubleclick were
also found to be inadvertently revealing the user’s browsing history.

####  2.5.2 Non-HTTP Cookies

So far, we have primarily focused on HTTP(S) cookies. However, the basic
concept of a cookie has been extended to other parts of the web. They all have
the common function of setting and retrieving data about a user on their
device, whether that happens over HTTP or some other protocol. These
alternatives arose in part because as browsers clamped down on HTTP cookies,
trackers moved their operations into less well-policed parts of the browser
that still gave them the basic ability to write and read data.

Some methods relied on the fact that browsers often use ‘caching’ — keeping a
local copy of various data from websites in order to not have to load it fresh
every time — to track users. By hiding a unique identifier within the data
that the user is caching, it becomes possible for the host to reidentify the
user next time they visit by querying some of the contents in the cache, a
method first documented in 2003 and examined in detail in 2006
[37].999https://perma.cc/G9ZU-HGD5 Another method, also first documented in
2006, was to use Flash, a now largely defunct video software platform, to
store cookie-like objects. Regular cookies, set using HTTP, could be easily
deleted in the browser. Flash cookies, by contrast, could be set by a first or
third-party, on the user’s Flash player software (which was for many years the
default means of watching video on the web), and remained there even if the
user were to switch to a different browser [38].

These non-HTTP cookies were often used to defeat attempts by users to purge
cookies from their browsers. If a HTTP cookie was deleted, a backup could be
retrieved (either through the local caching or Flash methods described above),
a practice called ‘respawning’. A study in 2009 found 281 Flash cookies across
54 of the top 100 websites [39]. However, the use of Flash cookies declined
following the publication of this research; a follow up research article by
the same authors in 2011 found just 100 Flash cookies on 37 of the top 100
sites [40]. However, newer methods of achieving the same goal of
reconstructing deleted cookies were also found, including the use of HTML5
local storage and ETags. Increasingly sophisticated techniques were developed
to enable the reconstruction of cookies from any traces left behind by the
original, deleted cookie. Cookies that were ‘virtually irrevocable persistent’
were dubbed ‘evercookies’ by a researcher who uncovered a particularly devious
example [41]. The discovery of such mechanisms eventually lead to a lawsuit
and $500,000 settlement by one of the companies deploying them, KISSmetrics,
in 2013[42]. However, large scale studies in the following years revealed the
practice was still rampant [43].

###  2.6 Fingerprinting

The methods of tracking described above all involve tying together a user,
based on identifiers stored on the browser, using HTTP cookies and related
technologies. However, this is inherently less reliable because the user might
delete the cookies stored on their device. While the various respawning
methods discussed above might allow the identifier to be re-established, any
form of browser-side storage would still result in a cat-and-mouse game
between trackers trying to place cookies somewhere on the device and make them
stick, and anti-tracking tools trying to find and remove them. From a
tracker’s perspective, rather than having to set and read an explicit
identifier on a browser, it would be far more effective to be able to just
tell one browser from another based on their inherent differences. This is
where fingerprinting and other ‘implicit’ methods of tracking come in
[44].101010For an overview of browser fingerprinting methods, see [45] . While
the term fingerprinting is the preferred term of researchers, privacy
advocates, policy makers and others, the fingerprinting industry prefers to
use a host of alternative terms, like ‘Unique User Identifiers’ (UUIDs),
‘Pseudo-identifiers’, and ‘Cookieless signals’. Presumably, these are chosen
to sound less scary, and more obfuscatory, than ‘fingerprinting’.

Unlike cookies and other methods which involve creating a unique identifier
and storing it on the user’s device so they can be identified later on,
fingerprinting aims to identify a user based on their inherent features that
might uniquely pick them out of the ‘crowd’ of other web users (‘probabilistic
identification’). By analogy, it’s like the difference between a car’s number
plate (an explicit, unique identifier assigned to the vehicle), versus a
description of its brand, model, colour, scratches, and other distinguishing
features. Even if the owner changes the number plate, one might still
recognise it because of the brand, model, colour scheme, particular shape of a
dent in the bonnet, hub caps, etc. Unlike cookie-based tracking, which
involves interfering with the way the browser operates, and by necessity
leaves a trace by placing a cookie, fingerprinting happens more opaquely in
the background, on the server-side, and so is harder to detect. Other
terminology often used to make the distinction between cookie-based and
fingerprint-based tracking is ‘stateful’ vs. ‘stateless’ (e.g. [46]). Cookies
are classed as ‘stateful’ because they record the ‘state’ of a user (e.g.
their previous activity on or off the site) and make that state available to a
first or third party; by contrast, fingerprint-based tracking is ‘stateless’
in that it approaches each user fresh each time, and attempts to use
identifying features to tie their current session to a previously identified
user. Such terminology can be misleading though, in the sense that _both_
approaches are capable of maintaining state; the difference being whether
state is maintained via a cookie stored on the browser, or via a server-side
database against which people are matched based on their browser fingerprints.

Fingerprinting methods all depend on the possibility that a tracker might be
able to uniquely identify a browser based on what they reveal about themselves
naturally. In some cases, this includes almost-unique identifiers that a
browser emits for functional purposes, such as the Internet Protocol address
from which the request is being made. Often, an IP address will be unique to a
single user. But even without an IP address, there is other information that
browsers may give away. For instance, the particular operating system version,
the combination of plug-ins installed, the screen resolution, the selection of
fonts that the browser has already installed, and so on. Such information is
routinely shared with websites by browsers for a variety of reasons. For
instance, knowing the screen resolution allows the website to adapt its layout
to fit the dimensions of the user’s screen. Knowing which fonts the user
already has installed means the website doesn’t need to waste bandwidth
sending fonts to users who already have them installed. However, all those
useful characteristics in combination may be enough to uniquely distinguish
one browser from another. Tools like the Electronic Frontier Foundation’s
‘Panopticlick’, or ‘AmIUnique’ allow users to see how unique their browser’s
fingerprint is [44].

Even without access to all those browser characteristics, there are other ways
to track people. An early theoretical fingerprinting attack from Felten et. al
[20], was based on measuring the time it takes for browsers to perform an
operation with or without certain cached information. Since browser
performance depends partly on what information it has already cached from its
history, the speed of certain operations gives away clues as to what sites
have previously been visited. That inferred history is privacy-compromising in
itself, and might be enough to uniquely identify an individual browser. In the
years since, such sophisticated attacks are unnecessary; there are far more
readily available characteristics for fingerprinting, and fingerprint data is
compact (around a dozen kilobytes) so can be collected within seconds[47].

Some methods of fingerprinting make use of the ‘Canvas’ element, which was
part of the fifth generation of the web markup language HTML, released in
2014. The canvas element was designed to allow for the dynamic rendering of
shapes and images. It can be exploited by fingerprinting scripts, which use
the element to draw some text with a particular combination of font, size, and
background colour. The text isn’t actually shown to the user, but since
different computers will render the text in slightly different ways — due to
different image processing engines, compression, speed, etc. — the
fingerprinter can distinguish between different browsers by observing how they
perform this operation. It then creates a cryptographic hash of this
information, and stores it so the same user can be identified later on using
the same method [43]. While canvas fingerprints are not always totally unique,
they do enable identification in combination with other data [48], with a 2015
study finding such methods enabled unique identification of 34% of
participants in a study of 1,000 web browsers [49].

Unlike the ‘deterministic’ tracking enabled by assigned identifiers,
fingerprinting is _probabilistic_ in the sense that the tracker might not be
100% certain that the browser they see in one context is the same as the
browser they see in another context. They consider a wide variety of
characteristics that a browser might reveal about itself, in combination with
each other, in order to single an individual browser out from the crowd. This
generally works because most browsers have a unique set of characteristics
that allow them to be distinguished from others. In this sense, browsers are
much like the characters in the board game _Guess Who?_ ; many share many
common features with each other, but any two browsers can almost always be
distinguished from each other based on at least one feature.

How (in)distinguishable your browser is from all the others is typically
measured in terms of the concept of _entropy_ as used in information
theory[50]. A system with high entropy is one where you would need to ask many
questions in order to provide a complete description of its state; whereas a
low entropy system is one whose state could be determined by asking only
relatively few questions. A high level of entropy (measured in bits) means a
browser is hard to distinguish from other browsers, while low entropy means it
is easy to pick it out from the crowd. Each individual browser characteristic
that is revealed to a tracker will detract from the browser’s overall entropy,
although some characteristics are more revealing than others [44]. Another
concept sometimes used in this context is that of _unicity_ , which is defined
in terms of the proportion of individuals in a set (in this case, the
proportion of browsers exposed to a tracker) that are unique [51, 47].

While fingerprinting is harder to detect than cookie-based tracking, it is
possible by either focusing on the presence of third-parties who are
independently known to engage in it (e.g. through the fact that they publicly
advertise their services), or by looking for the tell-tale signs of
fingerprint-related behaviour. An example of the first, is a major study of
three known commercial fingerprinting providers in 2013. It showed that they
were already using a wide variety of fingerprinting methods, allowing them to
track users without needing any client-side identifiers (e.g. cookies) [52].
An example of the second, in an early large-scale study of fingerprinting,
involved detecting when third-parties were trying to obtain a list of all the
fonts the browser had installed in a suspicious manner strongly indicating an
attempt to fingerprint [53]. Later versions of HTML also provided many new
opportunities for fingerprinting, with APIs that allowed access to information
like a device’s battery status; while it might be useful to adapt a website so
as to not use up too much power on a device with an already-low battery, this
information can also be abused by fingerprinters [54].

A study from 2020 revealed that fingerprinting has only increased in the years
after these initial large scale studies [55]. Browser fingerprinting is now
present on more than 10% of the top 100,000 websites, and over a quarter of
the top 10,000 websites. Fingerprinting can also be used to re-establish
explicit tracking methods like cookies. Similar to cookie respawning via
storing identifiers in other parts of the browser, fingerprinting can be used
to restore a deleted cookie. If a user deletes a cookie, trackers can use
fingerprinting to pick them up again when they show up on another site, and
re-link them back to the profile they had earlier associated with the
individual.

###  2.7 Email-based Tracking

While email is not a web technology, predating the web by many years, in
recent decades email has come to use many of the same technologies as the web,
including HTML and Javascript frameworks for formatting and making email
experiences more interactive. This has a lot to with the popularity of web-
based email clients, but even non-web based email clients have for many years
had the capacity to interpret HTML and run embedded Javascript in emails,
making email almost a subset of the web. Therefore it should come as no
surprise that tracking is also very common within emails. The original purpose
for email tracking was so that senders could tell whether and when their
emails were opened by the recipient. This was acheived by embedding a 1x1
pixel image. Upon the recipient opening the email, this would trigger a
request over the network to load the image so it could be rendered. That
request could be taken as a signal that the email had been opened. This
behavioural datapoint is typically combined with other behavioural data and
third-party cookies, to link together the user’s email reading with their web
browsing. A 2018 paper [56] found hundreds of different third-parties which
track email recipients using such methods. When users click on links within
emails, further information about them is leaked via the URL query string
(using a method similar to that involved in cookie syncing).

##  3 Tracking the Trackers

Many of the studies mentioned above involve detecting trackers in the wild, at
scale. There are distinct methodological challenges involved in such studies.
As these methods have evolved, they have shaped the development of research
into trackers. They have also helped inform the efforts of browser and anti-
tracking tool developers to identify and block tracking. This section
discusses the main methodological approaches to detecting trackers; for a more
comprehensive overview, see [57].

###  3.1 Network Traffic Analysis

The typical methodology for web tracking detection involves capturing network
traffic from the browser (typically, HTTP and HTTPS requests and responses),
during a browser session. In some cases, the browser session is driven by a
real human user, and in others it is simulated by a bot which automatically
loads and interacts with a web page. Web tracking studies have grown in scale
massively. Seminal studies in this space, starting in 2006, typicaly focused
on the top 100 or 1,000 websites (e.g. [58, 39]). But larger scale
measurements have become possible with new approaches. For simulated user
studies, there are frameworks for crawling like OpenWPM and webXray which can
easily scale to millions of websites [46, 59] and billions of individual pages
[60]. Other studies leverage data from hundreds of thousands of real users who
have opted to take part in studies (e.g. users of the tracker-blocking plugin
Ghostery [61]).

In either case, this network traffic is then typically separated into first-
party and third-parties based on domains. At this point, the collected traffic
logs can be inspected. Specific types of personal information - e.g. email
addresses, zip codes, telephone numbers, and other data types - can be
searched for within the network ‘payloads’ (the actual contents of the data
packets being exchanged over the network). In the case of HTTP traffic, such
payloads can be read in the clear, and in previous times this was sufficient
to monitor the majority of web traffic. Until 2011, studies of web tracking
were able to mostly rely on inspection of HTTP traffic [62]. The fact that so
many third-party trackers did not use the more secure HTTPS protocol with
transport layer encryption, meant that their cookies could be observed by any
passive observer with access to the network, e.g. internet service providers,
mobile broadband network operators, and national intelligence agencies. A
study from 2015 examined how a passive observer would be able to link browsing
activity even as a user moved from one IP address to another, by inspecting
HTTP cookies transmitted over the network[63]. They estimate that such an
attacker can reconstruct 62—73% of a typical user’s browsing history in this
way.

However, HTTP has gradually been replaced by HTTPS, which encrypts every
request and response between the client and server. To observe tracking
behaviour over HTTPS, decryption is therefore required using a man-in-the-
middle proxy. This involves dynamically generating and installing a
certificate for each hostname (e.g. thirdparty.com). The browser is configured
to trust the certificate, even though it is not the correct certificate for
thirdparty.com, allowing the encrypted HTTPS traffic data to be decrypted.
Then the traffic can be inspected for evidence of personal information and
identifiers used for tracking.

Inspecting network traffic (whether HTTP or HTTPS) in this way for every
request and response, provides important evidence to help determine whether
tracking is taking place. However, it may be too fine-grained, potentially
missing certain forms of tracking; for instance, it may not be easy to tell
whether the data sent contains a fingerprint, because it is not possible to
search for fingerprints in the same way one could search for an email address
or similar. The payload might have another layer of encryption in addition to
HTTPS, or it might be encoded in a way which evades simple detection methods.
Finally, traffic inspection may not scale well, as some tracking may only be
triggered in certain circumstances, or in response to specific user behaviours
which might be missed during the data collection (especially if the study uses
a simulated user rather than a real human participant). However, in many
circumstances it is reasonable to infer tracking is taking place even without
such evidence. For instance, the presence of a known third-party tracking
domain within network traffic would strongly suggest some kind of tracking is
present on the site. For these reasons, rather than examining each individual
network request, some studies simply detect the presence of a known tracker,
based on a reference to a known tracker host (i.e. a particular domain name,
or IP address).

A major challenge with this host-based approach to tracking the trackers is
how to compile a list of known trackers. Identifying a tracker is not as
simple as looking at the domain it operates under. This might work for large,
well known trackers who operate under a single domain. But there are many
different trackers out there. Ideally, there would be a comprehensive list of
all domains, with a definitive answer as to whether they are ‘trackers’ or
not. Researchers, browser vendors and anti-tracking tool providers have been
working towards such lists. One important resource has been the Domain Name
System’s WHOIS register. This is not a single list, but rather a protocol
which is used to create an interlinked system of different domain name
registration databases. In theory, and in reality in the early days of the
web, one could look up who owns any domain, and see some basic information
about them. However over the last decade or so, increasing numbers of domain
owners hide behind domain name registrar privacy services which hide their
details [64]. Another factor is that publicly listing all domain name owner’s
details — which often constitute personal data — is not compliant with EU data
protection law. In the lead up to the enforcement of the GDPR in 2018, EU data
protection regulators, in their capacity under the Article 29 Working Party
(now re-constituted as the European Data Protection Board), instructed ICANN
(Internet Corporation for Assigned Names and Numbers, the organisation
responsible for co-ordinating DNS) to make such WHOIS information private by
default. While ICANN have been attempting to develop an alternative access
system for years, which would protect privacy whilst also making WHOIS
information available to those with a lawful basis for processing it, the
implementation of such tiered access systems by individual domain name
registrars has been uneven [65]. These factors make it hard to compile tracker
lists based on WHOIS data.

Despite these difficulties, several projects have compiled tracking protection
lists. Such lists have been compiled by open-source anti-tracking projects,
tracker-blocking tools, and researchers. Such lists include those from
Ghostery111111https://perma.cc/YP9V-A7WR, Adblock121212https://perma.cc/G6LM-
NHDG, Disconnect131313https://perma.cc/QR9F-QYHA, Adblock Plus’s
Easylist141414https://perma.cc/ZJ7X-PPPX, the WebXray Domain Owner
list151515https://perma.cc/LXL9-SJ3G, the Exodus tracker databse (focused on
mobile trackers),161616https://perma.cc/V7YN-MCEV and others. This enables
researchers to scale detection of web tracking, by narrowing down to count
only those hosts which have been identified as trackers (see e.g. [66, 67,
68]. Entries on such lists may be identified manually, which should result in
high precision. However, these lists may not be fully representative of the
trackers in existence. They may be oriented towards the particular
circumstances of the organisations and user groups who compiled them (such as
geography, sites of interest, etc.).171717Another limitation of tracking
protection lists is that they tend to be web-centric, an issue which makes
them less viable for detecting tracking on other platforms as discussed below.
They may also have different definitions of tracking; sometimes they are
advertising-oriented rather than tracking in general, and some lists make
exemptions for trackers who sign up to codes of conduct.181818See e.g. AdBlock
Plus’ ’acceptable ads’ scheme [69] Finally, such lists may miss important
trackers which use less visible tracking methods, like fingerprinting; one
study of tracking ‘pixels’ used for fingerprinting found that popular tracker
lists missed between 25-30% of fingerprinting-based trackers[70].

Another methodological difficulty for web tracking research is that third-
party behaviours can be quite dynamic. The presence of a script from one
third-party in a web page doesn’t necessarily only indicate tracking by that
single party. Once the script is run, it might trigger other third-party
dependencies, who in turn might trigger further connections (for instance, to
facilitate cookie syncing between third-party trackers). Furthermore, this
behaviour might change from one visit to the next, leading to inconsistent
results between measurements in studies which only visit / crawl each page
once. Various researchers have modelled such dynamic behaviour. Gomer et al.
construct _Referrer_ graphs, where nodes represent first and third-parties,
and edges represent HTTP(S) references between them[71]. Another way of
modelling these networks of third-parties is via ‘third-party trees’, which
measure the inclusion relationships between domains by recording the exact
provenance of HTTP(S) requests[72]. Using this approach, Urban et al. found
that a single third-party can lead to subsequent requests by eight additional
third-party services, and half of these additional third-parties change
between repeated visits to the first-party. They also found that crawling only
the landing page of a website may give an under-estimate of the third-parties
that a user would be exposed to if they browsed around the site; deeper
website crawls resulted in 36% more third parties.

###  3.2 Inferring Tracker Data Flows from Ads Served

It is hard to know how trackers work behind the scenes, especially where they
use techniques like fingerprinting or cookie syncing which aren’t observable
by just inspecting the cookies applied to a browser, or where the contents of
cookies are unobservable. This presents a difficult problem for researchers
who want to understand what data may have been collected and how it may be
used. However, where those trackers are playing a part in the behavioural
targeted advertising supply chain, it may be possible to infer what they are
doing by observing their downstream effects, e.g. the ads that are eventually
targeted to a user.

Studies have used this approach - attempting to infer what data trackers
collect from what ads are eventually shown - since at least 2012 [73, 74].
This method can also be used to detect cookie syncing. If cookie syncing is
happening, then one should expect to be able to indirectly observe its effects
as trackers behave differently when they know additional information about a
user that they couldn’t have gleaned from their own tracking network. This has
been exploited in one study of cookie syncing [34]. By setting up fake
personas which automatically browse the web, exposing themselves to different
ad network trackers, and then observing the bids that those networks place in
programmatic ad exchange auctions, the authors were able to guess which ad
networks were colluding with each other behind the scenes. For instance, say
tracker A observes a web user visiting an automotive dealer website, and then
subsequently tracker B — despite never having directly observed that persona
interacting with automative-related content — wants to bid more to target a
car advertisement to that user. We might then reasonably infer that tracker A
and B have a back-channel where they combine their respective cookie
information to inform their bidding strategies. The authors developed a
machine learning model to infer these relationships, finding evidence
suggesting several instances of cookie syncing that would not be observable
directly from the client-side.

As Bashir et al. point out, an advantage of this approach is that it is not
necessary to establish the exact method by which the data used to target the
ad was collected and shared[74]. Instead, it relies on the semantics of how
exchanges serve ads, rather than the specific matching mechanism. Since such
methods are essentially attempts at causal inference, they could also borrow
from information flow tracking methods and more generally from experimental
science and statistical analysis, as explained in [75]. Along similar lines,
Lecuyer et al. propose _XRay_ , a generic system for reverse-engineering which
data is being used to drive profile-based targeting using ‘differential
correlation’ [76].

###  3.3 Cross-border Tracking Comparisons

Various research has aimed to study the international distribution of
trackers. While many tracking companies are based in the US, there are also
many others located elsewhere. The cross-border dimensions of tracking invite
some basic questions. Where in the world are trackers located? Are web users
in some parts of the world tracked more than others? The geographical spread
of trackers that a web user is exposed to will be highly dependent on what
sites they visit, and where in the world they are located. This has
interesting legal consequences. For instance, data about an individual in one
jurisdiction might be protected to a greater or lesser extent than the
jurisdiction in which the tracker is based. Relatedly, the extent to which
third-party trackers can be used as surveillance infrastructure by passive
network traffic observers also depends on where they are located within the
global flow of internet traffic. For a national intelligence agency, the
effectiveness of attempts to piggyback on tracking infrastructure depends in
part on where in the world the wiretap is located.

According to a 2013 study of trackers on the most popular websites used around
the world, the most common location for a tracker is the US [53]. Even in
China, the majority of trackers were found to be US-based, despite China
having a significant third-party tracking industry of its own. The only
country with more local trackers than US-based trackers was Russia. Variations
in tracking between jurisdictions was studied by Fruchter et al. [5], who
studied cookies and HTTP requests from browsing sessions originating in
different countries, finding significant differences between them. A study by
Hu et al. in 2020 found that users in China tend to be tracked by fewer
trackers, less often, than users in the US [77]. Regarding the use of third-
party trackers as surveillance infrastructure by national intelligence
agencies, Englehardt et al. [63] note that given the concentration of third-
party trackers in the US, the US National Security Agency (NSA) is
particularly well placed to catch foreign users in a dragnet surveillance
effort incorporating them.

###  3.4 Measuring Legal Compliance and Regulatory Effects

A number of studies of web tracking combine large-scale measurement of
tracking, with heuristic rules to automatically detect possible unlawful
behaviour by trackers. For instance, several studies implement tools to check
whether a website sets non-essential cookies without asking for consent in a
valid way (in violation of the EU ePrivacy Directive) [78, 79, 80, 81]. Other
studies look at whether first-parties disclose the existence of third-parties
in their privacy policies as required by various laws (e.g. data protection
and US sectoral / state laws)[82]. Libert et al. propose and demonstrate a
general purpose search engine for collecting court-admissible forensic
evidence of non-compliance by trackers[83].

Other studies attempt to measure the impact of regulation on web tracking,
e.g. whether new regulations result in changes in tracker distribution and
behaviour. For instance, Urban et al. study the effect of the GDPR on web
tracking [84]. They conclude that while the structure of entities engaging in
cookie syncing has not changed, the number of third-party connections appears
to have shrunk by around 40% since the GDPR came into force.191919For similar
work comparing pre- and post-GDPR tracking in mobile apps, see [85].

##  4 Tracking Countermeasures and End-User Perspectives

This section aims to cover some of the main approaches that have been proposed
(and in some cases, adopted) to limit or prevent tracking on the web, and
research into end-user perspectives on tracking. Where alternative
countermeasures for smartphones and IoT exist, they will be discussed in their
respective sections below.

###  4.1 Tools for Notice and Consent

The original response to address unwanted tracking was to transplant the US
‘notice and consent’ model of privacy regulation to the web [86, 87]. A user,
confronted with a website that wants to facilitate tracking by third-parties,
is given notice of who these third-parties are, what data they will use, for
what purposes, and can then make a choice whether to use the website or not.
Given the large number of websites and even larger number of third-parties,
this may not be practical. A 2008 study estimated [88] that the US national
opportunity cost for reading privacy policies was $781 billion. Moreover, even
given time, privacy policies are difficult to read [89, 90] and even
contradictory[91]. Finally, the end-user privacy settings that are available
are often difficult to use, and their effects are difficult for users to
understand and manage [92, 93]. As a result, numerous efforts have been made
to automate the process of conveying tracking preferences.

####  4.1.1 Tracking Preference Standards (P3P & DNT)

These included standardisation efforts from the likes of the W3C, with
standards like the Platform for Privacy Preferences (P3P), and Do Not Track
(DNT). These mechanisms aimed to enable users to control the data flows
between their browsers and websites and third-parties. The premise was that by
giving users a way to signal to websites their preferences regarding tracking,
websites could respond accordingly. Early proposals included the idea of
intelligent user agents — software running in the web browser — which could
record users’ preferences regarding tracking and automatically mediate or even
negotiate between them and the interests of first and third-parties who want
to track them [94]. The hope was that:

> ‘Architectures like P3P make possible machine to machine communication …
> machines can bear the cost of this negotiation [and] be our agents for
> protecting our privacy’ [95]

The P3P standard was developed at the W3C in the late 1990s, and some websites
began publishing machine-readable privacy policies in the P3P format around
the turn of the century. Researchers and engineers at AT&T labs developed and
tested early prototype P3P agents, but their usefulness was limited by the
fact that very few websites had adopted the standard [96]. Browsers attempted
to encourage websites to format their privacy policies using P3P, but these
efforts backfired when websites realised they could simply provide a
technically valid policy which contained no actual content [97]. P3P was
dropped by most browsers in the mid-2000s, with Microsoft Internet Explorer
and Edge maintaining support until Windows 10 in 2015.

A later effort to standardise a method of communicating user’s preferences
regarding tracking was the Do Not Track standard in 2011 [98]. This was much
more blunt than P3P: it simply recorded whether the user did or did not want
to be ‘tracked’ and communicated this to servers with three states: 1 to
indicate the user did not want to be tracked; 0 if they did want to be
tracked, and null if the user had not yet expressed a preference either way.
This was intended to be configured once per browser, for the whole web, not on
a website-by-website basis. It was hoped that this lightweight technical
protocol would be complemented by a legal and policy infrastructure that would
both define what constitutes ‘tracking’, and put in place governance
mechanisms to ensure that trackers obeyed the signalled instructions.
According to a 2012 survey of US consumers, DNT was popular [99]. But it was
declared a failure as early as the following year [100]. Browsers eventually
dropped support for DNT around 2016. The policymaking process came to a halt
in large part due to disagreements between browser vendors, users, digital
rights advocates, first-parties, and trackers about how to define tracking,
reflecting their different interests. Indeed, the online behavioural
advertising industry appears to object to the very term ‘tracking’, as
evidenced by the Interactive Advertising Board using the term in scare quotes
in a comment on a campaign by privacy activists against tracking (described as
‘a facile and indiscriminate condemnation of “tracking”’).202020’Digital
AdvertisingIndustry Warns Against Misguided EU Regulation - IAB Europe’
https://iabeurope.eu/all-news/digital-advertising-industry-warns-against-
misguided-eu-regulation/

A fresh attempt to create a global technical standard for privacy preference
setting is the Global Privacy Control (GPC).212121https://perma.cc/26BK-N6S8
Like P3P and Do Not Track, this is a browser-configured global opt-out signal;
proponents argue that websites are obliged to respect GPC signals under the
California Consumer Protection Act (CCPA) and the GDPR. It remains to be seen
whether this latest incarnation of a global privacy preference standard will
be successful, but it has been backed by the California Attorney General. Some
might question whether a user interaction which indicates consent to tracking
(e.g. by clicking ‘accept’ on a consent dialogue box) should take precedence
over a global browser-defined setting, since it is an affirmative action;
however, the fact that such dialogue boxes often use dark patterns to coerce
acceptance [79, 101] might lend the global browser setting more authority.
Finally, another recent proposal in a similar vein is the ‘Advanced Data
Protection Control’ standard, proposed by NOYB, a European data rights
organisation; this aims to provide for more fine-grained and flexible browser
consent signals particularly suited to E.U. data protection law. Whether these
new initiatives can succeed where previous ones have failed remains to be
seen. One thing counting in their favour this time are explicit legal
provisions for their use; e.g. for those users wishing to exercise their right
to object under the GDPR, Article 21(5) ensures that ‘the data subject may
exercise his or her right to object by automated means using technical
specifications’ (such as browser settings).

####  4.1.2 Privacy Policy Languages

Despite the failure of previous attempts to standardise protocols for
communicating privacy and tracking preferences, researchers and others have
nonetheless pursued various kinds of formal languages for describing privacy
and tracking-related policies. These have a variety of uses, from summarising
policies on behalf of users, to analysing and auditing the stated practices of
trackers.

Some projects, like TOS-DR (‘Terms of Service; Didn’t Read’) crowdsource the
annotation and highlighting of key clauses in terms of service and privacy
policies[102]. This approach has also been explored in research, where crowd-
sourced classifications of policies could be used as training data to train a
machine learning classifier to recognise the content of previously
unclassified privacy policies, enabling them to be summarised and made more
comprehensible [103, 104].

The widespread adoption of standardised or semi-standardised privacy policy
formats would not only be useful for end-user consent tools. It could also
enable large scale automated evaluation of different websites, which could
provide insights into trends and practices, automatically identify outliers,
and other kinds of analysis (such possibilities are explored in other contexts
where standardised privacy notices were adopted, e.g. financial institutions
[105]). Even when privacy policies are not standardised in this way, natural
language processing techniques can be used to identify disclosures of tracking
practices, e.g. [82, 106, 107]. Various projects aim to define formal semantic
languages to represent privacy-related information; for an overview, see
[108], and a recent example, modelled around data protection regulation, see
[109].

###  4.2 First-party Limitations on Tracking

While first-parties are often to a large extent dependent on third-parties for
parts of the functionality of their websites, as well as for their revenue via
advertising, there are still ways in which they can limit third-party tracking
without necessarily hurting their operation and bottom line. At the very
least, first-parties can audit their own websites to ensure that any user data
extracted by third-parties is in line with their expectations and policies.
There are several methods for monitoring data flows at runtime and ensuring
they are secure [110]. An early overview of such techniques and a review of
the enforcement of privacy and security policies by web developers is provided
in [111]. More straightforwardly, many of the functions that are currently
outsourced to third-parties could potentially be hosted by first-parties
themselves, to protect the privacy of users, for example using self-hosted
analytics rather than third-party analytics[112, 113].

In the last decade, numerous companies have emerged which offer tools for
first-parties to audit their own sites to identify and manage the third-party
resources they use.222222See e.g. QuantCast, OneTrust, TrustArc, Cookiebot,
and Crownpeak. Some use these audits to automatically generate privacy
policies for the first party, which describe the third party trackers. More
recently, many have offered so-called ‘consent management platforms’; pop-up
consent boxes designed to facilitate consent interactions from the user on
behalf of the first party. Whether these privacy policy-generators and consent
management platforms actually meet the legal standard for consent under EU
data protection law is questionable [79]; it is also unclear whether they or
the first party are ultimately responsible for ensuring such compliance [114].
However, given that existing web infrastructure and web development practices
are so heavily tilted towards third-parties, there is a clear need for better
tools to enable first-parties to limit and manage such issues.

###  4.3 Tracker Blocking and Obfuscation

Both tools for notice and consent, and first party limitations on tracking,
rely on first parties to take action against the interests of third parties.
But given that first parties are often dependent on third party services for
their revenue, such action is often lacking. As a result, unilateral methods
of preventing tracking, which block trackers at a technical level via the
browser, have instead proven popular.

Tracker blockers have been implemented both by specialist browser plugins like
Ghostery, Disconnect, Adblock, Adblock Plus, Privacy Badger, and others, as
well as in-built controls within the browsers themselves.232323There are also
other unilateral methods which prevent tracking at the local network level;
see section 5.2 Users of specialist tracker-blocking software are more
privacy-motivated and digitally literate than average [115], although they do
not always have good mental models of how these extensions actually work
[116]. Regardless, tracker-blockers do provide meaningful protection with very
little effort on the part of users, with users reporting only occasionally
encountering websites which do not work when the tracker-blocker is
enabled[116]. Where specialist browser plugins have ventured to offer new,
more aggressive means of tracker-blocking, browser providers have largely
followed; Safari and Firefox block third party cookies by default, and Chrome
has announced it will follow suit in 2022 (although similar commitments in the
past have not been upheld).

Dedicated tracker blocker tools can work in a variety of ways. Some block
network traffic at the operating system level, so they work beyond a specific
browser.242424E.g. MVPS, “Blocking unwanted connections with a hosts file,”
2015, https://perma.cc/NM8U-T3T6, and P. Lowe, “Yoyo hosts file,” 2015,
https://perma.cc/4TR6-SVX4. An advantage of this is that trackers can be
blocked regardless which browser or other application is being used; this
could, for instance, help stop the kind of email tracking discussed above if
the user were to be using a native email client. The disadvantage is that they
block entire domains or subdomains, rather than specific URIs: e.g.
thirdparty.com would also block thirdparty.com/privacypolicy.

However most tracker blocking is browser-based. Initially, it was not tracker-
blocking but ad-blocking plugins that were popular. Ad blockers like _AdBlock
Plus_ block the loading of programmatic web ads so users don’t see them on the
page. This doesn’t necessarily mean they prevent tracking. Adtech platforms
which both distribute ads and track users to enable ad targeting, might still
collect the data even if the ad blocker blocks it from showing ads. However,
tracker blockers, like _Ghostery_ , _Privacy Badger_ , and _Disconnect_ ,
display trackers that are present on a page and allow users to block them.

There are different approaches taken by different tracker blockers to
determine what constitutes tracking, and how they detect trackers. As
explained in section 3.1 above, there are large and relatively comprehensive
lists of tracking hosts which have been built by tracker-blocking projects and
researchers. An 8-year study of EasyList, one of the most popular curated
lists, found that there were often errors in the list (e.g. non-tracking sites
which were wrongly identified as trackers, and vice-versa) which took
substantial time to be corrected despite the list owners being notified [117].
Community-curated lists also often contain idiosyncratic rules that are ill-
defined and documented by a small number of contributors, which can lead to
outdated, ineffective or superfluous tracker-blocking behaviour [118].

In addition to community/company derived rules, there are also algorithmic
approaches, which use statistical and machine learning methods to identify
trackers[119, 120]. For instance, Privacy Badger and Ghostery both rely on an
algorithmic approach, which automatically classifies trackers based on
detecting similar patterns of high-entropy strings being sent by multiple
first-parties to a single third-party [67]. A study of tracker blocking in
2017 found that (some of) the rule-based trackers performed better than the
algorithmic ones; that trackers with a smaller footprint (i.e. present on
fewer sites) were more likely to evade tracker blockers; and that all had
blind spots when it came to identifying and blocking fingerprint-based
tracking, and tracking by third-party content delivery networks [121].

While earlier studies suggested that the algorithmic approach to tracker
identification might be less successful than manually-curated tracker lists,
more recent research and real-world deployments have used machine learning to
identify trackers at scale. For instance, Iqbal et al. use a graph-based
machine learning approach [122]. They represent the HTML, network requests and
javascript behaviour of a webpage as a graph, and use this in combination with
existing manually curated lists of trackers as ground truth to train an ML
model that classifies trackers. Others have explored machine vision to detect
adverts as visual elements on a page and block them[123]; however, this only
blocks adverts, rather than blocking tracking infrastructure in general.
Apple’s Safari browser has begun to deploy statistical and machine learning
approaches to detect trackers, an approach it calls ‘Intelligent Tracking
Prevention’ (ITP). Using statistics on resource loads, user interactions, and
other data, it infers whether a host is a tracker or not. Cookies from hosts
deemed to be trackers are then blocked from third-party use after one day
since the user interacted with the website, and then automatically deleted
entirely after 30 days. ITP has had a real impact on trackers’ bottom line.
The CEO of Criteo, an adtech firm heavily reliant on third-party tracking,
attributed the firms loss of over 20m revenue to
ITP252525https://perma.cc/G694-YNVQ.

Tracker blocking has of course not gone unnoticed by trackers themselves, who
have developed a range of _counter-_ countermeasures to address it. Some
attempt to detect when a user is using an ad or tracker blocker, and thus
enable the first-party to refuse to serve the page content until the user
disables their blocker [124]. Others attempt to circumvent blockers. For
instance, a bug in the Chrome browser meant that ad blockers could not
intervene on connections opened up over WebSocket (a low-overhead alternative
to standard HTTP/S); a study found that a small but persistent group of
trackers exploited this bug by routing their traffic through web sockets,
until the bug was fixed [125]. Taking the arms-race to another level, Zhu et
al. aim to detect attempts by trackers to detect tracker-blockers by using
‘differential execution analysis’[126]. By comparing the behaviour of a
webpage when visited with and without an adblocker, the counter-
countermeasures used to detect ad blockers can be isolated, and thus _counter_
-counter-countermeasures can be developed.

Tracker blockers have traditionally been designed to work against cookies, and
as a result have struggled to grapple with cookie-less tracking techniques
(i.e. fingerprinting). Even worse, the fact that a user has installed a
tracker blocker plugin might even be used by a fingerprinter as an additional
identifying feature, as observed by Nikiforakis et al. [52].

In addition to tracker-blocking tools which _prevent_ the flow of data to
trackers, some have proposed an alternative approach of introducing
deliberately false data into the tracking ecosystem, a practice known as
_obfuscation_ [127]. The _AdNauseum_ project aims to do this in the context of
behavioural advertising [128]. It is a browser plugin that automatically
randomly clicks on ads in the background while a user is web browsing, to
pollute their inferred interest profiles with things they aren’t actually
interested in. Another study of obfuscation, focusing on the tracker BlueKai
(owned by Oracle), found that injecting just 5% fake traffic in addition to
real traffic is enough to meaningfully alter the interest profile a tracker
compiles about a user [129]. While such deceptive practices may appear
malicious, Van Kleek et al. argue that there are many potentially beneficial
uses of what they call computationally mediated pro-social deception [130];
tricking the trackers might therefore be considered within the category of
‘benevolent deception’.

###  4.4 Privacy-preserving Alternatives

One of the most commonly-cited objections to tracking is that it is highly
privacy-invasive. But what if the underlying ends of tracking could be
effectively achieved, in less privacy-invasive ways? Several proposals aim to
do this using ‘privacy-preserving’ techniques; they enable some of the same
functions — targeting adverts, differentiating between users, enabling
aggregate insights — but without a third-party (or even first-party) ‘seeing’
an individual’s data.

Privacy-preserving ad targeting aims to enable adverts and content to be
targeted at individuals based on their behaviour and interests, without such
data actually being revealed to any adtech intermediaries or advertisers. For
instance, Hadadi et al. propose a system wherein a user interest profile is
created locally, on their own device, and a range of possible ads are selected
from locally based on that profile [131]. Davidson et al. similarly propose
local models for personalisation based on user personas on the Windows mobile
operating system [132]. Other proposals use techniques like private
information retrieval[133], a cryptographic protocol which allows items to be
retrieved from a database without revealing to the database owner what those
items are[134]. There may even be ways to achieve ad conversion measurement in
ways which don’t reveal any individual user data (see e.g. [135] and Apple’s
‘Privacy Preserving Ad Click Attribution For the
Web’262626https://perma.cc/Q33U-VRCH).

Whether these approaches really address the ethical concerns with tracking is
questionable. If the issue with the surveillance-based web is that it enables
behavioural data to be associated with an explicit, identifiable individual —
the ‘privacy as confidentiality’ paradigm — then these approaches represent a
promising alternative. But if the issue is instead that it enables
corporations, governments and other, even less accountable actors to
manipulate and misinform the public, or to discriminate against groups (even
if they don’t know which individuals are in those groups), or more broadly to
shape the information environments and choice architectures of billions of
people, then arguably it doesn’t matter whether they can access personal data
while doing so. As such, these privacy-preserving approaches may not be the
answer to the broader political concerns that tracking raises [136, 137, 138].

###  4.5 End-User Perceptions, Expectations, and Choices

A motivating assumption for much of the research into the detection and
mitigation of tracking is that it presents risks to those tracked. But further
investigation into how the _subjects_ of tracking understand, perceive, feel
and respond to tracking is important to help ground empirical research, the
design of countermeasures, and regulatory responses. Substantial research in
this vein has been undertaken within human-computer interaction (HCI) research
over recent decades [139, 140, 141].

Privacy concerns appear to vary internationally [142], by age cohort [143],
and between iOS and Android users[144]. Attitudes towards data flows are also
influenced by the context(s) from which the data are drawn, as well as the
type of data being disclosed, perceived norms around disclosures, individuals’
relationships with the data recipient(s), and the purposes of disclosure [145,
146, 147, 148, 149, 150, 151]. When their expectations are violated, e.g. by
data being sent to opaque third-party trackers in unanticipated ways, people
feel ‘creeped out’, and when people become accustomed to the reality of such
unwanted data flows, such feelings transform into helplessness and resignation
[152, 153]. Attitudes to tracking are typically placed within the broader
theoretical frameworks of privacy. These include conceptualisations of privacy
as control over information about oneself or ‘informational self-
determination’ [154, 155], and ‘contextual integrity’ [156], according to
which privacy norms regulate the transmission of information between various
contexts, between actors, concerning certain attributes, according to certain
transmission principles appropriate to those contexts [157, 158, 159].

Early research into privacy attitudes suggested that people may divide into a
small set of distinct privacy ‘types’ [160, 161], including ‘privacy
fundamentalists’ who avoid disclosing their information at all costs,
‘pragmatists’ who make calculated tradeoffs between privacy and benefit, and
‘unconcerned’ who are willing to give away their personal information for
little or no benefit. One might expect these broad categories to predict
people’s (intended or actual) behaviours in specific situations; however,
later research has found no significant correlations between the two [162].
Furthermore, the relationship between preferences, intentions, and behaviour
is complicated and fraught, especially in the context of the ubiquitous and
opaque tracking described above. Some studies purport to show discrepancies
between people’s stated preferences and their behaviour, such that someone who
claims to care about privacy might later behave in a way which suggests they
don’t. Various attempts have been made to explain (and explain away) these
differences [163, 164, 165], with some concluding that researching privacy in
experimental isolation is unhelpful [166], and that privacy attitudes are
relatively unpredictable across different scenarios [162, 167]. While people
appear unwilling to pay tangible economic costs for privacy, as evidenced by
the popularity of free over paid services (and experimental results [168]), it
is also not clear that paid alternatives are actually more privacy-
protective[169].

While it might seem obvious that targeted advertisements are preferable to
non-targeted ones (and some research supports this[170, 171]), this needs to
be weighed against the reality of the tracking infrastructure that comes along
with targeted advertisement which may be less desirable. A survey commissioned
by the UK data protection regulator found that 63% of participants found
digital advertising acceptable to fund free content, but after explanation of
how real-time bidding works, this fell to 36% [172]. This illustrates how
privacy preferences, intentions and behaviours that we observe in people need
to be interpreted alongside the level of awareness, understanding, competing
pressures, incentives and choice architectures that people face in real-world
contexts[173]. Stated privacy attitudes and preferences may not predict
behaviour because people may lack an adequate understanding and awareness of
privacy risks associated with certain technology use. Various studies
demonstrate how even technically savvy users may lack a complete understanding
of all the ways their data is being transmitted and used, whether via the Web,
through smartphone platforms and apps, or connected devices in the home [174,
175]. Given the complex nature of online behavioural advertising, it is no
surprise that users lack accurate and complete mental models of how it
works[176, 177].

One of the reasons people don’t take further action against privacy-violating
tracking is the infeasibility or unavailability of alternatives [178]. Without
awareness of privacy controls, and more importantly, belief in their efficacy,
people are unlikely to take action (a conclusion also found in relation to
security behaviours[179, 180]). However, people’s level of concern about and
desire to limit data flows can change once they are made apparent in a form
that users can understand. Several studies develop privacy awareness tools,
which visualise data flows involved in web and mobile tracking and reflect
back to people how their data is used[181, 115, 182, 183, 184, 185]. Given
these tools, study participants were able to articulate more specific and
actionable privacy preferences [181, 115, 182], as well as views on ethical,
economic (business models), and political dimensions of the data economy [183,
184].

Parents and children face particular challenges to understanding and
responding to tracking. Various work seeks to understand how parents and
children communicate and develop privacy preferences, with important
differences between teens [186] and younger children [187, 188]. Educating
children about privacy risks and improving their literacy can be effective in
changing their online disclosure behaviour[189], although the aforementioned
lack of tools to easily control tracking may ultimately hamper effective
action.

##  5 Tracking on ‘Smart’ Devices

The web is where the practices of third-party tracking first arose, but a
similar model has been deployed beyond. On smartphones, there are large app
ecosystems which have their own extensive array of trackers. The advent of the
‘smart home’ and ‘Internet-of-Things’ devices also present new prospects for
ubiquitous tracking. This section addresses tracking on these various non-web
platforms and devices.

###  5.1 Smartphones and Apps

While tracking on smartphone apps has much in common and shares similar
infrastructure to web-based tracking, there are some important differences.

####  5.1.1 Apps vs Browsers

The main difference between smartphones and the web is that on smartphones,
the web browser is just one app amongst many. Web tracking therefore co-exists
alongside app tracking on smartphones. Web tracking on mobile browsers is
largely the same as on other devices, but there are some differences. Early
studies of mobile web tracking from 2013, when smartphones were just beginning
to overtake their ‘dumb’ predecessors in rich countries, confirmed that web
users were being tracked similarly regardless whether they used a mobile or
desktop browser. Notable differences at the time were the comparatively
smaller number of mobile-specific third-party trackers, and the (then mostly
theoretical) possibility of being able to access more data from the smartphone
that would otherwise be unavailable (e.g. location) [190].

In the years since, the availability of smartphone sensor APIs including
motion (via accelerometers), position (via magnetometers), and environmental
features (air temperature, humidity, light, etc), have presented an additional
set of vectors for tracking mobile web users. A study of mobile web tracking
found that 63% of the scripts that access sensor APIs — while often for a
legitimate purpose - also engage in fingerprinting using those sensor readings
[191]. These add additional bits of entropy which enhance the ability of web-
based tracking on mobile web browsers.

However, the bigger difference in tracking on mobile devices is the tracking
involved in native mobile applications, which have access to the
aforementioned sensor data and much more. These are built on top of the
Android or iOS platforms and interact with profiling technologies in different
ways. While mobile apps are sometimes developed using web technologies, they
are more often developed in OS-specific development environments and languages
(e.g. Swift for iOS and Java for Android), rather than the standards and
programming languages of the web (e.g. Javascript, HTML and CSS). The main
ways in which tracking on apps differs to web tracking are: the types of data
available; the app distribution model; the operating system configurability;
and the use of advertising identifiers rather than cookies.

The types of data available on a mobile present different opportunities for
trackers. Mobile devices frequently move around in physical space, so location
and sensor data as described above provide valuable data for tracking purposes
- both as a means of singling out an individual user, and to infer behaviours
and interests to add to a profile for targeting purposes. Other information
that might be read from a phone by an app include a list of the user’s
contacts in their phone book, the handset model and other device information,
and a list of the other apps that the user has installed. The latter may sound
innocuous but the list of apps someone uses can often uniquely identify them,
making it an effective fingerprint in its own right [192].

The mobile app distribution model is also substantially different from the
web. On the web, a web application hosted anywhere can (by and large) be
accessed by anyone, largely without interference from gatekeepers. But mobile
apps need to be packaged up by developers, distributed somehow, and installed
by users. In theory, this could be done without going through the main
official app stores run by Apple and Google; for instance, the alternative
F-Droid app store for Android distributes apps not approved by Google on the
official Play Store,272727See https://perma.cc/Z6Q8-KYMT and users can ’side-
load’ app files directly. But the vast majority of apps are installed via app
stores. And in most parts of the world (outside of China, where most users use
multiple app stores [193]), most smartphone users have only one app store from
which to download apps: the official app store of their chosen OS. As a
result, Apple and Google have the ability to act as gatekeepers [194].
Providers have the power to effectively exclude apps based on their practices.
Early studies demonstrated that this gatekeeping role was not being used to
prevent apps leaking personal data[195]. But iOS and Android do limit what
developers can do in various ways, and have increasingly built in greater
privacy controls for end users and restrictions on app developers with respect
to tracking. These controls operate at both a technical level - by restricting
the ways that OS-level APIs can be utilised by apps - and at an
infrastructural / contractual level by deciding which apps are allowed to
appear on the iOS app store and Google Play store.

Another major difference is the increased ability of app developers to utilise
the functionality of the mobile operating system compared to the web. Web
browsers and web standards determine how resources are rendered, what scripts
are run in what order, and so on (like the SameOrigin policy). Equivalent
limits are not placed on mobile apps, which have tended to have more power to
control a user’s device than websites. While apps are ‘sandboxed’ from each
other to prevent apps from reading / writing between each other without
permission, within their own sandbox apps can generally run whatever code and
allow whatever network connections the app developer builds into their app,
given the permissions the developer has requested.282828Although, developers
can and frequently do circumvent the permission model, through side-channels
(where one app obtains data that it does not have permission for) and covert
channels (where an app obtains data via another app which does have permission
for such data); see [196]

At the same time, users themselves have very little ability to modify their
own device, including in ways which might limit tracking by apps. User access
to lower-level operating system functions generally requires an additional,
non-standard layer of permission. This is known as being ‘rooted’ (Android) or
‘jail-broken’ (iOS). The process is not straightforward, and may void the
device warranty. Many apps attempt to detect whether a device is rooted, and
will not run on it if so. As a result of this, the available tracker-blocking
tools on smartphones are far behind the equivalent plugins available for web
browsers, although some exist through their app store policies. The ability to
block tracking is directly limited by OS providers themselves in some cases.
_TrackerControl_ , an app which reveals trackers on mobile apps, illustrates
this point.292929https://perma.cc/73TX-SKCW It has two versions. One version
is available on Google Play, and can show the user what trackers are present
on different apps. The other version has the ability to also _block_ trackers,
but has to be loaded from the alternative Android app marketplace ‘F-Droid’ as
the Google Play store refuses to allow apps which enable such blocking.

####  5.1.2 Mobile Advertising Identifiers

Perhaps the biggest difference in smartphone tracking is the use of
specialised, OS-defined advertising identifiers instead of cookies. The first
generation of mobile third-party trackers would typically extract all manner
of identifiers that are permanently associated with the smartphone device.
These included the International Mobile Equipment Identity (IMEI) number
associated with the device itself, the International Mobile Subscriber
Identity (IMSI) number associated with the SIM card issued by the cellular
network, the phone number, the device identifier, the MAC address used for
connecting to WiFi networks, and others (see [197] for how third-parties are
able to access these identifiers). The use of these different identifiers is
highly problematic, since they often cannot be re-set and are strongly
associated with the user and their accounts (e.g. with their cellular network
account). To address this problem, both iOS and Android introduced separate
‘advertising identifiers’ (on Android, the Android Ad ID (AAID); on iOS, the
Identifier for Advertisers (IDFA)) for the purposes of third-party tracking.
At the same time, they have made efforts to block off access to the other
identifiers both at a technical level and through educating and warning
developers against such practices, and enforcing their policies through their
app stores. These Ad IDs can be re-set by the user; re-setting has the
intended effect of breaking a tracker’s ability to link between the user’s
previous and future activity.

In addition, both platforms created settings where users can limit access to
the Ad ID. On iPhones, the ‘Limit Ad Tracking’ option prevented app developers
from being able to request access to the user’s Ad ID. This has since been
replaced by a new mechanism on iOS. From iOS version 14, under the Apple
Tracking Transparency (ATT) framework, app developers are required by Apple to
request explicit consent from users for tracking. iOS users are faced with a
permission screen asking them to ‘ _allow [the app] to track your activity
across other companies’ apps and websites_ ’. The user can either click ‘ _Ask
App Not To Track_ ’ or ‘ _Allow_ ’, and both options are equally prominent on
the screen. When a user selects the first option, access to the IDFA commonly
used by trackers is denied (initial estimates suggest between 60 and 95%
choose this option [198, 199, 200]). The move proved highly controversial with
third-party trackers; prominent critics included Facebook, who paid for a
series of adverts in (non-targeted, paper) newspapers extolling the importance
of its tracking-based targeted advertisements for small businesses through the
Covid-19 pandemic. Initial reports suggest the third-party tracking industry
is right to be concerned; Facebook’s own figures suggest 80% of their users
will choose to not be tracked. While circumvention is possible through
alternative forms of tracking which don’t rely on the IDFA (e.g.
fingerprinting303030See e.g. https://perma.cc/46QY-PJMX), cutting off access
to the IDFA will likely significantly disrupt current tracking practices.

Google have tended to lag behind Apple on such measures, but have gradually
implemented some similar options. The Google Play Store states that the Ad ID
should be used for ‘advertising purposes’, and like the previous iOS approach,
Android gives users the ability to set a preference to ‘opt out of
personalisation’. However, the function of this setting was historically
somewhat ambiguous. Developers are still technically able to access the Ad ID
if the user has opted out of personalisation, but are required as a matter of
Google Play Store policy to not use the Ad ID for personalised advertising
purposes if this opt-out had been set by the user. However, developers could
_still_ use the Ad ID for other purposes, such as analytics, fraud detection,
and potentially other kinds of tracking, provided they have a privacy policy
covering such uses.

This rather vague and difficult-to-enforce policy on Android offered less
reassurance than the technical measures deployed by Apple which cut off access
to the IDFA entirely for users who opted out. Starting in 2021, Google
announced that they will no longer be relying on developers honouring the Play
Store terms, and instead be blocking access to the Ad ID at the API
level.313131https://support.google.com/googleplay/android-
developer/answer/6048248#zippy=%2Ctargeting-devices-without-an-advertising-
id%2Cpersistent-identifiers-including-android-id Developers will be required
not to connect data to a previously obtained Ad ID if the user has now removed
the Ad ID from their device (although it is unclear how this will be
enforced). Google also announced that they will provide alternative app-set
permanent identifiers for ‘essential’ non-advertising purposes like analytics
and fraud-detection to smooth the transition away from reliance on the Ad ID.
New measures will be put in place to prevent remote code being loaded during
run-time that could be used to circumvent Play Store policies. From April
2022, Google will require developers to provide accurate information on the
personal and sensitive data they collect. It remains to be seen how much
control users will have over these alternative permanent identifiers and how
closely their use will be monitored and how effectively the purpose
limitations will be enforced.

The ready availability of these identifiers has meant that tracking of mobile
users across apps is in many ways a much simpler affair than tracking users
across the web. Cookies are unnecessary, because devices have readily give up
unique identifiers across different apps, with no need for a third-party to
set their own unique identifier. Fingerprinting of mobile devices is also
largely unnecessary for the same reason, although some trackers do now offer
mobile fingerprinting services and make use of mobile sensor data as described
above. Such services may become more common as more users decide to make use
of the protection mechanisms available to them (i.e. making use of the ATT
options on iOS, or re-setting their Ad ID on Android). Fingerprinting mobile
devices may in some ways be harder than fingerprinting desktop devices, due to
the fact that at the device level, mobile devices have less variety and are
more standardised, but they are still ultimately eminently fingerprint-able
[201].

####  5.1.3 Third-party Mobile SDKs

In much the same way that third-party tracking on the web relies on first-
party developers embedding third-party code in their websites (or remotely
loading it during a session), third-party tracking in mobile apps relies on
developers embedding third-party code in the form of ‘libraries’ and ‘Software
Development Kits’ (SDKs) [202]. Many of these SDKs are set up so that by
default they connect to a third-party server and start sending personal data
to it. This is made easier by the fact that permissions in Android are given
on a per-app basis, rather than per-third-party tracker. As such, there is no
way for users to grant permission to a first-party app developer but withhold
permission for a third-party tracker embedded on that first-party app.
Additionally, apps typically ratchet up the privacy-risking permissions they
request over the lifetime of their installation, making additional requests on
average every three months [203]. This means that even if a user were to
carefully consider whether they would grant requested permissions to an app
before installing it, they cannot easily prevent onward use of such
permissions by third-parties and are likely to be subjected to further
sensitive requests after installation anyway.

Third-party trackers have taken advantage of such favourable conditions on
mobile apps. Large-scale measurement studies of tracking on mobile apps have
revealed a rich and varied third-party tracking ecosystem [204]. Many of these
have been used to facilitate location-based ad targeting[205]. A study of the
use of the Facebook SDK in Android apps, by Privacy International [206], found
that 61% of apps with the Facebook SDK automatically transfer data to Facebook
the moment a user opens the app. This is regardless of whether they are logged
into Facebook and even if they don’t have a Facebook account. This means that
Facebook knows immediately that a user has installed a particular app, even
before any other data is transferred. Given the sensitivity of certain apps
observed in this study - including a Muslim prayer app, a menstruation logging
app, and apps aimed at young children - this alone could be quite revealing.
The Android Ad ID was typically also automatically transferred, and many apps
also send highly detailed and sensitive data to Facebook without asking the
user. A more recent study of the same phenomenon found apps contact 4.7
trackers on average upon launching, without any user interaction [207].

####  5.1.4 Mobile Tracking Detection Methodology

As with large-scale web privacy measurement, a variety of methods exist for
detecting third-party trackers in apps. One approach, which is similar to web
tracking measurement methods, involves ‘dynamic’ network traffic monitoring.
This involves setting up a real or virtual mobile OS, inspecting network
traffic from the device and identifying any third-party destinations that
relate to tracking. This can be achieved in different ways. One common
approach has been OS-level instrumentation, with tools like TaintDroid [208],
and AppTrace [209]. An alternative is to analyse all communications traffic
transmitted by an app whilst it is in use [210]. In either case, apps must be
used in order to trigger the tracking behaviour of interest. This can be
acheived through simulated interactions via UI ‘monkeys’ - bots programmed to
interact with the app like a real user would [211, 212] \- or through real
user interactions with network traffic routed via a VPN [213, 197, 214].

An alternative approach is to use ‘static’ methods. These involve unpacking an
application’s source code (on Android systems, this comes as an Android
application package(APK)) and detecting the use of third-party tracking within
the source code [215, 216, 195, 217]. Methods for detection vary, from simply
searching for known tracker-associated hostnames to more complex machine
learning approaches. The static methodologies can scale more easily as apps do
not need to be actually run and interacted with in order to detect the use of
third-party trackers. This means that analysis can be completed on an app
within seconds rather than the minutes required for a real or simulated user
session in the dynamic approach.

However, both methods are likely to over and under-state the presence of
certain trackers. Dynamic approaches may miss third-party trackers that are
embedded in the app if they fail to trigger the relevant user interactions or
do not run for long enough. Static approaches may fail to identify trackers
which are dynamically loaded from a remote server during run-time and
therefore do not appear in the static code analysis. Furthermore, static
approaches may struggle to detect the presence of third-party tracking
libraries where the developer has obfuscated the app code. Some methods
attempt to defeat such obfuscation attempts, e.g. using machine learning
[218].

To understand the relative strengths and weaknesses of these two approaches,
Binns et al. directly compared dynamic and static approaches on a set of 200
apps[212]. They measured the extent of overlap between the two approaches, and
how many trackers are left out by each approach. They found that on average,
dynamic methods yielded 2.26 trackers which the static methods did not detect.
Static methods yielded an average of 4.85 trackers which the dynamic methods
did not detect. The average size of the intersection of mobile and web
trackers found by each method was 2.9. While the static method had a higher
positive rate, it is not possible to conclude that one method is better than
the other without ground truth on the proportions of true positives detected
by either method. Nevertheless, it gives some indication of the results that
can be expected by either method.

####  5.1.5 Distribution of App Trackers

Both dynamic and static methods have been deployed to study the distribution
of third-party tracking on mobile apps [212, 197, 219]. A consistent finding
is that, like the web, there are a few companies which have very large
prevalence across first-party apps. Alphabet / Google is consistently
identified as the most prevalent and prominent on both platforms. Recent
studies estimate that over 85% of Android apps communicate with Google /
Alphabet services [220, 221], with Facebook a distant but comfortable second.
The dominance of these two trackers on Android has been well established and
confirmed in multiple large scale studies of the Google Play Store, beginning
in 2014 [222].

Large scale studies of the distribution of trackers tend to focus more on
Android, in part because of the difficulties in studying iOS apps due to the
locked-down nature of the iOS system. However, some such studies exist. A 2011
study applied static analysis methods to iOS apps, finding more than half
collected unique device identifers and 55% contained advertising or analytics
libraries[223]. A 2013 study of 226,000 iOS apps found that many apps access
device identifiers, location and contacts [224]; subsequent iOS releases
implemented permission requests to make such access conditional on user
consent. Further studies have compared both mobile OS ecosystems against each
other (e.g. [225, 226, 221]). While Kollnig et al. found that the number of
third party trackers present in iOS apps was somewhat lower than Android,
neither platform was a clear ‘winner’ on any of the facets of privacy studied
[221].

####  5.1.6 Comparing App Tracking Against Web Tracking

One finding of large scale third-party tracking studies is that the
distribution of trackers differs between the web and mobile. There are some
trackers which are unique to mobile apps, and others which are unique to the
web [212, 197, 219]. This means that existing web-focused lists of trackers
have good coverage of the tracking ecosystem on the web, but have low coverage
for trackers in the mobile tracking ecosystem [219]. As with the web, mobile
trackers are used for different purposes, from targeted advertising, to
analytics, to security and more. Inferring the purposes of different trackers
can be challenging, although it is often possible to infer their purpose from
the way developers name functions and create URL paths, and metadata e.g.
about the domain name. Several proposals aim to automatically infer such
purposes from such information using machine learning [211, 227].

Some studies have compared the extent of third-party tracking between web and
mobile [68, 228]. While neither platform is clearly better or worse than the
other, there are meaningful differences between them. A comparison of 50
websites and their app equivalents found that while the website version of a
service connected to more third-party domains, more device identifiers were
leaked by apps [228]. For certain services, the app or the website offered a
less privacy-invasive option, but there was no clear winner. A comparison of
300 services with both web and app versions found similar numbers of trackers
between platforms, but quite different trackers were used[212].

####  5.1.7 App Tracking and the Law

Several studies have examined app tracking behaviours in light of regulatory
requirements on app developers and third-parties. Reyes et al. found that a
majority of the most popular free children’s apps in the US are likely in
violation of federal privacy law (Children’s Online Privacy Protection Act
1998 (COPPA))[229]. The violation is due to third-party SDKs which, while
capable of being configured in a COPPA-compliant way, are typically configured
by children’s app developers in ways which enable unlawful tracking and
behavioural targeting of children. The researchers also found that 19% of
these apps use SDKs whose own terms of service outright prohibit their use on
apps targeted at children.

In the context of EU data protection law, several studies have raised alarms
around potential non-compliance by apps, trackers and platforms. Several
studies suggests that many apps share data with trackers based in
jurisdictions outside the EU, which are not deemed ‘adequate’ by the European
Commission in their protection of personal data and apparently without
necessary legal protections in place [230, 197]. Apps aimed at children are
often those with the highest numbers of trackers[230], despite the European
Data Protection Board advising that profiling of children for marketing
purposes should be avoided.323232‘Because children represent a more vulnerable
group of society, organisations should, in general, refrain from profiling
them for marketing purposes’ [231] Finally, many apps which are required under
GDPR and the ePrivacy Directive to seek consent before accessing data on a
user’s device, access such data without seeking consent and immediately share
it with multiple third-party trackers (as found in studies mentioned
above[206, 207]). Despite hopes that the introduction of the GDPR in 2018
would reduce the extent and distribution of third party trackers, a large-
scale comparison of the Google Play Store before (2017) and after (2020) found
very little change in their distribution on Android apps[85].

####  5.1.8 App Developer Incentives

While end users have some power to change tracking practices, by refusing to
use services with unwanted tracking, user pressure is ultimately unlikely to
result in meaningful change given the rampant level of tracking across most
first-parties and the practical necessity of using certain services to engage
with essential services. As such, first-parties, and specifically the
developers who make design choices about which third-party trackers to
include, may have more influence over the extent of tracking in practice.
Privacy researchers seeking an alternative point of leverage for addressing
the negative externalities of third-party tracking have therefore sought to
understand developer’s reasons for integrating third-party trackers, their
understanding of the privacy implications for their users, and the usability
challenges they might face in adopting more privacy-preserving alternatives
[232]. This is part of a broader effort to study developer perspectives as
they are increasingly recognised as being key to better security and privacy
[233, 234].

In the first major study of smartphone app developers in 2014, Balebako found
that while third-party tracking SDKs were ubiquitous and heavily used,
developers often were not even aware of the data collected by these tools
[232]. More recent studies suggest that while developers are now more aware
that by using third-party SDKs they are subjecting their users to potentially
sensitive and invasive data flows, they see no other way to monetize their
apps[235, 236]. They are resigned to the existing business models, and
typically do not alter the tracker SDKs default, privacy-violating
configurations. Even in the more sensitive context of children’s apps, while
developers do respect children’s rights, they often feel they have no other
viable business model than monetising user data through third-party SDKs
[236]. Furthermore, the guidance provided by third-parties to developers is
often lacking in detail and appears deliberately vague on how they are
expected to implement the third-party tracking technology in legally compliant
ways; one study of popular Android tracking SDKs found very limited and
inadequate guidance on how developers were supposed to handle consent in
compliance with EU data protection law[207].

The changes to the iOS and (to a lesser extent) Google Play stores ecosystem
(as described in section 5.1.2), may ultimately have the biggest effect on
developers’ relationships with third party trackers. In addition to the ATT
framework, under iOS version 14, developers must provide standardised privacy
information which is displayed in the App store in the form of app privacy
‘labels’ (similar to those proposed in HCI research, e.g. [237]). Both
measures may provide greater incentives for app developers to assess their
relationships with third-parties, potentially cutting off those which provide
little value to them, especially where they are worried about the effect of
the new transparency measures and easy tracker-blocking options available to
users.

###  5.2 Internet-of-Things and Smart Homes

Tracking and various other forms of surveillance existed before the web and
mobile apps, and continue to operate outside them. However, the kind of
tracking that was developed on the web and mobile, has provided a technical
and commercial blueprint for tracking via devices outside those specific
platforms. In recent years, a set of much-hyped and partially adopted
technologies, grouped under the ‘Internet-of-Things’ moniker (and in the
domestic context, the ‘smart home’), have presented a novel frontier for the
extension of third-party tracking. What makes an object ‘smart’ is of course
vague and nebulous [238], but one of the commonly cited criteria is that a
smart device is internet-connected [239]. This ability to make network
connections has allowed smart IoT devices to mimic or even embrace wholesale
the same tracking infrastructures as already established in web and mobile-
based tracking. Often, the very same companies providing web tracking
technology are offering the same models for IoT [240].

These different smart devices raise different privacy implications owing to
their distinct locations, types of data collected, and modalities for
interaction[241]. For instance, several automobile manufacturers including
Volvo and Audi, have adopted Android Automobile, an automobile-focused version
of Android, developed by Google. This uses the same app distribution model as
the standard Android Play Store. This means that users must log in with their
Google account, and developers creating apps for these vehicles are able to
embed the full range of third-party trackers that are used in mobile apps, but
have access to more data about another dimension of the user’s life (i.e.
their car journeys).

Various research has investigated the extent of tracking on IoT and smart
devices, including smart toys [242, 243], smart TVs [244, 245, 246], robotic
home assistants [247], smart energy grid technology [248] and smart meter
agents [249, 250]. As with web and mobile, a picture of the extent of third-
party tracking can be gained from studying the network traffic from IoT
devices. A 2019 study found that 57.45% of the overall destinations contacted
by US IoT devices are third or support parties (50.27% for UK devices)[251].

The privacy implications of ‘smart’ speakers and voice assistants like
Amazon’s Echo and Google Home, have also been the subject of multiple studies
[252, 253]. Voice assistants placed in the home may be interacted with by
multiple different users, providing insights not only to a single user’s
habits and interests but also those of their family, friends, and potentially
any visitor to their home[254, 255]. Even if they only ‘listen’ when addressed
by their ‘wake word’, they may end up responding accidentally when the wake
word is said accidentally or the speaker makes a false positive error[256].
While Amazon and Google at present deny using data from the Amazon Echo and
Google Home smart speakers within their ad targeting services, third-party
apps that are delivered via smart speakers, like the music streaming service
Pandora, advertise the ability to target smart speaker users. Furthermore,
existing adtech tracking companies advertise the ability to identify which
consumers own smart speakers (which can be detected when their mobile devices