#  CookieGuard: Characterizing and Isolating the First-Party Cookie Jar

Pouneh Nikkhah Bahrami  University of California, Davis
Email<EMAIL_ADDRESS>Aurore Fass  CISPA Helmholtz Center for
Information Security
Email<EMAIL_ADDRESS>Zubair Shafiq  University of California, Davis
Email<EMAIL_ADDRESS>
###### Abstract

As third-party cookies are going away, first-party cookies are increasingly
being used for tracking. Prior research has shown that third-party scripts
write (or ghost-write) first-party cookies in the browser’s cookie jar because
they are included in the website’s main frame. What is more is that a third-
party script is able to access all first-party cookies, both the actual first-
party cookies as well as the ghost-written first-party cookies by different
third-party scripts. Existing isolation mechanisms in the web browser such as
SOP and CSP are not designed to address this lack of isolation between first-
party cookies written by different third-parties. We conduct a comprehensive
analysis of cross-domain first-party cookie retrieval, exfiltration, and
modification on top-10K websites. Most notably, we find 18% and 4% of the
first-party cookies are exfiltrated and overwritten, respectively, by cross-
domain third-party scripts. We propose CookieGuard to introduce isolation
between first-party cookies set by different third-party scripts in the main
frame. To this end, CookieGuard intercepts cookie get and set operations
between third-party scripts and the browser’s cookie jar to enforce strict
isolation between first-party cookies set by different third-party domains.
Our evaluation of CookieGuard shows that it effectively blocks all cross-
domain cookie read/write operations to provide a fully isolated cookie jar.
While it generally does not impact appearance, navigation, or other website
functionality, the strict isolation policy disrupts Single Sign-On (SSO) on
just 11% of websites that rely on first-party cookies for session management.
Our work demonstrates the feasibility of isolating first-party cookies.

##  1 Introduction

Third-party cookies enable trackers to collect a user’s browsing history
across the web. To improve privacy, all major browser vendors have started to
block or restrict third-party cookies [1, 2, 3, 4]. This has prompted third-
party trackers to start using first-party cookies for tracking [5]. Cookies
set by these third-party scripts in the main frame111A practice that is now
known as cookie ghost-writing [6, 7, 5] are treated as first-party cookies by
the web browser. Put simply, web browsers currently do not distinguish between
first-party cookies that are actually set by the first-party vs. first-party
cookies that are actually ghost-written by third-party scripts in the main
frame.

All scripts in the main frame, whether first-party or third-party, have
unrestricted access to all first-party cookies in the browser’s cookie jar,
regardless of whether they actually originally set the cookie. There is no
isolation between different sources of first-party cookies, both actual first-
party cookies and ghost-written first-party cookies by various third-party
scripts. This lack of isolation means that any script in the main frame can
invoke the getter function of document.cookie, prompting the browser to return
all first-party cookies stored in the cookie jar. This capability enables
third-party scripts not only to read their own cookies but also those set by
the first-party or other third-party scripts but also exfiltrate them to any
remote endpoint of their choice through link decoration [5, 6, 7]. Moreover,
third-party scripts can also use the setter function of document.cookie to
modify (overwrite or delete) cookies that they did not originally create.

While this seemingly problematic practice is starting to become known in
recent research literature, prior work lacks an in-depth measurement as well
as an effective intervention. To bridge this gap, we aim to solve the
following two key research questions in this paper:

$\bullet$ What is the prevalence of retrieval, exfiltration, and modification
(including both overwriting and deletion) of first-party cookies in the cookie
jar by third-party scripts?

$\bullet$ How can web browsers effectively isolate first-party cookies in the
cookie jar to prevent unauthorized access, exfiltration, or modification by
third-party scripts?

Web browsers have some built-in security mechanisms that allow developers to
control which resources can be loaded on their websites and how they share
access to these resources. One such mechanism, the Same-Origin Policy (SOP)
[8], restricts how resources from one origin can interact with resources from
another origin. However, SOP does not restrict third-party scripts included in
the main frame because it treats them as belonging to the same first-party
origin since they are not isolated in an iframe. Another mechanism, Content
Security Policy (CSP) [9], enables web developers to establish policies that
restrict which scripts can be loaded on a website. However, CSP’s protection
is relatively coarse-grained in that it allows a website publisher to control
which scripts can/cannot load but it offers no control over the cookies that
it can read or write from the browser’s cookie jar.

Recent research literature has found evidence of first-party cookie
manipulation and exfiltration by third-parties. Sanchez-Rola et al. [7]
measured the extent of first-party cookie ghostwriting and exfiltration on the
web. They found long chains of interactions among numerous entities to share
the same first-party cookie. Chen et al. [6] also studied the prevalence of
first-party cookies set by third-party scripts. They also found evidence of
cookie modification and exfiltration of first-party cookies by ghost scripts.
These studies generally focus on measuring the prevalence of ghost-written
cookies and do investigate first-party cookie exfiltration and manipulation.
However, they do not offer a comprehensive analysis of first-party cookie
modification and exfiltration and they also do not provide any intervention to
counter such practices. Munir et al. [5] proposed an intervention mechanism to
block ghost-written first-party tracking cookies. However, their approach does
not address the more fundamental problem of first-party cookie isolation,
i.e., whether first-party cookies can be accessed or modified by different
third-party scripts.

In this paper, we first conduct a comprehensive analysis of cross-domain
first-party cookie modification and exfiltration on the top-10K websites. Our
results show that 60% of the scripts included in the main frame are third-
party scripts, and of these 64% are advertising and tracking. We find that
cross-domain first-party cookie exfiltration and manipulation is widespread.
We find evidence of cross-domain cookie exfiltration on 42% of the websites
and manipulation on 32% of the websites. Overall, 18% and 4% of the first-
party cookies are exfiltrated and overwritten, respectively, by cross-domain
third-party scripts.

We propose CookieGuard, a browser-based intervention designed to isolate
first-party cookies ghost-written by third-party scripts in the main frame.
Our implementation of CookieGuard as a browser extension keeps track of first-
party cookie names and their creators’ domains. Based on its bookkeeping, it
alters the browser’s default interactions with the cookie jar by patching the
getter and setter functions of document.cookie. Specifically, CookieGuard
removes cookies from the getter response if they were not created by the
calling script’s domain. It also prevents third-party scripts from modifying
first-party cookies created by other third parties when the setter function is
invoked.

In our implementation of CookieGuard, we establish a simple isolation
boundaries based on domain-level isolation. This approach ensures that cookies
ghost-written by third-party scripts are effectively isolated from those set
by first-party scripts. However, we are able to include more sophisticated
rules, such as treating all domains owned by a single company as equivalent,
to prevent potential breakage in web functionality.

Our evaluation of CookieGuard shows that it successfully prevents all cross-
domain manipulation and exfiltration of first-party cookies without disrupting
website functionality. CookieGuard breaks 11% of the websites that implement
SSO and rely on first-party cookies for session management. Our browser
extension implementation of CookieGuard adds an average of 14.8% page load
overhead.

Our key contributions include:

  1. 1.

a comprehensive analysis of first-party cookie manipulation and exfiltration
at scale.

  2. 2.

the design and implementation of our intervention: a browser extension to
isolate first-party cookies. We will release the source code our tool.

  3. 3.

an evaluation of the impact of our intervention on website functionality and
its performance overhead.

##  2 Background

###  2.1 Security Mechanisms

Modern web browsers are equipped with a variety of security mechanisms
designed to protect users from threats and vulnerabilities while browsing the
internet. We discuss below mechanisms that provide enhanced protection for
scripts and cookie management.

Same-Origin Policy (SOP). The SOP [8] is a security mechanism that restricts
how a script loaded by one origin can interact with resources from other
origins. For example, the origin for the URL https://www.example.com:443/path
would be https://www.example.com:443. This origin includes the scheme (https),
the host (www.example.com), and the port (443). This policy ensures that
scripts running in a browser can only access resources from the same origin,
effectively isolating different websites from each other to prevent attacks
such as cross-site request forgery and data theft. Under SOP, even different
frames or iframes within the same web page are treated as separate browsing
contexts, limiting their interaction to scenarios where they share the same
origin.

Content Security Policy (CSP). The CSP [9] is another security feature. It
allows web developers to control which resources (including scripts,
stylesheets, and images) from which origins can be included and executed on a
web page. CSP can be implemented through an HTTP header sent from the server
or via a meta tag in the HTML document. CSP does not directly manage cookies
or their creation, it indirectly aids in securing them by restricting how and
where scripts can be included and executed on the website.

###  2.2 Inclusion of Scripts

Script inclusion can be either (1) direct if a developer explicitly references
a script using the <script> HTML tag or inserts an inline script in the HTML
source; or (2) indirect if a directly included script includes additional
scripts using the new script tag, import, or eval.

Any scripts that are included in the main frame of a website are treated like
first-party and have full access to all shared resources, such as cookies, DOM
elements, and other sensitive data, under the website’s origin.

CSP can be used to control the inclusion of scripts on a web page from other
origins. Scripts included in iframes with other origins are restricted by the
SOP to access the shared resources of the main frame.

###  2.3 Cookie Management in Web Browsers

Cookies can be created and accessed in two distinct ways: either by scripts or
through HTTP responses/requests.

HTTP cookies. HTTP cookies are created through the Set-Cookie header in HTTP
responses. If the response comes from a same-origin domain as the website, the
cookie is classified as a first-party cookie. Otherwise, it is classified as a
third-party cookie. Once cookies have been created, they are included by the
browser in all subsequent requests to the same domain, provided that the path
and domain conditions match. There is no policy to force first-party cookies
to be sent over cross-origin requests even if Access-Control-Allow-Credentials
in CORS header is set to true. To enhance security, the HttpOnly attribute can
be set to True when creating a cookie. A cookie created with this attribute
will only be sent in HTTP requests to the server, and will not be accessible
via scripts.

Script cookies. Cookies can be created and accessed by a script by calling the
document.cookie property in JavaScript. If the cookie is created by a script
and the script is included in the main frame of a website, it is classified as
first-party cookie. Otherwise it is classified as third-party cookie. Browsers
enforce SOP for cookies, which restricts scripts to creating and accessing
cookies only if their domain of origin matches the script’s domain of origin.
For instance, if tracker.com/myscript.js is included in the main frame of
example.com and creates a cookie there, the domain of the cookie is
example.com. This is because the domain of origin for the script is considered
to be example.com, where it is executed. All scripts directly or indirectly
included in the main frame have full access to all first-party cookies. They
can retrieve and manipulate all first-party cookies. Script cookies are not
subject to CORS headers and are primarily governed by the Same-Origin Policy.

Cookies’ category. Browsers have a simple perspective on cookies; cookies are
either first party (created by same-origin domains as the visited website’s
domain) or third party (created by third-party domains that hosted resources
requested by the website). However, as a previous study shows [7] this
perspective does not capture the full picture of cookie creation and sharing
on a website. There is a third category for cookies called ghost-written
cookies. These cookies are created by third-party scripts included in the main
frame. Therefore they are still considered as first-party cookies.

##  3 Threat Model

In this section, we outline the threat model associated with including third-
party scripts in the main frame. SOP restricts interactions between distinct
origins in a web browser. This means that a script running in one frame cannot
access the resources in frames with a different origin. As illustrated in
Figure 1, a script is included in an <iframe> originating from a different
domain than that of the main frame. Due to the SOP, this script is not
authorized to access the resources of the main frame such as the cookie jar or
DOM entities. Nevertheless, website developers often introduce third-party
scripts into the main frame, whether intentionally [10, 11] or unintentionally
[12]. In certain cases, third-party scripts cannot function as intended unless
they are included in the main frame. For example, analytics libraries need to
access specific user interaction metrics, such as mouse movements and clicks.
These metrics cannot be effectively captured if the script is executed within
a separate iframe. In Figure 1, a third-party script, is included in the main
frame, which gains access to the resources on the main frame, including the
HTML DOM, and cookie jar, or other included first-party scripts. We refer to
the interactions of this third-party script with the main frame’s resources as
“cross-domain” interactions.222 The domain (eTLD+1) is part of the origin,
which includes the full domain name, scheme, and port. For example,
https://example.com:8080 and https://subdomain.example.com:8080 have different
origins due to varied host names, despite the same scheme, port, and domain.
However, our focus is on cross-domain script interactions rather than cross-
origin, aiming to understand how third-party scripts from various domains
interact in the main frame. In this threat model, the adversary is a third-
party script that is not subject to SOP restrictions, because it is directly
included by the web developer (or indirectly included by another script) in
the main frame of the website. The inclusion of this third-party script poses
security and privacy risks. The adversary might exploit its access to the main
frame’s cookie jar, for example, collect and exfiltrate sensitive information
stored in cookie values such as browsing history, location data, or even login
states. If cookies include session identifiers, which are used to maintain a
user’s state on a website, reading these cookies can allow an attacker to
hijack the user’s session [13]. This can enable the attacker to impersonate
the user and gain unauthorized access to their accounts on various services.

Figure 1: Access of a script included in the main frame of a website to shared
resources.

##  4 Measurement Methodology

To measure the prevalence of cross-domain cookie manipulation and the actors
of such manipulations, we need to get access to the execution behavior of
scripts within web pages. Our solution, pagegraph+, is structured around a
well-defined three-step workflow, enabling us to effectively measure cross-
domain script interactions. The key components of this workflow are:

  * •

Web Crawler tool: Initially, we leverage a modified version of PageGraph [14]
to record web page behavior.

  * •

Data Collection: Subsequently, we automatize web page crawling using
PageGraph, consistently gathering comprehensive page behavior data.

  * •

Analysis Command Line Tool: Finally, we implement a command-line tool called
pagegraph+, tailored to the specific needs of our research. This tool
meticulously analyzes the data we have collected, allowing us to detect
various cross-domain script interactions.

We provide a breakdown of these components below.

###  4.1 Web Crawler

To comprehensively capture a script’s interactions with a website’s resources,
we employ web crawlers to log all page activities. Web crawlers serve to
initiate application-layer protocol requests and handle corresponding
responses. Their methods of request and response handling can vary
significantly [15]. Some crawlers, like cURL [16], Wget [17], and ZAP [18],
directly interact with the application layer of the networking stack, treating
web content as static files, and using HTTP GETs or POSTs to navigate a
website. These crawlers do not interface with web browsers, resulting in
incomplete data as they cannot render dynamic content. In contrast, others
like PhantomJS [19], Selenium [20], and Puppeteer [21] rely on driving web
browsers to generate application-layer requests. They provide wrappers to
access browser-based JavaScript APIs for interacting with and manipulating the
DOM. Certain crawlers, such as OpenWPM [22], AdGraph [23], PageGraph [14], and
WEBGRAPH [24], implement wrappers around crawlers like Selenium. OpenWPM and
WEGGRAPH employ Firefox browsers to drive while AdGraph and PageGraph use
Chromium. These wrappers enhance functionality, enabling actions like
mimicking user interactions, gathering data at different layers (network,
application, and content), and capturing screenshots. Access to these layers
is vital for privacy measurement studies, including web page fingerprinting,
tracking analysis, and censorship identification. Hence, our primary focus
lies with the latter group of crawlers. OpenWPM [22] stores data in a tabular
format. In contrast, tools like AdGraph [23], PageGraph [14], and WebGraph
[24] utilize a graph structure to capture information flow across HTML,
network, script, and storage layers. This graph-based structure provides a
comprehensive record of network requests and DOM changes, facilitating precise
tracing of behavior back to its source–whether it is some script or the
browser’s HTML parser. For recording page behavior, WebGraph is built on top
of OpenWPM, capturing the execution and interaction of HTML, network, script,
and storage layers in a graph format. However, PageGraph, an advanced
iteration of AdGraph, stands out by directly representing page actions in a
graph format. Therefore, PageGraph is the preferred choice for capturing page
behavior in our work.

PageGraph is implemented by deeply instrumenting the chromium browser V8
JavaScript engine as well as the Blink HTML rendering engine to capture and
annotate each frame of a web page at run-time in a unified directed graph
structure. Nodes of this graph correspond to entities such as DOM elements,
scripts, HTTP resources, or different storage mechanisms, e.g., cookie jar or
local storage. Edges represent relationship between nodes such as HTTP
requests and script interactions with DOM elements, e.g., insert, remove, set
attribute, etc. Details about the types of nodes and edges, as well as an
example of a graph generated when a web page is crawled, are provided in
Appendix 11.1.

###  4.2 Data Collection

We perform a large-scale web crawling to collect a large data set of websites.
We start by crawling the landing page of the top-10k websites from the
Universal Tranco list [25] which is a global top-ranking list, for this
purpose.

We use PageGraph to crawl the pages and record page behaviors including script
and other resource inclusion. PageGraph generates an XML-encoded graph for
each page execution, encapsulating the structure of the HTML document’s DOM
and the associated events that shape and alter it. As mentioned earlier,
within this graph, nodes symbolize various entities, including DOM elements,
scripts, HTTP resources, storage mechanisms, and JavaScript APIs provided by
the DOM. Edges within the graph signify connections between nodes,
representing associations such as DOM structures, script interactions with DOM
elements, DOM events, JavaScript API usage, and HTTP requests. PageGraph
generates a graph per frame/iframe on a web page. We are mainly interested in
cross-domain interactions between different third-party scripts that are
outside the purview of the SOP. According to the SOP, anything inside an
iframe/frame is not allowed to modify or access the DOM of the top page if
they do not have the same origin. Therefore, we only analyze the main frame
graph for each visited website.

###  4.3 Command Line Analysis Tool

To measure the prevalence of cross-domain cookie manipulation and responsible
scripts for such actions, we implement a command-based tool in Rust and built
on top of PageGraph. More precisely, it takes PageGraph generated graphs in
the graphml format as input, analyzes page behavior, and generates an output
in JSON format. Detailed information about the available commands and their
usage syntax is provided in Appendix 11.2. For this paper, we only use Storage
Access and Chain of Scripts queries.

###  4.4 Identifying Advertising & Tracking Resources

Throughout this paper, one of our primary objectives is to identify tracking
and advertising scripts that are included in the main frame. To this end, we
leverage the adblockparser [26] tool that is designed for matching URLs
against filter rules. We combine nine popular crowd-sourced filter lists [27,
28, 29, 30, 31, 32, 33, 34, 35], including EasyList and EasyPrivacy, that are
specifically curated to target URLs associated with advertising and tracking.
Note that we classify each occurrence of a third-party script URL within a
particular website context as advertising & tracking or not.

##  5 Measurements & Analysis

Including third-party scripts in the main frame subjects them to the SOP,
treating them as if they have the same origin as first-party scripts. Thus,
third-party scripts included in the main frame get access to all shared
resources within the main frame, including the first-party cookie jar or other
browser storage. In this section, we first investigate the prevalence of both
direct and indirect third-party script inclusion on the Web. We then
investigate who accesses the first-party cookie jar, how, and how much; and
the prevalence of cross-domain cookie manipulation and exfiltration.

###  5.1 Third-Party Script Inclusion in the Main Frame

We start by measuring the prevalence of third-party script inclusions
(directly or indirectly included) in the main frame of websites. We find that
third-party script inclusion in the main frame is quite prevalent. At least
one third-party script is present on 93.3% of the websites, in line with prior
work findings [36], with an average of 19 unique third-party scripts from 9
unique domains (eTLD+1)333“eTLD+1” refers to the effective top-level domain
plus one additional level, typically a subdomain; for instance, in
https://store.example.com, the eTLD+1 is example.com per website. The third-
party scripts included in the main frame of the top-10k websites are served
from 3,996 distinct domains. Using the methodology described in Section 4.4,
we find that, on average, 70% of the third-party scripts included in the main
frame are associated with advertising and tracking services.

We categorize included scripts into direct and indirect inclusions. We find
that 90.7% of the top-10k websites contain at least one script included
indirectly. On average, each website includes 10 scripts directly
(encompassing both first- and third-party scripts). Indirect inclusion
accounts for approximately 18 scripts, i.e., there are almost 2 times more
indirectly included scripts than included scripts on a website. Figure 2
presents the distribution of first-party and third-party scripts,
distinguishing between direct and indirect inclusions. The occurrence of
third-party scripts among indirectly included scripts is approximately 2.5
times that of directly included scripts. Notably, 33% of indirectly included
scripts are identified as advertising and tracking, compared to only 8.3% of
directly included scripts.

Figure 2: Proportional distribution of directly and indirectly included
scripts, categorized by first-party (1P) and third-party (3P) origins. Dotted
sections within each bar represent the advertising/tracking component.

We list the scripts that are included on a website, whether directly or
indirectly. If a script is included both directly and indirectly, to avoid
counting the same script twice on a website, we exclusively count this as a
direct inclusion. These scripts are then ranked based on their frequency of
inclusion, e.g., a script included more often gets a higher rank, with a
separation on direct vs. indirect inclusion. The top 10 scripts’ domains for
both categories are presented in Table I. As observed, googletagmanager.com is
the most frequently included domain for scripts, encompassing both direct and
indirect inclusions. While only 10% of scripts from this domain are directly
included across 10,000 websites, a substantial 90% are included indirectly.
This substantial disparity can be explained by the typical use of Google Tag
Manager (GTM) by web developers. When a developer includes a script from
googletagmanager.com on their website, it allows GTM to manage script and HTML
tags, which are primarily used for tracking and analytics, without altering
the website’s code. GTM operates through container tags that can dynamically
inject other tags based on predefined rules and triggers. Consequently, when a
tag within GTM activates, it prompts GTM to load additional scripts specified
in that tag. This could include analytics scripts, marketing automation
scripts, or any third-party scripts including scripts from
googletagmanager.com. Then googletagmanager.com starts including required
scripts including google-analytics.com and other scripts from the same or
other domains.

However, there are certain domains that are included mostly directly or
indirectly. For example, 98.4% of cloudflareinsights.com inclusions are
direct, across the top 10k sites. This script measures all raw requests made
to a website, regardless of whether it is cached or uncached, or if the user
has adblock or JavaScript turned off. On the other hand, a number of scripts
such as doubleclick.net and adobedtm.com are included indirectly over 90% of
the time. These scripts are being used for advertising and tracking purposes.
As evident in Table I host sites do not directly control and include trackers
but dynamic tag management tools such as GTM opens the gate for such trackers.

Direct | % | Indirect | %
---|---|---|---
googletagmanager.com | 10 | googletagmanager.com | 90
cloudflare.com | 75 | google-analytics.com | 98.7
cloudfront.net | 53.1 | facebook.net | 98.6
google.com | 15.4 | doubleclick.net | 91.4
cookielaw.org | 33.4 | google.com | 84.6
googleapis.com | 46.8 | googlesyndication.com | 0.84
googlesyndication.com | 0.2 | adobedtm.com | 90.7
jsdelivr.net | 55.9 | newrelic.com | 99.5
doubleclick.net | 8.6 | tiqcdn.com | 95.8
cloudflareinsights.com | 98.4 | gstatic.com | 83.4

TABLE I: The top 10 scripts’ domains, categorized based on direct or indirect
inclusion.

The inclusion of all third-party scripts could be attributed to website
developers. However, this is not always the case, as a third-party script may
indirectly include additional third-party scripts, potentially creating a
chain of indirectly included scripts [37, 38]. On several websites, such as
timesofisrael.com, boingboing.net, psychiatryonline.org, and netkeiba.com,
these inclusion chains extend to up to 14 scripts. Thus, these third-party
scripts are typically not explicitly trusted by the website developers [37].
On the other hand, there are examples such as googletagmanager.com, where web
developers may have some control over indirectly included scripts but do not
necessarily have full knowledge and control over them [39, 40].

We note that by doing so, web developers place significant trust in scripts
that they do not directly include. As mentioned in our threat model in Section
3, including scripts in the main frame of websites grants them full access to
shared resources, including cookies and DOM entities. The lack of control over
these inclusions, primarily consisting of tracking and advertising scripts,
poses significant privacy concerns and risks exposing users’ sensitive
information, such as their Personally Identifiable Information (PII). Users
typically do not see or understand what scripts are running in the background
and what data is being collected. This lack of transparency can undermine
trust and prevent users from making informed decisions about their privacy.

###  5.2 Cross-Domain Cookie Retrieval, Exfiltration, and Manipulation

In this section, we analyze cross-domain retrieval, exfiltration, and
manipulation (including overwriting and deleting cookies), of first-party
cookies in the cookie jar by third-party scripts included in the main frame.
To analyze such actions by third-party scripts, we run “Storage Access” and
“Network Requests” queries within PageGraph+ (cf. Table VIII). Then, we sort
network requests as well as cookie jar accesses and actions performed by all
scripts in chronological order based on their timestamps. We refer to the
initial script that creates a cookie name/value as its creator. Before
analyzing cross-domain actions on cookies, we study the total number of
cookies created across 10,000 websites.

####  5.2.1 Prevalence of Ghost Written First-Party Cookies

Web browsers treat ghost written cookies as first-party cookies. In this
section, we assess the prevalence of such cookies created in the main frame.

We find that 92.03% (98,728) of all first-party cookies are ghost written
cookies, set by third-party scripts, with 85.14% of them being indirectly
included. On average, 5 third-party scripts create 12.3 unique ghost written
first-party cookies per web site. However, there are outliers; for example,
clover.com includes 20 different third-party scripts, 17 of which are
categorized as tracking scripts, creating 83 ghost-written first-party
cookies.

####  5.2.2 Quantifying the Risk

Given the shared access to the cookie jar by all scripts in the main frame, we
now quantify the prevalence of first-party cookie retrieval, exfiltration, and
manipulation by any scripts other than the creator script domain. We
identified 28,821 unique cookie names created by 20,046 unique scripts across
10,000 websites. If we associate each cookie with its corresponding creator
script domain and count the number of pairs (cookie name, creator script
domain), we observe nearly 1.7 times more entries, totaling 49,575 pairs. This
indicates that cookie names are often duplicated, with different scripts
creating cookies under the same name. Consequently, this raises concerns about
potential unauthorized retrieval and manipulation of cookies by cross-domain
scripts, which we will explore further.

In the following Sections 5.2.3 and 5.2.5, we investigate four types of
interactions:

  * •

retrieval: a cross-domain script reads a cookie created by another script;

  * •

over-writing: a cross-domain script modifies the value of a cookie created by
another script;

  * •

deletion: a cross-domain script deleted a cookie created by another script;

  * •

exfiltration: a cross-domain script exfiltrates a cookie created by another
script.

####  5.2.3 Cookie Retrieving and Exfiltration

| Exfiltration | Retrieving | Overwriting | Deleting
---|---|---|---|---
% of sites | 41.4 | 43.1 | 31.88 | 2.3
TABLE II: Percentage of sites that have at least one interaction including
retrieving, overwriting, deleting, and exfiltration on cookies by cross-domain
scripts.

In this section, we investigate third-party scripts on the main frame that
retrieve cookie data originally created by other scripts and then exfiltrate
this data to third-party resources. Invoking the document.cookie API returns
the entire cookie jar, thus all scripts on the main frame have access to all
first-party and ghost-written cookies and may potentially exfiltrate them.

We adopted a heuristics-based method, as described in previous studies [41,
42], to detect cookie exfiltration by cross-domain scripts. Initially we must
detect identifiers in both cookie values and the query parameters of URLs
originating from third-party scripts in the main frame. To detect cookie
identifiers, assuming the format of cookie is (name1 =)value1|...|(nameN
=)valueN where $|$ represents any character except non-alphanumeric characters
[a-zA-Z0-9 -=], we iterates through value strings, splitting each on non-
alphanumeric characters. We then retain strings that meet or exceed the
specified length (eight characters in our case), considering them potential
identifiers. For each identifier, we generate three encoded forms: 1) Base64
encoding, 2) MD5 hash, and 3) SHA1 hash. To detect identifiers from query
parameters, we parse all URLs originating from third-party scripts on the main
frame to retrieve the query string. Following a similar algorithm to that used
for detecting cookie identifiers, we extract potential identifiers from these
query strings. Finally, we compare the cookie identifiers with those found in
query strings. If they match and originate from different domains, we classify
this as cross-domain identifier exfiltration.

####  5.2.4 Prevalence of Cookie Retrieving and Exfiltration

As evident from Table II, first-party cookies are retrieved by third-party
scripts other than the creator scripts on almost half of the websites (43.1%),
and first-party cookies are exfiltrated on 41.4 % of the websites. If we
consider all cookies (107,278) across 10,000 websites, 17.67% (18,960) of them
are retrieved and exfiltrated by cross-domain scripts. The prevalence of
cookies retrieval and exfiltration poses a significant threat to users’
privacy and security. It is noteworthy that even highly sensitive web
services, such as banks, host advertising, and tracking scripts could allow
third-party services to access privacy-sensitive information like users’
personally identifiable information (PII) and security-sensitive data,
including session cookies [13]. Session cookies, which authenticate users to
web services, when shared with unverified third-party resources, could easily
facilitate account takeovers.

Dominant players: Figure 3 presents the top script domains engaged in cross-
domain cookie retrieval and exfiltration. The x-axis represents the top
engaged domains, while the y-axis indicates the percentage of the total
actions—retrieval and exfiltration—performed by these domains.

Figure 3: Top 10 cookie retrievers and exfiltrators sorted based on the number
of their actions on cookies.

google-analytics.com is the top exfiltrator, accounting for 18.38% of all
cross-domain cookie retrievals and 16.4% of all cookie exfiltrations. This
domain is primarily associated with analytics services aiming to analyze users
behavior by collecting information and exfiltrating them. Other domains such
as chartbeat.com is also an analytics services. Further investigation of
domains beyond the top 10, which are not shown in Figure 3, reveals that
several Ad Exchanges, including doubleclick.net, amazon-adsystem.com, and
pubmatic.com, are also among the top exfiltrators. The reason for observing Ad
Exchanges among top exfiltrators is how Real-Time Bidding (RTB) systems
actually works [43]. When an RTB auction takes place on a website a user is
visiting, the RTB system sends bid requests to potential bidders. These bid
requests can include user information and other cookies on the user’s system
that may have been created by different scripts. The number of websites
supporting RTB systems is expanding; 14.3% of top Tranco websites support RTB
system [44]. Therefore, we expect to observe a large number of data
exfiltration from such domains raising concerns about unauthorized access and
misuse of user data by cross-domain scripts.

Left side of Table III lists the top cookies (along with their creators) that
have been most frequently exfiltrated by exfiltrators. The table also provides
the number of cross-domain scripts (attackers) responsible for cookie
exfiltration and the percentage of websites affected by such action by each
attacker. For example, _gid and _ga cookie set by google-analytics.com have
been targeted by respectively 692 and 569 cross-domain scripts on 17% and
13.7% of websites. These cookies, which distinguish users up two years [45],
are often exfiltrated to synchronize the _gid and _ga identifiers across
various websites, facilitating user behavior tracking beyond the initial site
where the cookie was set.

As we discussed, when the document.cookie command is called by a script, it
grants the access to the entire cookie jar. Given the widespread presence of
domains such as google-analytics.com and googletagmanager.com on more than
half of all websites [5], it is reasonable to hypothesize that cookies
associated with these domains are frequently targeted for exfiltration by
other scripts. To clarify this analysis, we categorize cookies that are
targeted for cross-domain exfiltration by calculating the ratio of the number
of exfiltrating actors to the number of sites where these cookies are
observed. The right side of Table 1 displays cookies most frequently
exfiltrated by cross-domain scripts, sorted according to this ratio. Notably,
cookies set by osano.com, a cookie consent management platform (CMP), show the
highest ratio of exfiltration. osano.com helps websites comply with data
privacy laws such as the EU Cookie Law, GDPR, and CCPA. This platform enables
websites to customize their cookie consent popups and manage user consents
effectively. Cookies created by osano.com have been exfiltrated by 14 unique
domain scripts, 12 of which are predominantly involved in advertising and
tracking, as observed on websites like chicagotribune.com.

Exfiltration (sorted by No. attackers) | Exfiltration (sorted by ratio)
---|---
(cookie_name, creator) | No. attackers | % sites | (cookie_name, creator) | No. attackers | % sites | ratio
(_gid, google-analytics.com) | 692 | 17.04 | (_sp_flow.b979, osano.com) | 14 | 0.01 | 0.14
(_ga, google-analytics.com) | 569 | 13.73 | (_sp_ses.b979, osano.com) | 14 | 0.01 | 0.14
(_fbp, facebook.net) | 533 | 7.97 | (_sp_id.b979, osano.com) | 14 | 0.01 | 0.14
(_gcl_au, googletagmanager.com) | 304 | 10.85 | (bounceClientVisit2051v, osano.com) | 14 | 0.01 | 0.14
(OptanonConsent, cookielaw.org) | 243 | 3.60 | (_gd1674650825010, rubiconproject.com) | 14 | 0.01 | 0.14
(_ga, googletagmanager.com) | 220 | 10.85 | (_admrla, osano.com) | 13 | 0.01 | 0.13
(lotame_domain_check, crwdcntrl.net) | 199 | 1.74 | (_sp_flow.da74, osano.com) | 13 | 0.01 | 0.13
(_hjTLDTest, hotjar.com) | 165 | 2.04 | (_sp_ses.da74, osano.com) | 13 | 0.01 | 0.13
(_parsely_session, parsely.com) | 134 | 1.17 | (_sp_id.da74, osano.com) | 13 | 0.01 | 0.13
(cto_bundle, criteo.net) | 113 | 0.89 | (bounceClientVisit2057v, osano.com) | 13 | 0.01 | 0.13

TABLE III: Top 10 cookie names and their owner domains, which have been
subjected to exfiltration by cross-domain scripts across 10,000 websites. The
table also provides the number of cross-domain scripts (attackers) responsible
for cookie exfiltration and the percentage of websites affected by such
manipulation from each attacker. Cookies on the left side of the table are
sorted based on the number of attackers and the right side table is sorted
based on the ratio of number of attackers to the percent of sites they have
been exfiltrated from.

####  5.2.5 Cookie Overwriting and Deletion

Next, we focus on cookies that were initially created by a script but was
later manipulated (over-written or deleted) by a third-party script. Invoking
the document.cookie API returns the entire cookie jar, regardless of whether
the caller script requires all cookies or not. However, to overwrite or delete
a specific cookie value, a third-party script needs to know the corresponding
cookie key. One potential explanation for this behavior could be the use of
common names such as test or user_id as cookie names. But that is not always
the case and we observe cases where the name of a cookie which is cannot be
randomly guessed is over-written by a cross-domain script. For instance, the
cto_bundle cookie initially created by Pubmatic is over-written by a script
associated with Criteo. Although this cookie originally belongs to Critieo
[46], in this specific case, we observed that it was first created by
Pubmatic. It changes from a string in hash format with a length of 194
characters to an entirely different value in hash format with a length of 258
characters.

####  5.2.6 Prevalence of Cookie Over-writing and Deletion

The last two columns of Table II represent the extent of cookie manipulation.
We observe that first-party cookies are overwritten by third-party scripts on
31.9% of the top 10,000 websites. Also, on 2.3% of these websites, cookies are
deleted by a third-party script. If we consider all cookies across the 10,000
websites, 3.7% (3,965) of all cookies (107,278) are over-written, and 0.5%
(529) of them are deleted by cross-domain scripts.

Dominant players. Figure 4 presents the top script domains engaged in cross-
domain cookie overwriting (overwritor), and deleting (remover). pubmatic.com
is the top cookie overwrite; 1% (41 cookies) of all cookie overwriting is
conducted by this domain. civiccomputing.com is the top cookie remover; 6.8%
(36 cookies) of all cookies are deleted by this domain. civiccomputing.com
provides Cookie Control, a consent management tool that helps websites comply
with privacy laws such as GDPR, LGPD, and CCPA. It provides a mechanism for
websites to manage user consent for cookies. If a user does not consent with
setting specific cookies, such as advertising and tracking cookies, it will
remove such cookies. Our data shows that 36 cookies created by other scripts
such as google-analytics.com and hotjar.com have been removed from websites.

Figure 4: Top 10 cookie overwritors and removers, sorted based on the number
of manipulated cookies.

The second and third columns of Table IV present the top cookies (along with
their creators) that have been most frequently overwritten and deleted by
cross-domain scripts. cto_bundle (created by criteo.net), as the most
overwritten cookie, is overwritten by 30 cross-domain scripts across 0.58%
(58) of websites. The top overwritor of this cookie is a script provided by
pubmatic.com. _gid cookie (created by google-analytics.com) is deleted the
most by 11 cross-domain scripts across 0.13% (13) of websites. The top remover
of this cookie is a script provided by prensaiberica.es.

Over-writing | Deleting
---|---
(cookies name, cookie creator) | No. attackers | % sites | (cookies name, cookie creator) | No. attackers | % sites
(cto_bundle, criteo.net) | 30 | 0.58 | (_gid, google-analytics.com) | 11 | 0.13
(_ga, google-analytics.com) | 15 | 19.06 | (_ga, google-analytics.com) | 9 | 0.09
(_pbjs_userid_consent_data, pubmatic.com) | 15 | 0.21 | (_gcl_au, googletagmanager.com) | 9 | 0.09
(panoramaId_expiry, crwdcntrl.net) | 11 | 0.46 | (_fbp, facebook.net) | 8 | 0.12
(_cc_id, crwdcntrl.net) | 11 | 0.46 | (ln_or, licdn.com) | 7 | 0.08
(cto_bundle, pubmatic.com) | 10 | 0.18 | (_ga, googletagmanager.com) | 4 | 0.05
(panoramaId, crwdcntrl.net) | 9 | 0.21 | (_cookie_test, cxense.com) | 3 | 0.12
(cto_bidid, pubmatic.com) | 9 | 0.08 | (_gd_visitor, 6sc.co) | 3 | 0.03
(_ga, googletagmanager.com) | 8 | 9.18 | (_gd_session, 6sc.co) | 3 | 0.03
(_sp_v1_data, sp-prod.net) | 5 | 0.05 | (cX_P, cxense.com) | 3 | 0.04

TABLE IV: Top 10 cookie names and their creator script domains, which have
been subjected to overwriting, and deletion by cross-domain scripts across
10,000 websites. The table also provides the number of cross-domain scripts
(attackers) responsible for cookie manipulation and the percentage of websites
affected by such manipulation from each attacker.

##  6 CookieGuard Design & Implementation

Our findings described in Section 5 show that first-party cookies are
susceptible to cross-domain manipulation and exfiltration. To address this
issue, we propose CookieGuard, an browser extension that isolates first-party
cookies set by different third-party scripts.

###  6.1 Design

CookieGuard’s key idea is to apply a filter to the original cookie jar to
ensure that only those cookies originally set by the invoking script are
returned. This idea can be realized in two ways.

Shadow Cookie Jar Metadata. The first approach is to maintain a shadow cookie
jar where each cookie’s creator information is logged. Here CookieGuard would
be responsible for updating information in this shadow cookie jar, including
cookie expiration, removal of deleted cookies, and enforcing policies like
HTTPOnly. The main drawback is related to performance: without optimal cookie
management strategies, page load times and the overall system performance
could be negatively impacted.

Separate Dataset. The second approach is to have a duplicate dataset in our
extension’s storage to log cookie names and the domains of their creators
(both for scripts and HTTP responses). Since this strategy avoids direct
cookie management tasks, the performance is better than with the first
approach. More specifically, CookieGuard intercepts both the creation of
cookies (by scripts and through the HTTP set-cookie header) and the accessing
of cookies in the cookie jar (by scripts). Additionally, it captures the
domain of the script that sets a cookie, ensuring comprehensive monitoring and
control over cookie operations within the browser. In practice, CookieGuard
intervenes when a script in the main frame attempts to access the cookie jar
via document.cookie. It ensures that only cookies originally created by the
same domain as the invoking script are returned. This improves the security of
first-party cookie management given the fact that cookies cannot be
manipulated by arbitrary third-party scripts in the main frame anymore.

For CookieGuard, we chose to implement the second approach as it simplifies
cookie management and reduces the computational overhead associated with
direct cookie interactions.

On some websites, essential functionality like user session management,
preferences, or shopping carts are handled by third-party scripts embedded as
first party. Blocking cookies set by these scripts could disrupt website
functionality. To prevent such disruptions, in CookieGuard’s implementation,
we grant full access control to the website owner to get access to all first-
party cookies. Consequently, if a script from the same domain as the website
invokes document.cookie, it retrieves all first-party cookies from the cookie
jar, regardless of the domain that set them.

We use the ETLD+1 as the level of granularity for matching a cookie’s creator
with the calling script. Filtering cookie access based on the entire origin
can be unnecessarily restrictive and may not provide additional privacy
benefits over domain-level blocking. By focusing on the domain level (ETLD+1),
we implement a more robust strategy.

Figure 5: CookieGuard overview

Figure 5 presents the overview of CookieGuard. 1 A server from site.com sends
an HTTP response containing a set-cookie header to set “c0” cookie on
site.com. Since the URL of the HTTP response matches the website, it is
classified as first party. The domain of the URL in the original cookie jar
and creator domain of this cookie in CookieGuard’s database are both set to
site.com. 2 A first-party script from the same domain as the visiting website
calls the “set” function of document.cookie to set “c1” cookie. Similar to
“c0”, both the domain of the URL in the original cookie jar and the setter
domain of this cookie in CookieGuard’s database are set as site.com. 3 A
script from ad.com, embedded in the main frame of site.com and considered as
first party by the browser, calls the “set” function of document.cookie to set
“c2” cookie. While the domain of the cookie is set to site.com in the original
cookie jar, the creator of this cookie is set as the domain of the script,
i.e. ad.com in CookieGuard’s dataset. 4 When ad.com’s script calls the “get”
function of document.cookie, the browser returns all cookies deemed first
party, including “c0”, “c1”, and “c2”. However, CookieGuard matches the domain
of the called script with the creator’s domain in its dataset, filters out
“c0” and “c1” (since their setter domains differs), and only returns “c2”. 5 A
second first-party script with site.com domain calls the “get” function of
document.cookie. Under the full access policy we have implemented in Section
6, the original cookie jar returns all first-party cookies when accessed by
scripts originating from the same domain as the website. CookieGuard matches
the domain of the caller script and the creator domain in its dataset. Since
the script’s domain matches the visiting website, no filter is applied, and
all cookies, “c0”, “c1”, and “c2”, are returned.

In the following section we explain the components of CookieGuard, and we
detail its implementation.

###  6.2 Implementation of CookieGuard

We implement CookieGuard as a browser extension, as illustrated in Figure 6.
The extension has three main components:

  * •

contentScript.js: This script injects cookieGuard.js into the main frame of a
website and facilitates the communication between cookieGuard.js and
background.js. It relays messages to ensure synchronized operations across
these scripts.

  * •

cookieGuard.js: This script implements a wrapper around the document.cookie
object’s “get” and “set” functions, enabling the interception of cookie jar
interactions. When a cookie is set, cookieGuard.js captures essential details
including the cookie’s name and setter’s domain, then forwards this
information to background.js to update the extension’s database. The domain of
a calling script is determined by analyzing the stack trace to identify the
last caller’s URL. If the URL is empty—-typically indicating an inline
script—-it defaults to the URL of the visiting website. For “get” requests,
cookieGuard.js queries background.js via contentScript.js to fetch the most
current dataset. It then applies a filter to the cookies, aligning them with
the domain of the calling script, as recorded in the dataset. If the calling
script’s domain matches the website’s domain, all corresponding first-party
cookies are returned, consistent with the browser’s default behavior. If the
calling script originates from a different domain, cookieGuard.js only returns
cookies whose setter domain matches the script’s URL, ensuring domain-specific
data integrity.

  * •

background.js: This script monitors HTTP responses that contain Set-Cookie
headers, logging details of non-HTTPOnly and first-party cookies by name and
setter domain in the extension’s storage. It handles all updates to the
dataset initiated by ’set’ requests from both HTTP headers and cookieGuard.js.
Furthermore, when the ’get’ function is invoked in cookieGuard.js,
background.js receives a message through contentScript.js to provide a current
copy of the dataset for accurate cookie filtering and response.

Figure 6: CookieGuard’s components

##  7 CookieGuard Evaluation

We assess the efficacy of CookieGuard, our cookie protection tool, through a
multi-faceted evaluation framework, focusing on accuracy, website breakage,
and runtime performance.

###  7.1 Access Control

We assess the effectiveness of CookieGuard in preventing cross-domain actions
such as the retrieval, overwriting, deletion, and exfiltration of first-party
cookies. Figure 7 illustrates the comparison between the percentage of sites
engaging in these actions on first-party cookies with the CookieGuard
extension enabled versus a regular browser without the extension. Notably,
CookieGuard significantly reduces cross-domain actions on first-party cookies:
retrieval by 60.2%, overwriting by 82.2%, deleting by 86.2%, and exfiltration
by 83.2%. As we discussed in Section 6.1, to avoid web breakage that might
result from restricting access to the entire cookie jar for first-party
scripts, we allow website owners full control over access to all first-party
cookies. Therefore, the percentage of sites exhibiting cross-domain actions on
first-party cookies with CookieGuard enabled is not zero.

Figure 7: Evaluation of Cross-Domain Actions: Comparing Browser Behavior with
CookieGuard Extension versus Regular browser without Any Extensions

###  7.2 Website Breakage

We perform a manual assessment of CookieGuard to determine its impact on
website functionality when the CookieGuard extension is enabled. A random
sample of 100 websites from the Tranco top 10k list is selected and tested in
two separate settings: with and without the CookieGuard extension activated.
One of the authors examines all 100 websites. Two separate evaluators are
recruited to provide assessments of website breakage. Each of these evaluators
is responsible for assessing a unique set of 50 websites from our chosen
sample. At least two distinct evaluators review each website to ensure a
comprehensive evaluation.

We classify breakage into four categories: navigation (moving between pages),
SSO (initiating and maintaining login state), appearance (visual consistency),
and other functionality (such as chats, search, and shopping cart). Breakage
is labeled as either major or minor for each category: Minor breakage occurs
when it is difficult but not impossible to use the functionality. Major
breakage occurs when it is impossible to use the functionality on a web page.

The results are shown in Table V. While CookieGuard has no impact on
navigation and appearance (0% breakage), we observe 1–11% minor and major
breakage on SSO and other functionality. More specifically, on 11% of the
websites, we are not able to sign in using SSO, because the sign-in process is
managed by third parties. When the user logs into SSO provider’s system such
as Google account, the system authenticates the user and upon successful
authentication, the SSO provider sets a session cookie in the user’s browser.
This cookie is then used to remember the user’s authentication status. The SSO
that leads to web breakage stems from the dependency on third-party cookies
for session management and login process. On some websites, multiple third-
party scripts are in charge of session management. For example, on zoom.us two
scripts, i.e. microsoft.com and live.com are in charge of SSO. Since
CookieGuard eliminates all cross-domain manipulations, is such cases breakage
happens. An example of a minor breakage would be on cnn.com, where a user can
sign in but after refreshing the website, the session does not keep the user
signed in. In terms of functionality, on 3% of the websites, there is at least
one advertisement served by a third-party script, which is not shown due to
our extension; and in another 3% of the websites, CookieGuard leads to major
breakage in functionality. For example, on facebook.com, Facebook Messenger,
an instant messenger service owned by Facebook, is managed by cookies served
from fbcdn.net. Although fbcdn.net is a CDN belongs to Facebook, since their
domains are different, it is considered as third-party on facebook.com.
Therefore, its access to the cookie jar is limited by CookieGuard which leads
to not working properly. To resolve this issue with facebook.com and other
websites with similar problem, we implement a whitelist feature in CookieGuard
for all domains belonging to a company, by leveraging information from
DuckDuckGo’s entities list [47].

| Navigation | SSO | Appearance |  | Functionality
---
Minor | 0% | 1% | 0% | 3%
Major | 0% | 11% | 0% | 3%
TABLE V: Qualitative manual analysis for 100 websites using CookieGuard,
showing % of No , Minor, and Major breakages in navigation, SSO, appearance,
and functionality.

###  7.3 Runtime Performance

We evaluate the performance overhead across top 10,000 websites, both before
and after CookieGuard deployment, utilizing Selenium to extract standard page
performance metrics for each visit. These metrics include the timing of key
page load events. Specifically, we measure dom_content_loaded,
dom_interactive, and load_event_time using Selenium. dom_content_loaded time
indicates when the HTML document has been completely loaded and parsed,
without waiting for stylesheets, images, and subframes to finish loading.
dom_interactive time indicates the duration until the DOM is fully prepared
for user interaction. load_event_time indicates the total time to completely
load all resources, such as images and CSS, signifying the full usability of a
web page.

Table V summarizes the results. A standard benchmark [48] for user-perceived
web page performance measures the timeline of key events marking various
stages in the browser’s page load and rendering process. The management of
cookies by CookieGuard adds an average overhead of 304 milliseconds to website
performance. While this may impact website load times negligibly, it is a
reasonable trade-off for the significant improvements in security and privacy
controls that CookieGuard provides. By managing cookie access more strictly,
CookieGuard prevents unauthorized data access and enhances user trust.

Metrics |  | Normal
---
(Mean, Median)
| CookieGuard
---
(Mean, Median)
DOM Content Loaded | 1659 ms, 946 ms | 1896 ms, 1020 ms
DOM Interactive | 1464 ms, 842 ms | 1702 ms, 911 ms
Load Event | 3197 ms, 2008 ms | 3635 ms, 2136 ms
TABLE VI: Performance analysis for the CookieGuard replacement

##  8 Discussion

Automated data crawling. We used pagegraph to collect our data. However, some
websites employ anti-crawling techniques that can prevent automated browsers
from accessing their content. This limitation can reduce the amount of data
collected and may introduce bias in the dataset. Moreover, the automatically
crawled data may be different than that for a real user interacting with a
website. This is particularly an issue for websites that require user
authentication or have dormant scripts that do not execute during non-
interactive page visits. Although such limitations are unavoidable in large-
scale studies, gathering data from a vast number of websites can help mitigate
their potential impact.

Rate of successful crawling. Out of the 10,000 websites in our study,
PageGraph generates a graph for 72% of them. It is worth noting that while
PageGraph’s crawler demonstrates a robust success rate of nearly 90% for the
top 1,000 pages, this rate gradually decreases for websites further down the
list. On the other hand, investigating and comparing the Tranco list with the
now-deprecated Alexa list, previously available at https://www.alexa.com/,
reveal that Tranco does not accurately reflect the links that an average
consumer would visit. A few examples of non-consumer-facing domains include
gstatic.com, googletagmanager.com, and doubleclick.net, which either return a
404 error code or redirect to completely different URLs. To compensate for the
low crawling success rates from both PageGraph and the Tranco list, we
continue crawling websites until PageGraph has successfully generated 10,000
graphs.

Manipulation of script source. CookieGuard relies on the script source
attribute to distinguish between third-party scripts from different domains in
the main frame. However, these third-party scripts can attempt to manipulate
the script source to circumvent CookieGuard’s protection in the following
ways:

  * •

Embedded as inline scripts: rather than including scripts using script tags,
the source of a third-party script can be embedded as inline script. Inline
scripts are automatically considered as first-party scripts.

  * •

Hosted as a first-party script: web developers may decide to host the script
code on the same domain as the website (or a subdomain of the website).

  * •

CNAME cloaking: CNAME cloaking [49, 50] is a technique that creates a first-
party subdomain and assigns a DNS CNAME record pointing to the third-party
domain of the script.

To mitigate this, instead of evaluating the URLs of scripts, we could assess
their execution behavior. Chen et al. [51] propose a signature-based mechanism
that creates behavior signatures for scripts. A practical method would involve
conducting a large-scale web crawl to generate signatures for various third-
party scripts. If CookieGuard detects that a first-party script’s signature
matches that of a third-party script, it can then treat it as a third-party
script. A key challenge that warrants further attention is JavaScript
obfuscation [52]. For this signature-based approach to work, the signatures
should be resistant to minor changes in a script’s code.

Beyond cookies: Cross-domain manipulation of other shared resources. As we
discussed in Section 3, scripts included in the main frame have access to a
variety of shared resources beyond cookies such as the HTML DOM. We conducted
a pilot analysis to investigate the existence and prevalence of cross-domain
DOM modification. We observed that a number of cross-domain scripts run with
full privileges modify, insert, or remove DOM elements that do not belong to
them on 9.4% of sites. Modification can be applied to the content of HTML
elements, e.g., innerText or innerHTML, the style (CSS) of the HTML element,
and the attributes and classes of the HTML element, e.g., src. We leave a more
thorough investigation of this issue for future work. Moreover, we aim to
develop a defense mechanism to mitigate this practice.

##  9 Related Work

Third-party scripts. Prior research has studied the widespread inclusion of
third-party scripts on websites and security risks associated with their use
[36, 53, 54]. Lauinger et al. [53] have investigated over 133K websites
finding that 37% of them include at least one script with a known
vulnerability. Musch et al. [54] modify the JavaScript environment in a such a
way that the accidental introduction of a Client-Side XSS vulnerability
through a third party is prevented. Nikiforakis et al. [36] analyze the
extensive presence of third-party scripts across over 3 million pages from the
top 10,000 Alexa sites, reporting that 88.5% of popular sites incorporate at
least one third-party script, not necessarily in the main frame. The study
also tracks the increasing reliance on third-party scripts over time. In
contrast, our research, unlike others that focus on security, explores the
privacy implications of third-party scripts in the main frame. Additionally,
our study specifically targets the inclusion of third-party scripts in the
main frame, finding that 93.3% of websites include at least one such script
directly in their main frame. Our analysis categorizes these scripts by their
method of inclusion, revealing that only 10% are directly included, while a
significant 90% are included indirectly across 10,000 websites. This suggests
that the rise in third-party script inclusion may not directly correlate with
increased trust by websites.

First-party cookies ghost-written by third-party scripts. Another line of
prior work has studied cookie creating and exfiltration by third-party
scripts. Sanchez et al. [7] analyzed cookie (both script and HTTP cookies)
exfiltration, overwriting, and deleting across 1 million websites. They
collected 66.7 million cookies from 74% (738,168) of the websites visited.
Their findings reveal that 11% of these cookies are first-party, 47% are
third-party, and 42% are ghost-written. They also find that 13.4% of all
cookies are exfiltrated, 0.19% are overwritten, and 0.08% are deleted by
scripts or Set-Cookie headers in responses. Additionally, they report that
cross-domain cookie exfiltration and collision (including overwriting and
deleting) occur on 28.3% and 0.7% of the visited websites, respectively. Our
work focuses exclusively on first-party scripts (created by both first-party
and third-party scripts on the main frame) due to their critical role in
storing users’ sensitive information and session cookies. Consequently, we
only consider cross-domain actions, including exfiltration and manipulation,
by scripts on the main frame. We do not investigate actions caused by Set-
Cookie headers in responses, as responses sent from third-party servers cannot
access or manipulate first-party cookies. Since the publication of this paper,
i.e. 2021, we have noted a significant shift of third-party scripts into the
main frame. Notably, 92% of all first-party cookies in our dataset are ghost-
written cookies. This shift has had significant consequences. The incidence of
cross-domain cookie exfiltration, overwriting, and deletion has increased by
factors of 1.3, 19.5, and 6.2, respectively. Additionally, the number of
websites engaging in cross-domain cookie exfiltration, overwriting, and
deleting has risen by 1.5 and 45.7 times, respectively. It is important to
note that these figures represent a conservative estimate, as our study
focuses only on first-party and ghost-written cookies manipulated or
exfiltrated by scripts in the main frame, excluding other scripts and HTTP
responses. Chen et al. [6] investigated ghost-written first-party cookies set
by third-party tracking scripts. Their findings indicate that 97% of the Alexa
top 10K websites host at least one ghost-written cookie, with exfiltration
occurring on 57.7% of these sites by both same-domain and cross-domain
scripts. However, their study does not address other impacts of third-party
scripts in the main frame, such as cookie manipulation. Moreover, neither the
studies by [7] nor [6] offer an intervention mechanism to protect first-party
cookies from cross-domain exfiltration and manipulation. There are extensive
number of tools and extensions allowing users to automatically delete cookies
from specified domains [55, 56, 57]. Moreover, Munir et al.[5] proposed a
machine learning-based intervention mechanism to automatically block ghost-
written first-party tracking cookies. However, none of these studies address
the more fundamental problem of first-party cookie isolation, i.e., whether
first-party cookies can be accessed or modified by different third-party
scripts.

Shared global namespace. Another line of prior work has studied JavaScript
conflicts in the shared global namespace. Ocariza et al. [58] and Zhang et al.
[59] investigated how JavaScript global identifier conflicts might lead to
cookie overwriting. Several studies focused on JavaScript issues,
predominantly focusing on bad coding practices [60, 58, 61, 62, 63, 59, 64].
The primary objective of these studies is to identify conflicts shared global
namespace, especially when they result in functional web issues, as opposed to
focusing solely on shared cookie jar on the main frame.

Takeaway. Our work is distinct from prior work in two main ways. First, our
study focuses on first-party cookie manipulation/exfiltration by third-party
scripts in the main frame. Second, we propose an intervention tool called
CookieGuard to isolate cookies from manipulation/exfiltration by cross-domain
scripts.

##  10 Conclusion

We presented CookieGuard, a novel browser-based intervention to isolate first-
party cookies. CookieGuard advances the state-of-the-art in two major ways.
First, different from prior work on third-party JavaScript and cookie
measurements, we specifically focus on third-party scripts included – either
directly or indirectly – in the main frame such that they can
manipulate/exfiltrate cookies in the shared first-party cookie jar. Second,
different from prior work on blocking or partitioning third-party and/or
first-party cookies, CookieGuard is the first-of-its-kind first-party cookie
partitioning system. CookieGuard complements interventions that are being
introduced in web browsers to improve the security and privacy of cookies.
Going forward, the underlying problem addressed by CookieGuard goes well
beyond cookies. Third-party scripts included in the main frame have access to
all first-party shared resources (e.g., HTML DOM, global namespace), not just
the cookie jar. Future work can investigate interventions, similar to
CookieGuard for the cookie jar, to introduce isolation in other shared
resources.

## References

  * [1] “Firefox rolls out Total Cookie Protection by default to all users worldwide,” https://blog.mozilla.org/en/products/firefox/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/.
  * [2] “Introducing tracking prevention, now available in Microsoft Edge preview builds,” https://blogs.windows.com/msedgedev/2019/06/27/tracking-prevention-microsoft-edge-preview/.
  * [3] “Full Third-Party Cookie Blocking and More,” https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more.
  * [4] “Update on the plan for phase-out of third-party cookies on Chrome,” https://privacysandbox.com/news/update-on-the-plan-for-phase-out-of-third-party-cookies-on-chrome/.
  * [5] S. Munir, S. Siby, U. Iqbal, S. Englehardt, Z. Shafiq, and C. Troncoso, “Cookiegraph: Measuring and countering first-party tracking cookies,” _arXiv preprint arXiv:2208.12370_ , 2022.
  * [6] Q. Chen, P. Ilia, M. Polychronakis, and A. Kapravelos, “Cookie swap party: Abusing first-party cookies for web tracking,” in _Proceedings of the Web Conference 2021_ , 2021, pp. 2117–2129.
  * [7] I. Sanchez-Rola, M. Dell’Amico, D. Balzarotti, P.-A. Vervier, and L. Bilge, “Journey to the center of the cookie ecosystem: Unraveling actors’ roles and relationships,” in _2021 IEEE Symposium on Security and Privacy (SP)_. IEEE, 2021, pp. 1990–2004.
  * [8] “Same-origin policy,” https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy.
  * [9] “Content security policy (csp),” https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP.
  * [10] “Meta Pixel,” https://developers.facebook.com/docs/meta-pixel/get-started/.
  * [11] “About TikTok Pixel,” https://ads.tiktok.com/help/article/using-cookies-with-tiktok-pixel.
  * [12] J. Ruohonen, J. Salovaara, and V. Leppänen, “On the integrity of cross-origin javascripts,” in _ICT Systems Security and Privacy Protection: 33rd IFIP TC 11 International Conference, SEC 2018, Held at the 24th IFIP World Computer Congress, WCC 2018, Poznan, Poland, September 18-20, 2018, Proceedings 33_. Springer, 2018, pp. 385–398.
  * [13] A. Aliyeva and M. Egele, “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_ , 2021, pp. 123–134.
  * [14] “Brave software, pagegraph,” https://github.com/brave/brave-browser/wiki/PageGraph, 2020.
  * [15] S. S. Ahmad, M. D. Dar, M. F. Zaffar, N. Vallina-Rodriguez, and R. Nithyanand, “Apophanies or epiphanies? how crawlers impact our understanding of the web,” in _Proceedings of The Web Conference 2020_ , 2020, pp. 271–280.
  * [16] “Curl - command line tool,” https://curl.haxx.se, 2019.
  * [17] “Wget - command line tool,” https://www.gnu.org/software/wget, 2019.
  * [18] “Owasp zap spider,” https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Projec, 2018.
  * [19] “Phantomjs- headless web browser,” http://phantomjs.org, 2018.
  * [20] “Selenium - web browser automation,” http://www.seleniumhq.org, 2018.
  * [21] “Google chrome puppeteer,” https://github.com/GoogleChrome/puppeteer.
  * [22] “openwpm,” https://github.com/openwpm/OpenWPM.
  * [23] U. Iqbal, P. Snyder, S. Zhu, B. Livshits, Z. Qian, and Z. Shafiq, “Adgraph: A graph-based approach to ad and tracker blocking,” in _2020 IEEE Symposium on Security and Privacy (SP)_. IEEE, 2020, pp. 763–776.
  * [24] S. Siby, U. Iqbal, S. Englehardt, Z. Shafiq, and C. Troncoso, “$\\{$WebGraph$\\}$: Capturing advertising and tracking information flows for robust blocking,” in _31st USENIX Security Symposium (USENIX Security 22)_ , 2022, pp. 2875–2892.
  * [25] V. Le Pochat, T. Van Goethem, S. Tajalizadehkhoob, M. Korczyński, and W. Joosen, “Tranco: A research-oriented top sites ranking hardened against manipulation,” in _Proceedings of the 26th Annual Network and Distributed System Security Symposium_ , ser. NDSS 2019, Feb. 2019.
  * [26] “adblockparser,” https://github.com/scrapinghub/adblockparser.
  * [27] “Easylist.” https://easylist.to/easylist/easylist.txt.
  * [28] “Easyprivacy,” https://easylist.to/easylist/easylist.txt.
  * [29] “Fanboy social list.” https://easylist.to/easylist/fanboy-social.txt.
  * [30] “Fanboy annoyances list.” https://easylist.to/easylist/fanboy-annoyance.txt.
  * [31] “Anti-adblock killer.” https://raw.github.com/reek/anti-adblock-killer/master/anti-adblock-killer-filters.txt.
  * [32] “Peter lowe’s list.” http://pgl.yoyo.org/adservers.
  * [33] “Warning removal list.” https://easylist-downloads.adblockplus.org/antiadblockfilters.txt.
  * [34] “Squid blacklist.” http://www.squidblacklist.org/downloads/sbl-adblock.acl.
  * [35] “Blockzilla.” https://raw.githubusercontent.com/annon79/Blockzilla/master/Blockzilla.txt.
  * [36] N. Nikiforakis, L. Invernizzi, A. Kapravelos, S. Van Acker, W. Joosen, C. Kruegel, F. Piessens, and G. Vigna, “You are what you include: large-scale evaluation of remote javascript inclusions,” in _Proceedings of the 2012 ACM conference on Computer and communications security_ , 2012, pp. 736–747.
  * [37] M. Ikram, R. Masood, G. Tyson, M. A. Kaafar, N. Loizon, and R. Ensafi, “The chain of implicit trust: An analysis of the web third-party resources loading,” in _The World Wide Web Conference_ , 2019, pp. 2851–2857.
  * [38] ——, “Measuring and analysing the chain of implicit trust: A study of third-party resources loading,” _ACM Transactions on Privacy and Security (TOPS)_ , vol. 23, no. 2, pp. 1–27, 2020.
  * [39] M. Tahaei and K. Vaniea, “Code-level dark patterns: Exploring ad networks’ misleading code samples with negative consequences for users,” _What Can CHI Do About Dark Patterns_ , pp. 1–5, 2021.
  * [40] ——, ““developers are responsible”: What ad networks tell developers about privacy,” in _Extended Abstracts of the 2021 CHI Conference on Human Factors in Computing Systems_ , 2021, pp. 1–11.
  * [41] P. Papadopoulos, N. Kourtellis, and E. Markatos, “Cookie synchronization: Everything you always wanted to know but were afraid to ask,” in _The World Wide Web Conference_ , 2019, pp. 1432–1442.
  * [42] S. Englehardt and A. Narayanan, “Online tracking: A 1-million-site measurement and analysis,” in _Proceedings of the 2016 ACM SIGSAC conference on computer and communications security_ , 2016, pp. 1388–1401.
  * [43] L. Olejnik and C. Castelluccia, “To bid or not to bid? measuring the value of privacy in rtb,” _accessed on_ , pp. 05–21, 2016.
  * [44] M. Pachilakis, P. Papadopoulos, E. P. Markatos, and N. Kourtellis, “No more chasing waterfalls: a measurement study of the header bidding ad-ecosystem,” in _Proceedings of the Internet Measurement Conference_ , 2019, pp. 280–293.
  * [45] “Google analytics cookie usage on websites,” https://web.archive.org/web/20230308001207/https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage.
  * [46] “cto_bundle,” https://cookiedatabase.org/cookie/criteo/cto_bundle/.
  * [47] “DuckDuckGo Tracker Radar list of entities,” https://github.com/duckduckgo/tracker-radar/tree/main/entities, 2022.
  * [48] M. Smith, P. Snyder, B. Livshits, and D. Stefan, “Sugarcoat: Programmatically generating privacy-preserving, web-compatible resource replacements for content blocking,” in _Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security_ , 2021, pp. 2844–2857.
  * [49] S.-C. Lin, K.-H. Chou, Y. Chen, H.-C. Hsiao, D. Cassel, L. Bauer, and L. Jia, “Investigating advertisers’ domain-changing behaviors and their impacts on ad-blocker filter lists,” in _Proceedings of the ACM Web Conference 2022_ , 2022, pp. 576–587.
  * [50] P. Snyder, A. Vastel, and B. Livshits, “Who filters the filters: Understanding the growth, usefulness and efficiency of crowdsourced ad blocking,” _Proceedings of the ACM on Measurement and Analysis of Computing Systems_ , vol. 4, no. 2, pp. 1–24, 2020.
  * [51] Q. Chen, P. Snyder, B. Livshits, and A. Kapravelos, “Detecting filter list evasion with event-loop-turn granularity javascript signatures,” in _2021 IEEE Symposium on Security and Privacy (SP)_. IEEE, 2021, pp. 1715–1729.
  * [52] M. Moog, M. Demmel, M. Backes, and A. Fass, “Statically Detecting JavaScript Obfuscation and Minification Techniques in the Wild,” in _Dependable Systems and Networks (DSN)_ , 2021.
  * [53] T. Lauinger, A. Chaabane, S. Arshad, W. Robertson, C. Wilson, and E. Kirda, “Thou shalt not depend on me: Analysing the use of outdated javascript libraries on the web,” _arXiv preprint arXiv:1811.00918_ , 2018.
  * [54] M. Musch, M. Steffens, S. Roth, B. Stock, and M. Johns, “Scriptprotect: mitigating unsafe third-party javascript practices,” in _Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security_ , 2019, pp. 391–402.
  * [55] “Cookie AutoDelete,” https://chromewebstore.google.com/detail/cookie-autodelete/fhcgjolkccmbidfldomjliifgaodjagh.
  * [56] “Quick Cookie Manager,” https://addons.mozilla.org/en-US/firefox/addon/cookie-quick-manager/.
  * [57] “uMatrix,” https://chromewebstore.google.com/detail/umatrix/ogfcmafjalglgifnmanfmnieipoejdcf.
  * [58] F. S. Ocariza, K. Bajaj, K. Pattabiraman, and A. Mesbah, “A study of causes and consequences of client-side javascript bugs,” _IEEE Transactions on Software Engineering_ , vol. 43, no. 2, pp. 128–144, 2016.
  * [59] M. Zhang and W. Meng, “Detecting and understanding javascript global identifier conflicts on the web,” in _Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering_ , 2020, pp. 38–49.
  * [60] F. S. Ocariza Jr, K. Pattabiraman, and A. Mesbah, “Autoflox: An automatic fault localizer for client-side javascript,” in _2012 IEEE Fifth International Conference on Software Testing, Verification and Validation_. IEEE, 2012, pp. 31–40.
  * [61] B. Hackett and S.-y. Guo, “Fast and precise hybrid type inference for javascript,” _ACM SIGPLAN Notices_ , vol. 47, no. 6, pp. 239–250, 2012.
  * [62] S. H. Jensen, A. Møller, and P. Thiemann, “Type analysis for javascript,” in _Static Analysis: 16th International Symposium, SAS 2009, Los Angeles, CA, USA, August 9-11, 2009. Proceedings 16_. Springer, 2009, pp. 238–255.
  * [63] M. Pradel, P. Schuh, and K. Sen, “Typedevil: Dynamic type inconsistency analysis for javascript. in 2015 ieee/acm 37th ieee international conference on software engineering, vol. 1,” _IEEE, 314ś324_ , 2015.
  * [64] J. Patra, P. N. Dixit, and M. Pradel, “Conflictjs: finding and understanding conflicts between javascript libraries,” in _Proceedings of the 40th International Conference on Software Engineering_ , 2018, pp. 741–751.

##  11 Appendix

###  11.1 PageGraph architecture

Category Node Type Edge Type HTML/DOM \- HTML element \- text change \- text
node \- [remove/delete/insert/create] node \- DOM root \- frame owner parser
JavaScript \- script \- js result \- Web API \- js call \- JS builtin Storage
\- local storage \- storage set \- session storage \- storage read result \-
cookie jar \- [delete/clear] storage Network \- resource \- request
[complete/error/ start/response] Other \- Remote frame \- execute \-
Set/Delete attribute \- [add/remove] event listener

TABLE VII: Type of nodes and edges captured in PageGraph

We have organized node and edge types into five categories, as shown in Table
VII: HTML/DOM, JavaScript, Storage, Network, and Other. Figure 8 illustrates a
sub-graph excerpt from the crawling result of PageGraph on https://cnn.com.

Figure 8: PageGraph representation of entities within a web page embedded in a
graph.

The image and script URLs are changed to fit in the graph. As represented in
the Figure, 1) the browser’s HTML parser encounters a <script> in the website
while loading the page and inserts a DOM node to embed the script tag in the
graph. 2,3) An HTTP request is sent to fetch the script source code pointed to
in the src attribute of the DOM script tag. 4) The result is encoded as a
script node in the graph. 5) The script node inserts a DOM node to represent a
decoded img tag. 6,7) An HTTP request is sent to fetch the image file from the
address included in the src attribute of the ¡img¿ tag.

###  11.2 PageGraph+ command line tool

PageGraph+ is a command-based tool, which we implemented in Rust and built on
top of PageGraph. More precisely, it takes PageGraph generated graphs in the
graphml format as input, analyzes page behavior, and generates an output in
JSON format.

PageGraph+ comprises two distinct command groups: script-based commands and
general commands. The focus of script-based commands are on investigating
different execution behavior of script nodes while general commands focuses on
any other node types. For script-based commands, the template syntax is as
follows:

⬇

$ \--file <graphml> SCRIPT \--QueryName \--output <output_path>

In this syntax, the \--file argument gets the recording of a page execution
captured by PageGraph in graphml format. The \--QueryName argument specifies
the query to be executed on the input graph. A list of available queries on
script nodes is provided in Table VIII. The \--output argument denotes the
path where the resulting output will be stored.

Query |
---|---
Category |  Syntax
Network Requests |  ‘$ –file <graph.ml> scripts –query-requests Description: This query analyzes the input GraphML file to determine the type of network requests made by scripts and the number of requests initiated from each script.
Storage Access |  ’$ –file <graph.ml> scripts –query-storage action Description: This query identifies all scripts that access storage (including cookie jar, local storage, and session storage) and perform actions based on <action>, which can be “set”, “read”, or “delete”.
Injected Scripts |  ’$ –file <graph.ml> scripts –query-injected-scripts Description: This query retrieves all the injected scripts within the GraphML data, providing insights into script injections.
Chain of Scripts |  ’$ –file <graph.ml> scripts –query-subsequent-scripts Description: This query extends the Injected Scripts query to analyze script chains by running the specified depth of script calls on each script node. It helps identify sequences of script calls and their implications.

TABLE VIII: List of CookieGuard’s script queries

For general commands, the template syntax is as follows:

⬇

$ \--file <graphml> GENERAL \--type <node_type> \--output <output_path>

In this syntax, the \--file and \--output arguments retain their roles from
script-based commands. The \--type argument indicates the type of the node we
intend to analyze. The complete list of node types is provided in Table VII.