# Measuring UID Smuggling in the Wild

Audrey Randall<EMAIL_ADDRESS>UC San Diego  ,  Peter Snyder
<EMAIL_ADDRESS>Brave Software  ,  Alisha Ukani<EMAIL_ADDRESS>UC San Diego  ,
Alex Snoeren<EMAIL_ADDRESS>UC San Diego  ,  Geoffrey M. Voelker
<EMAIL_ADDRESS>UC San Diego  ,  Stefan Savage<EMAIL_ADDRESS>UC San
Diego  and  Aaron Schulman<EMAIL_ADDRESS>UC San Diego

(2022)

###### Abstract.

This work presents a systematic study of UID smuggling, an emerging tracking
technique that is designed to evade browsers’ privacy protections. Browsers
are increasingly attempting to prevent cross-site tracking by partitioning the
storage where trackers store user identifiers (UIDs). UID smuggling allows
trackers to synchronize UIDs across sites by inserting UIDs into users’
navigation requests. Trackers can thus regain the ability to aggregate users’
activities and behaviors across sites, in defiance of browser protections.

In this work, we introduce CrumbCruncher, a system for measuring UID smuggling
in the wild by crawling the Web. CrumbCruncher provides several improvements
over prior work on identifying UIDs and measuring tracking via web crawling,
including in distinguishing UIDs from session IDs, handling dynamic web
content, and synchronizing multiple crawlers. We use CrumbCruncher to measure
the frequency of UID smuggling on the Web, and find that UID smuggling is
present on more than eight percent of all navigations that we made.
Furthermore, we perform an analysis of the entities involved in UID smuggling,
and discuss their methods and possible motivations. We discuss how our
findings can be used to protect users from UID smuggling, and release both our
complete dataset and our measurement pipeline to aid in protection efforts.

††copyright: none††journalyear: 2022††conference: ; conference TBD; date
TBD††booktitle: Internet Measurement Conference (IMC ’22), October 25–27,
2022, Nice, France

##  1\. Introduction

Over the past few years, tensions have deepened between those collecting
detailed user behavior data for advertising purposes and privacy-conscious
users who do not want to be monitored. While there are some efforts to find a
compromise between these positions (e.g., allowing the collection of
aggregated, anonymized data (Bindra, 2021; Goel, 2022)), none have yet managed
to satisfy advertisers or privacy advocates (Cyphers, 2021; Schechner et al.,
2022; Wakefield, 2022). In the absence of such a solution, privacy-focused
browsers (i.e., browsers for which privacy is seen as a competitive advantage)
have rolled out changes that block one of the core mechanisms used by _third-
party trackers_ to aggregate information about a user _across different
websites_ , thereby building a profile of that user.

Previously, third-party trackers could build user profiles across websites
because information stored by the tracker was accessible to that tracker
across all websites that include it. Trackers commonly used third-party
cookies for this purpose, although any type of browser storage could be used.
Trackers could use this shared storage to build shared state for each user
across every website that included the tracker. However, several browsers are
now employing an anti-tracking defense called “partitioned storage,” which
removes this sharing ability. By partitioning all browser storage by the
domain of the top-level website, browsers intended to prevent trackers from
linking user information across sites.

However, trackers have responded by implementing a new class of tracking
technique that we call _UID smuggling_. UID smuggling allows trackers to share
a user’s information across websites by modifying the user’s navigation
requests. The tracker accomplishes this style of tracking by decorating users’
navigation requests with identifying information, which will then be shared
across first-party boundaries. The tracker may also choose to momentarily
redirect the user to its own domain, where it can record this smuggled
information as a first party itself. In each case, trackers use UID smuggling
to regain the ability to link user-identifying information across sites,
circumventing the browser’s attempt to partition such information.

This work presents the first systematic measurement of UID smuggling in the
wild. We make the following contributions to understanding online tracking and
improving Web privacy:

  1. (1)

We perform the first systematic measurement of UID smuggling in the wild.

  2. (2)

We construct a multi-stage analysis pipeline, nicknamed CrumbCruncher, to
crawl the Web and measure how frequently UID smuggling occurs.

  3. (3)

We improve on prior techniques for differentiating user identifiers from other
values and synchronizing multiple crawlers.

  4. (4)

We categorize the behaviors of trackers, including which categories of sites
are more likely to engage in UID smuggling.

  5. (5)

We contribute to countermeasures against UID smuggling, both by sharing our
hand-edited dataset, and by publishing our tool for finding new instances,
CrumbCruncher.

The remainder of our work is organized as follows. Section 2 covers the
background of navigational tracking and related work. Section 3 describes the
design of our crawler, CrumbCruncher, and its capabilities and limitations.
Section 4 presents our findings, including the most common participants in
navigational tracking and a summary of their behaviors and categories. Section
5 describes the limitations of our work. Section 6 details our contribution to
the countermeasures that various entities have taken against navigational
tracking. Section 7 discusses related work, and Section 8 concludes.

##  2\. Background

Advertisers want to track user activity across sites for a variety of
purposes, including performing identity resolution and supporting affiliate
marketing, but such capabilities represent a significant threat to user
privacy.

For over a decade, browsers allowed advertisers to perform these cross-site
tracking functions with third-party cookies. But because this capability
presents a threat to privacy, several popular browsers have implemented
_partitioned storage_ to isolate third-party cookies so they cannot be used
for cross-site tracking. At the time of writing, Firefox, Safari, and Brave
(Johnson et al., 2021; WebKit, 2019; Huang et al., [n. d.]) all use
partitioned storage by default.

Figure 1. Flat storage versus partitioned storage.

Partitioned storage uses a hierarchical namespace, where the hierarchy is
based on the domain of the frame that contains the cookie-storing element.
Figure 1 shows the difference between flat and partitioned storage from a
tracker’s perspective. When flat storage is in use, the tracker can read from
or write to the same storage area regardless of which website it is on, but
when partitioned storage is implemented, the tracker accesses a different
storage area on each website that loads the tracker. This prevents trackers
from assigning the same user-identifying cookie (represented by the
gingerbread man icon) to users across sites. A similar system is used for
other browser storage, such as local storage.

To circumvent the protections that partitioned storage provides, advertisers
are increasingly using _UID smuggling_. UID smuggling modifies a user’s
navigation requests by adding information to the navigation URLs in the form
of query parameters. UID smuggling may also redirect the user to one or more
third-party trackers before redirecting to the intended destination.

Figure 2. How UID smuggling allows trackers to circumvent partitioned storage.

Figure 2 shows this process in detail. In UID smuggling, the user is sent
through a navigation path. This path begins at the originator website, where
the user clicks a link. When the link is clicked, the page itself or a tracker
on the page decorates the URL by adding the originator’s user identifier (UID)
as a query parameter. The navigation path then passes through zero or more
redirectors, which are invisible to the user but are permitted to store first
party cookies. Each of these redirectors has the ability to store the UID from
the query parameter as a cookie or local storage value under the redirector’s
domain. Finally, the user is sent to the destination, the website the link
originally pointed to. The destination may also store the UID under its own
domain. Thus, trackers using UID smuggling regain the ability to share UIDs
across websites with different domains, in defiance of the browser’s
partitioned storage protections.

UID smuggling is related to, but more powerful than, two previously studied
tracking techniques: bounce tracking and cookie syncing. Bounce tracking also
modifies a user’s navigation path by redirecting them through tracking sites
that can store first-party cookies. Bounce tracking allows a tracker to record
which originator and destination websites a user has visited, but not to
aggregate any information about a user’s behavior on those websites (the links
the user clicks, purchases the user makes, etc.), because no link decoration
is used to insert UIDs into the navigation path. The tracker thus cannot link
together the different UIDs it has assigned to a user across different
websites. Both UID smuggling and bounce tracking are part of a class of
tracking techniques known as “navigational tracking.”

Cookie syncing allows multiple third parties on a _single_ first-party site to
share UIDs with each other. However, if partitioned storage is in place, third
parties cannot share information _across_ first-party websites using cookie
syncing. When partitioned storage is in use, the storage available to trackers
on the destination site is partitioned away from their storage on the
originator. Thus, all trackers on the originator can share their UIDs with
each other, and all trackers on the destination can do likewise, but trackers
on the originator cannot share UIDs with trackers on the destination.

##  3\. Methodology

Figure 3. A single step of the ten-step random walk that CrumbCruncher
performs for each seeder domain.

In this section, we describe CrumbCruncher, a web crawling system based on
Puppeteer that measures the prevalence of UID smuggling in the wild.
CrumbCruncher’s goal is to collect as many potential cases of UID smuggling as
possible, and then distinguish the benign cases from true UID smuggling by
determining which smuggled values are truly UIDs. To collect potential UID
smuggling, CrumbCruncher employs multiple synchronized crawlers that simulate
a set of users, with an additional, trailing crawler that simulates a user
returning to each site. CrumbCruncher must then identify which potential UIDs
are truly UIDs by comparing them across each crawl: values that vary across
the set of different users but remain static for the repeat visitor are likely
to be UIDs.

The canonical approach for identifying UIDs in prior work is to use only two
crawlers to compare potential UID values across users. Unfortunately, these
studies have been forced to discard a large number of potential UIDs from
their analyses under two circumstances: first, when the potential UID only
appeared on one crawler instead of both, and second, when the potential UID
might be a session ID instead. Because we expect UID smuggling to be rare and
difficult to find in the wild, we require CrumbCruncher to discard as few UIDs
as possible. CrumbCruncher achieves this goal in three ways. First, it
distinguishes UIDs from session IDs more accurately than prior studies, which
allows it to retain UIDs that would have been discarded by previous common
strategies (Koop et al., 2020; Englehardt et al., 2015; Englehardt and
Narayanan, 2016; Acar et al., 2014). Second, when potential UID smuggling does
not appear on all crawlers, CrumbCruncher applies programmatic and manual
heuristics to identify UIDs, rather than discarding the cases entirely as
prior work does (Fouad et al., 2020; Englehardt et al., 2015; Englehardt and
Narayanan, 2016; Koop et al., 2020; Acar et al., 2014). Finally, CrumbCruncher
introduces a novel method for synchronizing web crawlers that click iframes,
which allows it to collect data from the elements that are most likely to
contain UID smuggling. CrumbCruncher also uses three synchronized crawlers,
rather than two, giving it multiple chances to observe each potential UID
across two crawlers. Each of these improvements allows CrumbCruncher to
collect or retain more data than previous systems.

###  3.1. Crawling the Web

CrumbCruncher collects a sample of websites that contain UID smuggling by
performing ten-step random walks. Each random walk begins at a “seeder domain”
taken from the Tranco list of the globally most-popular 10,000 domains (Le
Pochat et al., [n. d.]). Each of CrumbCruncher’s multiple crawlers follows the
same walk.

At each step of a walk, CrumbCruncher records all first-party cookies, local
storage values, and web requests on the originator page. Next, it chooses
either a frame ($<$iframe$>$) or anchor ($<$a$>$) element to click on, in an
attempt to trigger navigation. CrumbCruncher selects iframes because we expect
them to contain advertisements which might use UID smuggling. CrumbCruncher
also follows anchors because many webpages do not contain iframe elements.
Regardless of element type, CrumbCruncher prefers elements that navigate to a
URL with a different registered domain than the current page. For each click
that triggers a navigation, CrumbCruncher’s browser extension collects all
navigation web requests by implementing a handler for the
chrome.webRequest.onBeforeRequest event. Upon arriving at the destination
page, CrumbCruncher again records all first-party cookies, local storage
values, and web requests for ten seconds.

CrumbCruncher repeats this navigation process, starting at each new page
loaded by the click in the previous step, nine times. It then selects a new
seeder domain to start the next random walk. CrumbCruncher retains browser
state (including cookies and storage values) for the duration of each walk and
discards it when beginning a new walk. CrumbCruncher proceeds in this depth-
first manner to maximize the number of distinct pages visited, rather than
maximizing the elements visited per page, because we expect that websites
likely use UID smuggling in either all elements that trigger navigation or
none.

###  3.2. Detecting potential UID Smuggling

CrumbCruncher’s goal is to identify cases where a UID has been smuggled—i.e.,
passed across sites in defiance of browser protections—which requires
differentiating UIDs from non-tracking tokens. We use the term “token” to
refer to any potential UID found inside the value of a name-value pair,
whether that pair is a first-party cookie, a local storage object, or a query
parameter. CrumbCruncher builds on prior work that identifies UIDs by
comparing the tokens that are passed by two different users access a
particular website (Acar et al., 2014; Englehardt et al., 2015; Englehardt and
Narayanan, 2016; Koop et al., 2020; Fouad et al., 2020; Urban et al., 2018).
However, instead of using two crawlers, CrumbCruncher uses four.

Three of the four crawlers—nicknamed Safari-1, Safari-2, and Chrome-3—each
simulate a different user on a Safari or Chrome browser. These three crawlers,
which run in parallel, allow CrumbCruncher to discard tokens that are the same
across users and are thus unlikely to be UIDs. We explain how CrumbCruncher
spoofs browsers and impersonates different users in Sections 3.4 and 3.5. The
fourth crawler, Safari-1R, simulates the same user as Safari-1. Safari-1R
checks whether the same token is observed when a webpage is accessed twice by
the same user: specifically, Safari-1R repeats each crawl step immediately
after Safari-1 finishes it. Safari-1R allows CrumbCruncher to discard tokens
that differ when observed repeatedly by the same user, and thus are probably
session IDs, not UIDs. More details on this process are given in Section 3.7.

###  3.3. Synchronizing multiple crawlers

One underlying assumption behind the multi-crawler methodology is that all
browsers are accessing the same version of a particular webpage: the four
crawlers must visit the same URL and click the same elements on each page.
This process is depicted in Figure 3. However, we find that keeping the
crawlers synchronized presents a significant challenge due to the dynamic
nature of the web. Determining which elements are the same on different
instances of the same webpage is not straightforward. Even when accessed
simultaneously, websites often load dynamic content: elements that appear on
one crawler’s page might not appear on the others’. We also find that even
when elements are the same (e.g., iframes that load the same content), they
might not appear in the same locations or with the same size. Additionally,
CrumbCruncher clicks iframe elements, which often do not have any attribute
that identifies where a user will navigate when they click the iframe.
Determining which iframe elements are equivalent across different instances of
a webpage is more challenging than comparing anchor elements, which almost
always have an easily comparable $<$href$>$ attribute.

To mitigate this issue, CrumbCruncher uses a central controller (a local HTTP
server) to choose the element that Safari-1, Safari-2 and Chrome-3 click in
unison. Upon loading a page, each crawler sends a list of all anchor and
iframe elements on that page to the central controller. These lists contain
the elements’ properties, location, bounding boxes, and x-paths. The
controller compares the three lists to find elements that are the same across
all three instances of the page. We consider elements to be the same if any of
three heuristics are met:

  1. (1)

They are anchors and their href values are the same (not including query
parameters).

  2. (2)

They have the same property names (the values may differ) and similar bounding
boxes (the $y$-coordinate may differ, to allow for elements that render at
different heights on the page).

  3. (3)

They have the same property names and x-path.

These heuristics are imperfect: they may incorrectly label elements as the
same when they are not, or incorrectly discard elements. To mitigate these
possibilities, CrumbCruncher compares the fully qualified domain name (FQDN)
of the site each crawler has landed on at the end of every crawl step. If all
three FQDNs are not the same, CrumbCruncher terminates the walk. We still
include data from this last step in our analyses because this situation often
occurs when CrumbCruncher has clicked on different advertisements that each
exhibit a separate instance of UID smuggling.

We evaluate the effectiveness of these heuristics and find 7.6% of all crawl
steps fail because CrumbCruncher is unable to find an element that is the same
across all three synchronized crawls: this type of failure occurs at step ③ in
Figure 3. A further 1.8% of crawl steps fail at step ⑥ because the clicked
elements were not actually the same, and led to different destination
websites.

###  3.4. Impersonating different browsers

All four crawlers use Chrome (version 95 or 92) because our chosen crawling
framework, Puppeteer, is designed for that browser. However, CrumbCruncher
impersonates Safari on three of our four crawlers by spoofing the User-Agent
string.111We use the Safari User-Agent string Mozilla/5.0 (Macintosh; Intel
Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2
Safari/605.1.15. We chose to test Safari and Chrome because at the time of
writing, Safari implemented partitioned storage by default, and Chrome did
not. Our hypothesis was that trackers might use UID smuggling on Safari to
evade partitioned storage protections. Our Chrome-3 crawler was originally
intended to test this hypothesis, but we were unable to use it for this
purpose: UID smuggling cases quite often appeared on only one crawler,
regardless of whether that crawler was one of the three Safari crawlers or the
Chrome crawler (see Section 3.7). Differentiating cases where content that
performed UID smuggling was loaded dynamically from cases where UID smuggling
occurred deliberately on Safari and not Chrome proved to be impossible, so we
simply use Chrome-3 as another distinct user to identify UIDs.

We note that while spoofing the User-Agent string does change the value of
window.navigator, which is commonly used as a proxy for identifying the
browser, it is not a foolproof method of impersonating a browser. Websites may
use more sophisticated methods to identify a browser, such as comparing the
codecs it supports (Vastel et al., 2020). However, relatively few websites go
to such lengths: Vastel et al. crawled the Alexa 10K and found that only 93
websites appeared to use sophisticated fingerprinting techniques to identify
the browser that was loading them (Vastel et al., 2020). We therefore consider
the risk of sites misidentifying our browser to be small, given how few
websites appear to use fingerprinting to identify browsers.

###  3.5. Impersonating different users

The Chrome browser differentiates users by storing profiles in a folder called
the “user data directory” (repository, [n. d.]). To simulate a new user at the
start of each random walk, each crawler starts with a new user data directory.
This folder is modified from the default in two ways: first, third-party
cookies are disabled, and second, a Chrome extension is installed that records
web requests.

One potential limitation of our user simulation method is that websites may
generate UIDs using fingerprinting, i.e., by examining factors like User-Agent
string, supported fonts, hardware, and more.222IP address is generally too
variable to be used as an input by fingerprinters (Eckersley, 2010). Many of
these inputs are identical across all four crawlers since they are run on one
machine. If a tracker generated its UIDs using fingerprinting, assigned the
same UID across multiple crawlers, and then performed UID smuggling,
CrumbCruncher would erroneously discard those cases. However, we find that
this rarely occurs by performing the following experiment.

We observe that CrumbCruncher will not discard potential instances of UID
smuggling that only appear on a single crawler: only instances that appear on
multiple crawlers and have identical UIDs will be discarded. If CrumbCruncher
is erroneously discarding instances of UID smuggling, we would expect to see
very few cases that both occur on multiple crawlers _and_ originate on sites
that perform fingerprinting.

To test this hypothesis, we separate cases of UID smuggling into two groups:
the cases that originate on sites that are known to employ fingerprinting, and
cases that originate on other sites. To determine which sites use
fingerprinting, we use the list of fingerprinters found by Iqbal et al. (Iqbal
et al., 2021). We find that 13% of UID smuggling in our data originates on
pages hosted by one of Iqbal et al.’s fingerprinters. We then divide both
groups again, into the instances that occur on a single crawler and the
instances that occur on multiple crawlers. Next, we compare the proportion of
single-crawler to multiple-crawler instances in the fingerprinting group to
the non-fingerprinting group. In the fingerprinting group, 44% of UID
smuggling cases occur on multiple crawlers, whereas in the non-fingerprinting
group, 52% of cases occur on multiple crawlers. While the two-proportion Z
test suggests that this difference is statistically significant—and,
therefore, that CrumbCruncher likely missed some cases of UID smuggling due to
fingerprinting—the difference is small. The relative difference between
populations suggests CrumbCruncher may have missed on the order of 13 cases of
UID smuggling on sites that employ fingerprinting.

###  3.6. Identifying Potential UID Smuggling

Once CrumbCruncher has finished collecting data, we search for potential UID
tokens that were transferred across first-party contexts. We define “different
first-party contexts” as the case when the site the token was originally found
on has a different registered domain than any of the sites that eventually
received the token, whether those sites are redirectors or the ultimate
destination.

We extract potential UID tokens from cookies, local storage, and query
parameters by recursively attempting to parse the value of each name-value
pair333We do not look for tokens in the names of name-value pairs because
Fouad et al. found that storing UIDs as names rather than values was a very
uncommon practice (Fouad et al., 2020). as JSON or URL-encoded values. For
example, if a query parameter contains a JSON string that itself contains
several URL-encoded tokens, we extract each URL-encoded token individually.

We then discard all of the tokens that were not passed across at least one
first-party context as a query parameter. For example, if the same token was
found on both the originator site and the destination, but was not passed from
the originator to the destination as a query parameter, we discard it. We find
that the vast majority of these particular tokens are not used in UID
smuggling, but rather false positives that happen to appear on both websites.

However, we keep tokens that only get passed across part of a navigation path.
For example, if a token appears as a query parameter in the URL of a
redirector, then gets passed to the destination, we keep it even if it did not
appear on the original URL of that navigation path. Tokens are also not
required to appear as cookies or local storage values: they can appear on the
originator and destination as query parameters in third-party web requests.

###  3.7. Identifying UIDs

After collecting all potential cases of UID smuggling, we identify and discard
all of the cases that transfer harmless values rather than UIDs. Examples of
harmless values include timestamps, language specifiers, session IDs, and so
on. While performing this analysis, we discovered that cases of potential UID
smuggling fell into two categories: we labeled these categories “static” and
“dynamic.” Static UID smuggling occurs on elements that are always the same on
every visit to the page. Consequently, cases of static UID smuggling appear on
all four crawlers. Dynamic UID smuggling occurs on elements that load
different content on different page visits. Cases of dynamic UID smuggling
appear on fewer than all four crawlers, despite our efforts to keep the
crawlers synchronized. Identifying UIDs in static UID smuggling is simpler
than in dynamic UID smuggling: we describe our procedure in the static case
first.

####  3.7.1. Identifying UIDs in the static case

To track an individual user, a UID must be the same across all website visits
by the same user and different across visits to the same website by different
users. Consequently, we discard any token that is the same across our crawlers
that simulate different users, since these cannot be UIDs. However, it is also
necessary to discard tokens that differ across a single user, since these
tokens are likely to be session IDs that are not used for user tracking. Prior
work discarded session IDs by discarding all tokens whose lifetime was less
than a specific time, such as 90 days (Koop et al., 2020; Englehardt et al.,
2015; Englehardt and Narayanan, 2016) or a month (Acar et al., 2014).
CrumbCruncher improves on prior work by comparing potential session IDs across
Safari-1 and Safari-1R, which simulate the same user visiting the same website
twice, and discarding the tokens that differ across these crawlers. A sampling
of data collected from one of our crawler machines indicates that 16% of the
UIDs we identify have a lifetime of less than 90 days, and 9% have a lifetime
shorter than a month. These UIDs would have been missed by prior work that
uses lifetime to determine whether a token is a session ID.

####  3.7.2. Identifying UIDs in the dynamic case

User Profiles | # Tokens
---|---
2 identical plus 1 or more different profiles | 325
2 or more different profiles only | 171
2 identical profiles only | 20
1 profile only | 445
Table 1. Crawler combinations where UIDs appeared.

Unfortunately, we found that the majority of potential UID smuggling instances
were dynamic and thus did not occur on all four crawlers: in fact, many
instances occurred on only a single crawler. For example, we encountered many
cases where each crawler loaded the same originator website and clicked the
same iframe element, but the iframes contained different advertisements, so
each advertisement presented a different navigation path and arrived at a
different destination. We classify tokens that appear on fewer than four
crawlers in the following manner:

  1. (1)

If a token is present in any two crawls with different user profiles, and its
value is the _same_ across those crawls, we discard it.

  2. (2)

If a token’s name is present in Safari-1 and Safari-1R, which have the same
user profile, and its value _differs_ , we discard it.

We are left with two classes of tokens: tokens that are present in only a
single crawl, and tokens that only appear in crawls with different profiles
(and have different values across each crawler). For these tokens, we employ
both the programmatic heuristics used by previous work and manual sorting.

We base our programmatic heuristics on those of prior studies (Englehardt et
al., 2015; Englehardt and Narayanan, 2016; Koop et al., 2020). We remove
tokens that appear to be dates or timestamps, tokens that appear to be URLs,
and tokens that are less than seven characters long. We do not impose any
restrictions based on cookie expirations. However, even after we applied these
filters, manual inspection of the remaining tokens revealed a high number of
obvious false positives. These included natural language strings separated by
delimiters (such as “Dental_internal_whitepaper_topic,” “share_button”),
concatenated words with no delimiter (“sweetmagnolias,” “trustpilot”), semi-
abbreviated words (“navimail”), acronyms (“en-US”), and more. Filtering most
of these out programmatically presented a significant challenge.

We therefore concluded that programmatic heuristics would be insufficient to
distinguish UIDs from other tokens, and resorted to removing obvious false
positives by hand. Our final, conservative strategy is to remove tokens that
are composed of any combination of natural language words, coordinates,
domains, or obvious acronyms like “en-US.” Table 1 shows how many of the final
set of UIDs were present on various combinations of crawlers.

In the end, we manually removed 577 out of 1,581 tokens because our
programmatic filters failed to recognize them as non-UIDs. This number is
significantly higher than we expected and underscores the value of attempting
to observe UIDs across as many crawlers as possible. Care should therefore be
taken when comparing our results to prior work that did not attempt to
manually remove false positives.

###  3.8. Implementation

We implemented CrumbCruncher using both Puppeteer, to automate site visits and
record cookies and local storage, and a custom Chrome extension, to record web
requests. We use Puppeteer in “headful” mode, using the monitor emulator XVFB
(xvf, [n. d.]), to reduce the chance that CrumbCruncher will be identified as
a bot. While Puppeteer is capable of recording most web requests, it cannot
guarantee that it can attach request handlers before any requests on a page
have been sent (aslushnikov, 2018; berstend, 2018). We found during initial
testing that this led to a significant number of missed requests; hence,
CrumbCruncher records requests using a browser extension instead.
CrumbCruncher runs on twelve Amazon EC2 t2.large instances. Each EC2 instance
has a different set of 834 seeder domains. The full crawl of 10,000 seeder
domains takes approximately three days to complete.

Unique URL Paths | 10,814
---|---
Unique URL Paths w/ UID Smuggling | 850
Unique Domain Paths w/ UID smuggling | 321
Unique Redirectors | 214
Dedicated Smugglers | 27
Multi-Purpose Smugglers | 187
Unique Originators | 265
Unique Destinations | 224
Table 2. Summary of the navigation paths and their participants measured by
CrumbCruncher.

##  4\. Results

We consider two forms of navigation paths in our evaluation. “URL paths”
consist of the full URLs of the originator, any redirectors, and the
destination (e.g., a.com/x/y?UID=0 $\rightarrow$ b.com/x/y?UID=0). Domain
paths consist only of the domains at each step of the path (e.g., a.com
$\rightarrow$ b.com).

In total, we observed 10,814 unique URL paths in the data set we gathered
using CrumbCruncher. We consider unique URL paths, rather than total URL paths
including duplicate paths, because this metric gives a better estimate of how
many websites participate in UID smuggling.

Using our method for identifying UIDs, we found UID smuggling on 8.11% of the
unique URL paths taken by CrumbCruncher. It is interesting that such a non-
trivial percentage of advertisers have implemented UID smuggling, especially
given that Chrome—the most widely used web browser—still permits tracking with
third-party cookies by default. We speculate that the affiliate advertising
market may be driving the adoption of UID smuggling: affiliate programs have
reportedly been failing to attribute conversions because of browsers’ third
party cookie blocking (Hamilton, 2012), and link decoration allows conversions
to be attributed correctly.

In the rest of this section we examine the UID smuggling we discovered in
detail to understand who is implementing it, how they implement it, and why
they implement it.

Redirector | Count | % Domain Paths
---|---|---
adclick.g.doubleclick.net | 36 | 11.2
googleads.g.doubleclick.net | 20 | 6.2
advance.lexis.com* | 10 | 3.1
d.agkn.com | 9 | 2.8
btds.zog.link | 9 | 2.8
ad.doubleclick.net | 8 | 2.5
gm.demdex.net | 8 | 2.5
www.kinopoisk.ru* | 7 | 2.2
secure.jbs.elsevierhealth.com | 6 | 1.9
t.myvisualiq.net | 6 | 1.9
11173410.searchiqnet.com | 6 | 1.9
optout.hearstmags.com* | 6 | 1.9
signin.lexisnexis.com* | 6 | 1.9
trc.taboola.com | 5 | 1.6
l.instagram.com* | 5 | 1.6
ads.adfox.ru* | 5 | 1.6
www.facebook.com* | 5 | 1.6
reseau.umontreal.ca* | 5 | 1.6
l.facebook.com | 4 | 1.2
rtb-use.mfadsrvr.com | 4 | 1.2
www.campaignmonitor.com* | 4 | 1.2
6102.xg4ken.com* | 4 | 1.2
swallowcrockerybless.com* | 4 | 1.2
montreal.imodules.com* | 4 | 1.2
www.getfeedback.com* | 4 | 1.2
kuwosm.world.tmall.com* | 4 | 1.2
www.awin1.com | 3 | 0.9
www.zenaps.com | 3 | 0.9
pr.ybp.yahoo.com | 3 | 0.9
go.dgdp.net | 3 | 0.9
Table 3. The most common redirectors observed in unique domain paths. *Multi-
purpose smuggler

###  4.1. Redirectors

Figure 4. Most common entities involved in UID smuggling as originators or
destinations.

We start by identifying the trackers involved as redirectors in the navigation
paths that include UID smuggling. We use unique domain paths instead of URL
paths for this analysis, because this metric better captures how widely a
redirector is spread across the web, without over-counting repeated instances
of UID smuggling by the same entity.

We classify redirectors into two groups: “dedicated smugglers” and “multi-
purpose smugglers.” We use a conservative heuristic to identify dedicated
smugglers that appear to have no purpose in the navigation path besides UID
smuggling.444For example, site-specific redirection services (e.g., Twitter’s
t.co) are not considered dedicated smugglers using this classification. We
consider a redirector a dedicated smuggler if it meets three requirements:

  * •

The redirector appears in navigation paths whose originators have multiple
different registered domains,

  * •

The redirector appears in navigation paths that end in destinations with
multiple registered domain names,

  * •

The redirector’s FQDN is never observed as an originator or destination.

We separate out dedicated smugglers because we are confident that these
domains have no purpose besides UID smuggling, and their sole intent is
therefore likely to be enabling trackers to aggregate users’ information
across websites. We also predicted that dedicated smugglers might be
particularly underrepresented in filter lists that block trackers, because UID
smuggling is such a recent technique. Indeed, when we compared the dedicated
smugglers that we found to the Disconnect list of trackers (Disconnect, [n.
d.]b), 41% of them (11 out of 27) were not yet present in the list.

However, our heuristic is conservative. The less often CrumbCruncher sees a
redirector, the less likely it is to observe multiple originators and
destinations for that redirector, in which case the redirector would not be
classified as a dedicated smuggler. Consequently, some dedicated smugglers
might appear in the “multi-purpose smugglers” category.

Table 3 shows the most commonly-occurring redirectors in the navigation paths
we measured. From this list, 16 of the 30 most common redirectors are
dedicated smugglers and 14 are multi-purpose (the multi-purpose smugglers are
marked with an asterisk). Of the 16 dedicated smugglers, 14 are owned by
advertisers, while the other two (btds.zog.link and
secure.jbs.elsevierhealth.com) have unclear owners or purposes. The most
commonly used dedicated smuggler is DoubleClick, which appears in more than
20% of all cases of UID smuggling.

The multi-purpose trackers appear to fill a variety of rolls: while all of
them perform UID smuggling, some have a separate purpose as well. Some
redirect to sign-in pages (e.g., signin.lexisnexis.com), host user-facing
websites (e.g., www.facebook.com), upgrade or downgrade HTTP/HTTPS connections
(e.g., kuwosm.world.tmall.com), or specify the English-language version of a
site by appending “/en/” (e.g., www.getfeedback.com). Some multi-purpose
smugglers are owned by advertising companies, just as the dedicated smugglers
are. Two redirectors, swallowcrockerybless.com and d.agkn.com, appear to be
associated with adware or other potentially unwanted activity.

###  4.2. Originators and Destinations

Next, we identify the organizations that acted as originators or destinations
during UID smuggling. We began with the Disconnect entity list (Disconnect,
[n. d.]a), which recorded an owning organization for 45 out of the 436 unique
registered domains of the originators and destinations. We then identified the
owners of a further 235 registered domains manually (all of the domains that
appeared multiple times, plus as many of the long tail as we could). An entity
is counted once per unique domain path: if multiple domains owned by a single
organization appear more than once in a domain path, the owning organization
is only counted once for that path.

Figure 4 shows the originators and destinations observed most frequently in
our measurements. We note that many originators might be expected to publish
affiliate advertisements, such as sports websites, news organizations, and
adult websites, while many destinations might have affiliate advertising
programs, such as retailers or technology companies. While we cannot guarantee
that these entities participate in UID smuggling as part of affiliate
advertising campaigns, many of these organizations support that hypothesis.

Figure 4 also illustrates one particular case of UID smuggling between
unexpected organizations. One of the most common cases of UID smuggling in our
measurements was a navigation path that led from the originator instagram.com,
owned by Facebook, to the Google Play Store. This path existed because the
button on instagram.com advertising the Instagram mobile app always appended
instagram.com’s UID cookie to the navigation request for play.google.com. We
were surprised to see that two large advertising companies, that might be
expected to be competitors, were apparently sharing UIDs with each other.

Figure 4 also contains an example of UID smuggling that was not initiated by
an advertiser, but rather used to synchronize information between multiple
domains owned by a single company. The most common originator in Figure 4 is
Sports Reference, an organization that maintains several websites with
statistics for popular American sports. This company owns several sports-
themed domains whose websites link frequently to each other, such as
stathead.com, hockey-reference.com, baseball-reference.com, and others (spo,
[n. d.]). CrumbCruncher spent several random walks in this ecosystem of
websites. We hypothesize that rather than using UID smuggling for advertising,
Sports Reference uses it to share information between its own affiliated
sites.

####  4.2.1. Content categories

Figure 5.  Categories of websites that participate in UID smuggling as
originators or destinations.

We further break down the originators and destinations by categorizing them by
the topic of their site content. We use the categorization defined by the IAB
Tech Lab Content Taxonomy (IAB, [n. d.]) as provided by Webshrinker
(Webshrinker, [n. d.]b), whose data set contains 404 domain categories
(Webshrinker, [n. d.]a). Out of 339 unique registered domains, 307 had a
useful category and 32 were categorized as unknown.

Figure 5 shows the most common categories of websites that participate in UID
smuggling in our dataset. The counts of websites per category reflect the
number of unique registered domains in that category, so that each registered
domain is represented only once even if CrumbCruncher encountered it multiple
times. For example, even though Facebook’s domains are common originators as
seen in Figure 4, they only appear twice as originators in Figure 5: once for
facebook.com and once for instagram.com, both in the “Social Networking”
category.

Notably, “News/Weather/Information” is the most common category for
originators, and the second most common category overall. This result is
consistent with previous studies that found news websites to have an above-
average amount of more traditional tracking mechanisms, such as fingerprinting
and tracking pixels (Englehardt and Narayanan, 2016; Iqbal et al., 2021). Our
impression, based on manual inspection of a few of these originators, is that
news websites have an above-average number of advertisements in iframes that
perform UID smuggling when clicked.

####  4.2.2. Third parties

Figure 6. Most common domains of third party web requests sent from the
destination site.

After a UID has been transferred through the entire navigation path, it may
not have finished its journey: third parties on the destination site may also
send the UID back to their own servers. Figure 6 shows the 20 most common
registered domains of the targets of web requests sent from destination sites
that included UIDs.

The third-party trackers listed in this figure include trackers that did not
appear to use UID smuggling. We note that many requests to third party
trackers passed the UID only because the request included the entire URL of
the destination site, suggesting that the UID may have been “leaked” to these
entities accidentally. This unintended consequence of UID smuggling may
present a further privacy harm, in that trackers that do not participate in
UID smuggling are nevertheless gaining access to UIDs that they would
otherwise be unable to observe.

###  4.3. Navigation Paths

Figure 7. Distribution of the types of redirectors in URL paths. Figure 8.
Counts of UIDs that traversed each portion of a URL path.

In this section, we examine the characteristics of navigation paths used for
UID smuggling, including the features that differentiate them from benign
navigation paths.

Figure 7 shows the number of redirectors in the middle of each URL path that
was used for UID smuggling. The first bar, with zero redirectors, shows the
cases where a UID was transferred directly from the originator to the
destination without passing through any redirectors in between.

The results show that the higher the number of redirectors in a path, the
greater the proportion of paths that contain dedicated smugglers, and the
greater the number of dedicated smugglers in each path. We conclude that
shorter navigation paths are more likely to have a benign purpose, whereas
longer navigation paths are more likely to be used for UID smuggling.

Long navigation paths give multiple trackers the ability to share UIDs with
each other. For example, one navigation path started at a coupon-collecting
website (couponfollow.com), passed through a partner site owned by the same
entity, then passed through four different trackers before arriving at the
final destination (a retailer). Each of these trackers had the ability to
record information about the ad the user had clicked and their apparent
interest in the retailer’s products.

Long navigation paths can also allow a single tracker to coordinate multiple
domains that it controls. If those domains are connected to separate
infrastructure (as might be the case if one advertising company acquired
another and inherited the acquisition’s infrastructure), the company might
wish to synchronize the UIDs stored as first party cookies by redirectors. For
example, the most common pair of redirectors we observed (where the first
domain in the pair immediately redirects to the second domain) is awin1.com
$\rightarrow$ zenaps.com. Both domains are owned by the advertiser AWIN.

UIDs do not always begin at the originator and pass through each redirector
before arriving at the destination: they may appear at any step of the path
and cease their journey at any number of hops further along. Each navigation
path can also contain multiple UIDs. Figure 8 shows how many UIDs traverse
each portion of the navigation path. We divide the UIDs that traverse each
partial path into two groups: the UIDs that passed through a dedicated
smuggler, and the UIDs that passed through either multi-purpose smugglers only
or no redirectors at all. For example, the second bar, “Originator to
Destination,” shows the number of UIDs that were passed through navigation
paths that did not include any redirectors.

We observe that the majority of UIDs are transferred across the entire path
from the originator, through any redirectors if they exist, to the
destination. A tracker might wish to do this when it is reasonably confident
that the destination will include one of its scripts, which is capable of
storing the UID under the destination’s domain. If a tracker is present on the
originator and capable of initiating UID smuggling, but is not confident that
the destination will contain one of its scripts, it might choose to transfer
the UID through only part of the navigation path. These “partial transfer”
cases involve a higher proportion of dedicated smugglers, which is further
confirmation that the redirectors we label “dedicated” have no other purpose
in the navigation path than UID smuggling. We hypothesize that trackers who
only send a UID through a part of the navigation path might be less widely
used, since they are apparently not confident that the destination will
contain one of their scripts.

##  5\. Limitations

CrumbCruncher has several limitations. First, we only look for UIDs that are
transferred in the query parameters of URLs, and not by other methods. For
example, trackers reportedly sometimes decorate the link in the
document.referrer header with the UID, instead of the link to the destination
page (Wilander, 2019). Our initial reasoning was that there are a wide variety
of ways to transfer UIDs, so we could simply check once a crawl was complete
for UIDs that had mysteriously appeared on different websites without being
passed through a URL. In practice, this turned out to be difficult: dynamic
instances of UID smuggling had to be detected using heuristics, which gave
large numbers of false positives when used without the additional information
provided by multiple crawlers. It turned out that when the same value appeared
on two different websites, the most common reason was that the value was not a
UID and had simply happened to be generated on both sites. To reduce our false
positive rate and therefore the number of identifiers we had to remove by
hand, we chose to consider only values that we had observed get transferred
across at least two first party contexts.

Second, if a website uses browser fingerprinting to generate UIDs, our
methodology may not fool the site into believing that our crawlers represent
different users. We have calculated that the effect of browser fingerprinting
on our results is very small: please see Section 3.5 for details.

##  6\. Countermeasures

###  6.1. Existing Mitigations

Defending against UID smuggling is not straightforward. Given the difficulty
of designing defenses that do not degrade user experience, most defenders
(whether browsers or browser extensions) have so far opted for either
heuristic-based or blocklist-based approaches. For example, Safari uses
heuristics: the browser will delete cookies and website data set by a
redirector unless the user also interacts with the redirector as a first-party
website (Apple, [n. d.]). Safari labels an originator as performing UID
smuggling if 1) it automatically redirects the user to another site, and 2) it
did not receive a user activation (Snyder and Yasskin, 2021). Safari also
classifies a site as a UID smuggler if it participates in a navigation path
that contains another known UID smuggler.

In contrast, Firefox defends against UID smugglers using the Disconnect
Tracker Protection blocklist (Disconnect, [n. d.]b; Mozilla, [n. d.]). Firefox
clears all storage from sites on the Disconnect tracking list after 24 hours,
unless the user has loaded the site as a first party in the previous 45 days
(Snyder and Yasskin, 2021). Unfortunately, we found that many UID smugglers
are not yet present on the Disconnect list.

The Brave browser has multiple approaches for preventing UID smuggling. First,
if the browser is navigating to a link with a query parameter for another
destination URL, Brave will simply redirect to the URL in the query parameter
(Snyder, 2021). If the browser cannot detect the final destination of the
navigation, it allows the navigation to proceed, but inserts an interstitial
that warns users they will be tracked if they continue. Brave also maintains a
list of UID smuggling URLs created from crowd-sourced and open-source
information, as well as a blocklist of query parameter names that are commonly
used for UID smuggling. Finally, Brave clears the storage areas associated
with any sites it classifies as UID smugglers as soon as the user closes the
tab that loaded them.

While Chrome is in the process of deprecating third-party cookies (Schuh,
2020), it does not appear to implement any features to defend against UID
smuggling yet.

Some browser extensions have begun to implement protections against UID
smuggling as well. For example, Privacy Badger (Foundation, [n. d.]) – a
browser extension by the Electronic Frontier Foundation that blocks cross-site
tracking – identifies when a tracker inserts a redirector into a navigation
path, and extracts the destination link from the query parameter in the
redirector’s URL (Cyphers, 2018). Another extension, uBlock Origin, implements
an interstitial-based approach similar to Brave’s (Newman, 2021).

###  6.2. Proposed Mitigations

CrumbCruncher’s data can help augment the blocklists used by privacy tools and
browsers to defend against UID smuggling. We provide two contributions: first,
we commit to publishing our list of token names and trackers in a publicly
available GitHub repository (although we will refrain from recording the link
here at this time to preserve the double-blind nature of the review process).
This repository will contain the list of query parameter names that were used
to transfer UIDs across websites, as well as the list of entities that
participate in UID smuggling as redirectors. Our second contribution is the
code for CrumbCruncher itself, which can be run as an almost entirely
automated pipeline in order to continuously update blocklists of navigational
trackers. A major challenge of blocklist-based defenses lies in keeping those
blocklists up to date: CrumbCruncher can help do that with much less human
intervention than systems that rely on user reports of UID smuggling. We will
publish the code for CrumbCruncher along with the list of token names and UID
smugglers that we discovered in this study.

##  7\. Related Work

The work that is most closely related to our own is Koop et al.’s study of
bounce tracking (Koop et al., 2020). Bounce tracking is similar to UID
smuggling in that users’ navigation paths are modified to insert redirectors
that can store values as first parties, but differs in that no UIDs are
transferred across contexts. Koop et al. study bounce tracking only, and do
not attempt to measure whether UIDs are transferred across contexts.
CrumbCruncher also clicks both iframes and anchors, whereas Koop et al.’s
crawler clicks only anchors. This allowed CrumbCruncher to detect navigational
tracking used by advertisements in iframes.

To verify that CrumbCruncher crawled a reasonable sample of the Web and
successfully detected modified navigation paths, we measured the instances of
bounce tracking that CrumbCruncher observed while it searched for UID
smuggling, and compared our findings to the instances found by Koop et al. We
found that bounce tracking that did not also involve UID smuggling was present
on 2.7% of the navigation paths we studied (UID smuggling was present on
8.1%). Because Koop et al. did not attempt to measure whether UIDs were
transferred across contexts, their study labeled all UID smuggling that
involved one or more redirectors as bounce tracking. Koop et al. found that
“11.6% of the websites in the Alexa top 50,000 had at least one link leading
to one of the top 100 [most common] redirectors.” This finding seems
consistent with our measurement that either UID smuggling or bounce tracking
is present on a total of 10.8% (8.1% UID smuggling and 2.7% bounce tracking)
of the unique navigation paths we followed.

###  7.1. Prior work on differentiating UIDs

Multiple groups have attempted to differentiate between identifiers that are
capable of tracking users (UIDs) and identifiers that are not. To be a UID, a
value must differs across different users, remain the same for the same user
(i.e., it must not be a session ID), and contain sufficient entropy.
Techniques for making these three determinations vary.

Prior work, which focused on cookies that might be UIDs, determined whether a
cookie varied across users by directly or indirectly simulating different
users across different crawls. Some work used two crawlers that visited the
same sites simultaneously (Englehardt and Narayanan, 2016; Englehardt et al.,
2015; Fouad et al., 2020), while others simulated multiple users sequentially
using a single crawler (Koop et al., 2020) or multiple crawlers (Urban et al.,
2018). Simulating multiple users sequentially enables a crawler to simulate
more different users, because keeping multiple crawlers synchronized becomes
more difficult as the number of crawlers increases, and a single crawler can
evade this problem entirely. The disadvantage of sequential user simulation in
prior work is that the crawlers did not guarantee that they visited each
website more than once and thus observed each cookie more than once.
Consequently, some of the cookies measured by the single sequential crawlers
could not be compared across multiple users. In contrast, CrumbCruncher makes
a concerted effort to visit every website in each crawl with four crawlers
that represent three different users, which maximizes the chance that we can
compare cookies and local storage values across users.

Determining whether a token is a UID also requires discarding session IDs.
Most past studies labeled cookies as session IDs if their lifetime was less
than a specific time, such as 90 days (Koop et al., 2020; Englehardt et al.,
2015; Englehardt and Narayanan, 2016) or a month (Acar et al., 2014). These
works also required that the token not vary during the crawl. In contrast,
Fouad et al. did not put a lifetime limit on cookies, arguing that trackers
can easily link short-lived cookies on their servers (Fouad et al., 2020). We
improve on prior work for discarding session IDs by immediately repeating
every crawl step using a crawler that mimics one previous user. We only assume
a token is a session ID if it differs across these two crawls. This technique
allows us to include the 16% of UID smuggling instances that we would have
discarded if CrumbCruncher had used a 90 day minimum lifetime — see Section
3.7.1 for more details.

A further difference between CrumbCruncher and prior work is in how we
determine if tokens are “the same” across users. Some previous work used the
Ratcliff/Obershelp algorithm (Black, 2021) to compare cookie values and
allowed those values to differ by 33% (Koop et al., 2020; Englehardt and
Narayanan, 2016; Acar et al., 2014), 45% (Englehardt et al., 2015), or by an
unspecified amount (Urban et al., 2018), while still treating the cookies as
“the same.” We chose to discard tokens as non-UIDs only when they are entirely
identical across different users, because we wished to be unambiguous about
why we had discarded a particular potential UID. Some previous work also
required cookie lengths to remain the same across crawls (Acar et al., 2014;
Englehardt et al., 2015; Urban et al., 2018) or to only differ by 25% (Koop et
al., 2020), as well as requiring cookie lengths to be at least eight
characters. We require token lengths to be greater than eight characters, but
we do not place any restrictions on the similarity of token lengths across
users.

###  7.2. Related work on cookie syncing

A related technique to navigational tracking is cookie syncing, which has been
investigated by multiple groups (Urban et al., 2018; Acar et al., 2014;
Papadopoulos et al., 2019; Englehardt and Narayanan, 2016; Papadopoulos et
al., 2018; Urban et al., 2020). Cookie syncing is not the same as navigational
tracking, because it does not allow third parties to share a UID across top
level sites when partitioned storage is in use. Instead, cookie syncing allows
third parties on the same site to share a UID with each other.

###  7.3. Other related work

Trackers may circumvent partitioned storage protections using techniques that
do not rely on navigational tracking, such as CNAME cloaking (Dimova et al.,
2021; Dao et al., 2020) or browser fingerprinting (Eckersley, 2010;
Nikiforakis et al., 2013; Iqbal et al., 2021).

CNAME cloaking is the procedure of mapping a website subdomain to a third
party domain using a DNS CNAME record. This technique allows trackers to share
their first party cookies, because the browser is tricked into attaching
cookies from the original website’s subdomain rather than the third party
domain the subdomain redirects to (Dimova et al., 2021). Trackers can access
session cookies, even those belonging to financial institutions, using this
technique (Aliyeva and Egele, 2021; Ren et al., 2021).

Browser fingerprinting is another technique used by trackers to circumvent
partitioned storage and track users across websites. Browser fingerprinting
allows a tracker to use features of a user’s browser such as window size,
installed fonts, supported codecs, and more to create a unique “fingerprint”
of that user that can function as (or generate) a UID (Eckersley, 2010). A
2013 study crawled 20 pages for each of the Alexa top 10,000 sites and found
that 40 performed browser fingerprinting (Nikiforakis et al., 2013). A more
recent study improved detection of fingerprinting code by using machine
learning (Iqbal et al., 2021). They then measured the Alexa top 100,000 sites
and found that 10 percent of them perform fingerprinting. They find
fingerprinting is more common with popular sites, as almost 25% of the Alexa
top 10,000 sites perform fingerprinting.

##  8\. Conclusion

In this work, we present the first systematic study of UID smuggling, a
technique that allows trackers to evade browsers’ protections against cross-
website tracking. We find that UID smuggling is present across 8.1% of the
navigations paths we observed. We publish a list of the entities that
participate in UID smuggling, and classify these entities according to their
behavior and purposes. Our findings can be used by browsers to improve
protections against UID smuggling.

Understanding the scope of UID smuggling, and the techniques by which it is
conducted, is important to continue improving privacy on the Web. Browsers are
increasingly (though not yet universally) trying to protect their users from
being tracked. Understanding how trackers are circumventing new browser
privacy protections is important, to make sure privacy improvements are not
lost as quickly as they’re gained.

## References

  * (1)
  * spo ([n. d.]) [n. d.].  Sports Reference | Sports Stats, fast, easy, and up-to-date.  https://www.sports-reference.com/
  * xvf ([n. d.]) [n. d.].  Xvfb—virtual framebuffer X server for X Version 11\.  https://www.x.org/releases/X11R7.6/doc/man/man1/Xvfb.1.xhtml
  * Acar et al. (2014) Gunes Acar, Christian Eubank, Steven Englehardt, Marc Juarez, Arvind Narayanan, and Claudia Diaz. 2014\.  The web never forgets: Persistent tracking mechanisms in the wild. In _Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security_. 674–689.
  * Aliyeva and Egele (2021) Assel Aliyeva and Manuel Egele. 2021.  Oversharing Is Not Caring: How CNAME Cloaking Can Expose Your Session Cookies. In _Proceedings of the 2021 ACM Asia Conference on Computer and Communications Security_. 123–134.
  * Apple ([n. d.]) Apple. [n. d.].  Prevent cross-site tracking in Safari on Mac.  https://support.apple.com/guide/safari/prevent-cross-site-tracking-sfri40732/mac
  * aslushnikov (2018) aslushnikov. 2018\.  Intercept target creation: Issue #3667.  https://github.com/puppeteer/puppeteer/issues/3667
  * berstend (2018) berstend. 2018.  Target creation event listeners are sometimes not executed early enough: Issue #2669.  https://github.com/puppeteer/puppeteer/issues/2669
  * Bindra (2021) Chetna Bindra. 2021\.  Building a privacy-first future for web advertising.  https://blog.google/products/ads-commerce/2021-01-privacy-sandbox/
  * Black (2021) Paul E. Black. 2021\.  Ratcliff/Obershelp pattern recognition.  https://www.nist.gov/dads/HTML/ratcliffObershelp.html
  * Cyphers (2018) Bennett Cyphers. 2018\.  Privacy Badger Rolls Out New Ways to Fight Facebook Tracking.  https://www.eff.org/deeplinks/2018/05/privacy-badger-rolls-out-new-ways-fight-facebook-tracking
  * Cyphers (2021) Bennett Cyphers. 2021\.  Google’s FLoC Is a Terrible Idea.  https://www.eff.org/deeplinks/2021/03/googles-floc-terrible-idea
  * Dao et al. (2020) Ha Dao, Johan Mazel, and Kensuke Fukuda. 2020.  Characterizing cname cloaking-based tracking on the web. In _Proceedings of IFIP/IEEE Traffic Measurement Analysis Conference (TMA)_.
  * Dimova et al. (2021) Yana Dimova, Gunes Acar, Lukasz Olejnik, Wouter Joosen, and Tom Van Goethem. 2021.  The CNAME of the Game: Large-scale Analysis of DNS-based Tracking Evasion.  _Proceedings on Privacy Enhancing Technologies_ 3 (2021), 394–412.
  * Disconnect ([n. d.]a) Inc Disconnect. [n. d.]a.  https://github.com/mozilla-services/shavar-prod-lists/blob/master/disconnect-entitylist.json
  * Disconnect ([n. d.]b) Inc Disconnect. [n. d.]b.  Tracker Protection Lists.  https://github.com/disconnectme/disconnect-tracking-protection
  * Eckersley (2010) Peter Eckersley. 2010\.  How Unique is Your Web Browser?. In _Proceedings of the 10th International Conference on Privacy Enhancing Technologies_ _(PETS’10)_. Springer-Verlag, Berlin, Heidelberg, 1–18.
  * Englehardt and Narayanan (2016) Steven Englehardt and Arvind Narayanan. 2016.  Online tracking: A 1-million-site measurement and analysis. In _In proc. 2016 ACM SIGSAC conference on computer and communications security_. 1388–1401.
  * Englehardt et al. (2015) Steven Englehardt, Dillon Reisman, Christian Eubank, Peter Zimmerman, Jonathan Mayer, Arvind Narayanan, and Edward W Felten. 2015\.  Cookies that give you away: The surveillance implications of web tracking. In _Proceedings of the 24th International Conference on World Wide Web_. 289–299.
  * Fouad et al. (2020) Imane Fouad, Nataliia Bielova, Arnaud Legout, and Natasa Sarafijanovic-Djukic. 2020.  Missed by filter lists: Detecting unknown third-party trackers with invisible pixels.  _Proc. Priv. Enhancing Technol._ 2020 (2020), 499–518.
  * Foundation ([n. d.]) Electronic Frontier Foundation. [n. d.].  Privacy Badger.  https://privacybadger.org/
  * Goel (2022) Vinay Goel. 2022\.  Get to know the new Topics API for Privacy Sandbox.  https://blog.google/products/chrome/get-know-new-topics-api-privacy-sandbox/
  * Hamilton (2012) Peter Hamilton. 2012\.  Server-to-Server Tracking Basics (Web-Based Affiliate Marketing).  https://www.tune.com/blog/server-side-tracking-basics/
  * Huang et al. ([n. d.]) Tim Huang, Johann Hofmann, and Arthur Edelstein. [n. d.].  Firefox 86 Introduces Total Cookie Protection.  https://blog.mozilla.org/security/2021/02/23/total-cookie-protection
  * IAB ([n. d.]) IAB. [n. d.].  IAB Tech Lab Content Taxonomy.  https://www.iab.com/guidelines/iab-tech-lab-content-taxonomy/
  * Iqbal et al. (2021) Umar Iqbal, Steven Englehardt, and Zubair Shafiq. 2021\.  Fingerprinting the Fingerprinters: Learning to Detect Browser Fingerprinting Behaviors.  _2021 IEEE Symposium on Security and Privacy (S &P)_ (2021), 1143–1161.
  * Johnson et al. (2021) Brian Johnson, Ivan Efremov, and Peter Snyder. 2021\.  Ephemeral Third-party Site Storage.  https://brave.com/privacy-updates/7-ephemeral-storage/
  * Koop et al. (2020) Martin Koop, Erik Tews, and Stefan Katzenbeisser. 2020\.  In-Depth Evaluation of Redirect Tracking and Link Usage.  _Proc. Priv. Enhancing Technol._ 2020, 4 (2020), 394–413.
  * Le Pochat et al. ([n. d.]) Victor Le Pochat, Tom Van Goethem, Samaneh Tajalizadehkhoob, Maciej Korczyński, and Wouter Joosen. [n. d.].  A research-oriented top sites ranking hardened against manipulation - Tranco.  https://tranco-list.eu/
  * Mozilla ([n. d.]) Mozilla. [n. d.].  Enhanced Tracking Protection in Firefox for desktop.  https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop
  * Newman (2021) Jared Newman. 2021\.  The incredibly sneaky way websites sidestep privacy tools to spy on you.  https://www.fastcompany.com/90663878/bounce-tracking-privacy-browsers-brave-firefox-safari-edge
  * Nikiforakis et al. (2013) Nick Nikiforakis, Alexandros Kapravelos, Wouter Joosen, Christopher Kruegel, Frank Piessens, and Giovanni Vigna. 2013.  Cookieless Monster: Exploring the Ecosystem of Web-Based Device Fingerprinting. In _2013 IEEE Symposium on Security and Privacy_. 541–555.  https://doi.org/10.1109/SP.2013.43
  * Papadopoulos et al. (2019) Panagiotis Papadopoulos, Nicolas Kourtellis, and Evangelos Markatos. 2019.  Cookie Synchronization: Everything You Always Wanted to Know But Were Afraid to Ask. In _The World Wide Web Conference on - WWW ’19_. ACM Press, San Francisco, CA, USA, 1432–1442.  https://doi.org/10.1145/3308558.3313542
  * Papadopoulos et al. (2018) Panagiotis Papadopoulos, Nicolas Kourtellis, and Evangelos P. Markatos. 2018.  Exclusive: How the (synced) Cookie Monster breached my encrypted VPN session. In _Proceedings of the 11th European Workshop on Systems Security_. ACM, Porto Portugal, 1–6.  https://doi.org/10.1145/3193111.3193117
  * Ren et al. (2021) Tongwei Ren, Alexander Wittman, Lorenzo De Carli, and Drew Davidson. 2021.  An Analysis of First-Party Cookie Exfiltration due to CNAME Redirections.  _In proc. Workshop on Measurements, Attacks, and Defenses for the Web (MADWeb)_.
  * repository ([n. d.]) Chromium Git repository. [n. d.].  User Data Directory.  https://chromium.googlesource.com/chromium/src.git/+/HEAD/docs/user_data_dir.md
  * Schechner et al. (2022) Sam Schechner, Patience Haggin, and Tripp Mickle. 2022\.  Google Overhauls Cookie Replacement Plan After Privacy Critiques - WSJ.  https://www.wsj.com/articles/google-overhauls-cookie-replacement-plan-after-privacy-critiques-11643115603
  * Schuh (2020) Justin Schuh. 2020\.  Building a more private web: A path towards making third party cookies obsolete.  https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html
  * Snyder (2021) Peter Snyder. 2021\.  Debouncing.  https://brave.com/privacy-updates/11-debouncing/
  * Snyder and Yasskin (2021) Peter Snyder and Jeffrey Yasskin. 2021.  Navigational-Tracking Mitigations.  https://privacycg.github.io/nav-tracking-mitigations/
  * Urban et al. (2018) Tobias Urban, Dennis Tatang, Martin Degeling, Thorsten Holz, and Norbert Pohlmann. 2018.  The unwanted sharing economy: An analysis of cookie syncing and user transparency under GDPR.  _arXiv preprint arXiv:1811.08660_ (2018).
  * Urban et al. (2020) Tobias Urban, Dennis Tatang, Martin Degeling, Thorsten Holz, and Norbert Pohlmann. 2020.  Measuring the Impact of the GDPR on Data Sharing in Ad Networks. In _Proceedings of the 15th ACM Asia Conference on Computer and Communications Security_. ACM, Taipei Taiwan, 222–235.  https://doi.org/10.1145/3320269.3372194
  * Vastel et al. (2020) Antoine Vastel, Walter Rudametkin, Romain Rouvoy, and Xavier Blanc. 2020.  FP-Crawlers: Studying the Resilience of Browser Fingerprinting to Block Crawlers. In _Proceedings 2020 Workshop on Measurements, Attacks, and Defenses for the Web_. Internet Society, San Diego, CA.  https://doi.org/10.14722/madweb.2020.23010
  * Wakefield (2022) Jane Wakefield. 2022\.  Google slammed over ad-cookie replacement flip-flop.  _BBC News_ (26 Jan. 2022).  https://www.bbc.com/news/technology-60138876
  * WebKit (2019) WebKit. 2019.  Tracking Prevention Policy.  https://webkit.org/tracking-prevention-policy/
  * Webshrinker ([n. d.]a) Webshrinker. [n. d.]a.  IAB Categories.  https://docs.webshrinker.com/v3/iab-website-categories.html#iab-categories
  * Webshrinker ([n. d.]b) Webshrinker. [n. d.]b.  Webshrinker Website.  https://www.webshrinker.com/
  * Wilander (2019) John Wilander. 2019\.  Intelligent Tracking Prevention 2.3.  https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/