arXiv CSopen access

From Third-Party to First-Party: Measuring and Protecting Against Modern Web Tracking Mechanisms

arXiv:2606.16720v1 [cs.CR] 15 Jun 2026

From Third-Party to First-Party: Measuring and Protecting Against Modern Web Tracking Mechanisms Christian Böttger

Tareq Khouja

Norbert Pohlmann

[email protected] Institute for Internet Security Westphalian University of Applied Science Doctoral School NRW Department of Computer and Data Science

[email protected] Institute for Internet Security Westphalian University of Applied Science

[email protected] Institute for Internet Security Westphalian University of Applied Science

Nurullah Demir

Tobias Urban

[email protected] Stanford University

[email protected] Institute for Internet Security Westphalian University of Applied Science

Abstract Web user tracking has always been a cat-and-mouse game between privacy-conscious users and trackers. Recently, this conflict has driven a shift from third-party tracking toward first-party tracking (FPT) and server-side tracking (SST). By relocating tracking logic to the browser’s first-party context or the website’s backend, these mechanisms obscure data flows and render traditional client-side detection tools increasingly ineffective. Despite the growing adoption of these techniques, our understanding of their deployment at scale remains limited, and generalized protection mechanisms are lacking. In this work, we conduct a large-scale measurement of top sites to assess this shift and the prevalence of FPT and SST. We develop a provider-independent methodology to detect these mechanisms and find that over 54% of analyzed sites now deploy FPT or SSTrelated techniques. By clustering scripts based on their similarity and constructing a network graph, we demonstrate that the ecosystem is densely connected and dominated by major vendors like Google. Finally, we demonstrate that current filter lists are largely ineffective against first-party tracking, and we propose new rules to address this gap. We show that these rules block 63% more requests than traditional filter lists.

1

Introduction

On the modern Web, targeted advertising (ads) is the primary revenue model for websites [65], and behavioral analytics are important for optimizing websites [44], both of which rely on user tracking. Consequently, providers employ pervasive tracking techniques to collect extensive user data. These practices are often viewed as privacy-invasive, as they often occur without proper consent [58, 80] and offer limited transparency mechanisms to meaningfully inform users [49, 66, 77]. Traditionally, third-party cookies have served as the predominant mechanism for this data collection [2, 26, 34, 79]. A recent direction is that trackers implement tracking methods that do not rely on third-party cookies [81] by moving the tracking mechanisms into the website’s backend or

into the first-party context. This technique is called first-party tracking (FPT) [17] or server-side tracking (SST) [3, 24, 30]. In contrast to traditional client-side tracking, FPT moves data collection and transmission from the user’s browser to the website’s backend or the first-party context of a page [57]. In both cases, website providers host tracking mechanisms in a first-party context or use third-party resources that can access the first-party context, enabling them to evade privacy-enhancing tools and making URL-based detection challenging. Furthermore, this relocation obscures the data flow, as users cannot easily identify third-party tracking-related requests or the entities involved [32]. While prior studies have offered insights into specific implementations, such as Meta or Google Tag Manager [3, 24], or addressed particular legal [32] and technical challenges [57], the broader ecosystem remains less explored. To bridge this gap, we develop a generic methodology to identify FPT and SST and conduct largescale measurements across 13k sites and 750k pages to assess their adoption. We assess which parties are involved in this new tracking ecosystem and test if similar tracking code is in first- and thirdparty tracking methods. Furthermore, since blocking FPT requests is challenging, we developed a statistical method to generate blocking rules compatible with ad blockers, thereby protecting users from FPT and SST. We find that over 54% of analyzed sites have adopted FPT or SST. By clustering the JavaScript involved in these techniques, we identify an ecosystem operated by 492 distinct entities, yet highly centralized around a few major vendors (e.g., Google). Notably, we find that a significant number of third-party trackers have begun operating in first-party contexts, accounting for over 8% of the analyzed tracking requests. To address the limited efficiency of block lists, we derive 181 FPT-blocking rules using a statistical approach, showing that they block 63% more first-party tracking requests than existing lists with a minor impact on page breakage. In summary, we make the following contributions: • Prevalence of FPT and SST. We show that, with 13,187 sites using cookies potentially linked to FPT or SST, these technologies are an emerging and prevalent privacy threat on the Web. Further,

Christian Böttger, Tareq Khouja, Norbert Pohlmann, Nurullah Demir, and Tobias Urban

we show that trackers have begun migrating their activities into the first-party context, as we find similar scripts in both contexts. • First-party tracking ecosystem analysis. By clustering tracking scripts into 492 entities, we reveal a centralized ecosystem dominated by major vendors (e.g., Google), demonstrating that first-party tracking largely relies on existing third-party infrastructure. • First-party-tracking protection mechanisms. We design and evaluate a URL-based detection and mitigation pipeline that utilizes FPT-specific query-parameter patterns and translates them into blocking rules. We show that the generated rules block notably more FPT-related requests (63%) than common blocklists without causing considerable page breakage.

2

Terminology

The term site refers to the registrable portion of a domain, commonly known as the “effective Top-Level Domain plus one” (eTLD+1) [7, 9, 18, 55, 78]. For example, in https://www.example.edu/, the eTLD+1 is example.edu. In contrast to a site, a page (or webpage) is a specific URL and the document accessible at that address. Thus, a site can have multiple pages that contain the site’s content. Cookies are small key–value pairs stored by the browser to persist state across requests [4, 78]. We refer to cookies by their setting context (e.g., first-party cookies). Notably, third-party scripts can set first-party cookies as long as they originate from the visited domain [4].

2.2

Frontend

Backend

3 stores data

3 tracks 2 emebds

2 collects data

visits 1

4

send data

1 visits User

Website

(a) Client-side tracking.

User

tracker.org

(b) Server-side tracking.

Figure 1: Comparison of client-side and server-side tracking.

Background

Here, we introduce the terminology used in this work and describe the basis of first-party and server-side tracking.

2.1

Website

tracker.org

Server-Side and First-Party Tracking

Server-Side Tracking (SST) and First-Party Tracking (FPT) shift tracking activities from third parties to the website’s backend or the user’s first-party context, introducing distinct challenges for transparency and detection. As more and more defense techniques against client-side tracking are employed, providers of tracking technology need to adapt their data-collection practices. Consequently, major tracking providers such as Google, TikTok, or Meta have introduced a technique referred to as server-side tracking [35, 42, 43]. SST moves essential parts used for tracking into the backend of the visited site (i.e., the first party). The server collects or aggregates the data of interest and, after preprocessing, forwards it to the tracker [31, 47]. Thus, a key difference from client-side tracking is that this type of tracking can occur without the client being aware of any communication with a third party. Figure 1 shows a high-level comparison between both techniques. While the name “server-side” tracking implies that tracking only happens on the server, current mechanisms rely on storing an identifier on the client in the form of first-party cookies [57]. The client-side component of an SST deployment is minimal, a persistent identifier is stored in a first-party cookie, which the first-party server reads on each visit and transmits to the tracker as part of its backend processing [21, 24, 30, 75]. From the browser’s perspective, this tracking can happen without any request to a tracker domain. This architectural property is one reason SST is harder to detect and

protect against: the first-party domain varies by definition across sites and cannot be part of a static block list [32]. Further, first-party tracking (FPT) refers to a tracking model in which the user identifier is stored in the first-party context (e.g., in a first-party cookie). Because the identifier is set and accessed in a first-party context, it is not subject to many browsers’ defenses that restrict third-party cookies. This can be achieved by embedding tracking logic directly into the website’s first-party JavaScript code, by proxying third-party scripts through a first-party subdomain via DNS reconfiguration [14], or by configuring a tag management system such as Google Tag Manager to deliver tracking code within the first-party context [3]. Because the browser classifies these resources as first-party, neither third-party cookie restrictions nor domain-based blocking rules apply. The tracking identifier is stored as a first-party cookie via the “document.cookie” API [4] and persists across browsing sessions. Hence, first-party tracking enables cross-site or long-term user tracking while bypassing privacy mechanisms designed to limit traditional client-side tracking (e.g., third-party tracking) [17]. While SST and FPT operate differently, both rely on first-party cookies as persistent user identifiers. We focus on detecting and analyzing these cookies, and henceforth use FPT to refer to both mechanisms.

3

FPT Measurement Framework

In this section, we detail our data collection, measurement, preprocessing, and analysis. Artifacts of our work are provided in a code repository (see Section A).

3.1

Data Collection

The scope of this study is to assess client-side indicators FPT. We do not aim to capture communication between servers and, therefore, cannot draw any conclusions about what is happening on the server side. Yet, we argue that if we find client-side first-party indications for user tracking, it is processed by a server for that purpose (e.g., we assume that if on the client side FPT-related tracking code is executed, then on the server side a corresponding component exists). To understand the FPT tracking ecosystem and develop appropriate countermeasures, we need to collect a representative sample of FPT-related first-party cookies (see Section 2.2), the parties that set them, and the websites that use such tracking techniques. To

From Third-Party to First-Party: Measuring and Protecting Against Modern Web Tracking Mechanisms

collect this data, we use the MultiCrawl Web measurement framework [20], which is based on OpenWPM [25]. During a measurement run, we instrument the framework to record HTTP requests and responses (including headers), cookies set via HTTP headers, JavaScript interaction with cookies (e.g., we instrumented the content_script_instrument and save_content function), and download all JavaScript resources (files). OpenWPM uses the Firefox browser, which we configure to prevent third-party cookies from being set or sent in third-party contexts. Thus, websites might resort to first-party tracking, as third-party cookie-based tracking is not possible. Further, to minimize detection by anti-bot mechanisms, we applied best practices to hide that OpenWPM is in use [50]. To increase the number of cookies in our dataset, we interact with the consent banners on webpages. We use the browser extension Consent-O-Matic [41] and modify it to accept all cookies. We choose Consent-O-Matic because it is a major extension for this use and has been validated as effective in previous work [19, 61]. For our measurement, we use the Tranco1 list [51] generated on April 2nd, 2025. We use the top 5k sites from the list and randomly select 5k sites from each of the following buckets: 5,001-10k, 10,001-50k, 50,001-250k, 250,001-500k [16], resulting in a total of 25k sites. For each of the 25k sites, we visit 25 pages [78]. Overall, we run four measurements simultaneously on different virtual machines (VMs) from two locations (i.e., Germany and the United States). Our framework follows best practices for large-scale Web measurements [15, 16] (e.g., multiple crawls and multiple locations) to capture a realistic, representative dataset on the prevalence of server-side tracking in the field. We chose to run the experiments in the U.S. because sites typically use more cookies when users visit them from the U.S. rather than from the EU [19]. We performed two measurements from each location to increase the validity of the results and to robustly identify first-party tracking cookies. All of the VMs are located in Germany. We connected all machines via a VPN to two different locations: two are connected to VPN gateways in the U.S., and two machines are connected to VPN gateways in Germany. We use NordVPN [60] as a VPN provider.VPN providers may impact measurements (e.g., by inserting ads) [46]. However, we found no evidence of this for NordVPN. We deactivated NordVPN’s integrated AdBlock mechanism. Sites detecting VPN use would affect all measurement profiles equally.

3.2

Data Preprocessing

Identifying Tracking Cookies. In this work, we want to assess the impact of first-party tracking on the tracking ecosystem. Thus, we need to determine whether first-party cookies are used for tracking [57]. One significant challenge in this task is that firstparty cookies are often used to identify sessions and maintain state within the otherwise stateless HTTP protocol. Such session identifiers are similar to tracking IDs, as they serve a comparable purpose: identifying the same user across page visits and HTTP requests. Session IDs typically expire when a browser is closed, whereas user identifiers are designed to persist across multiple sessions. To select an appropriate identification method, we assess three prior approaches. The first is a community-driven approach that 1 https://tranco-list.eu/list/QG4V4/1000000

uses classifications from Cookiepedia [63], which curates a mapping of cookie names to their potential purposes. To assess its suitability, we applied the Cookiepedia database to our collected first-party cookies. Cookiepedia classified only 3,914 (0.09%) of the 477,231 first-party cookies as tracking cookies, confirming the limited coverage of community-driven databases for this emerging phenomenon. In contrast, our heuristic (described below) identified 0.14% of cookies as tracking-related and discovered 16,881 (51%) additional cookies that Cookiepedia could not classify. The heuristic missed only 1 cookie that Cookiepedia flagged as a tracking cookie. This cookie was not detected because it has a lifetime of only 30 minutes, placing it outside our longevity criterion. This confirms Cookiepedia’s unsuitability for this context. The second approach is to leverage the ML-based (tracking) cookie classifier proposed by CookieGraph [57], which uses a supervised classifier trained on labeled cookie data. While methodologically more principled, CookieGraph presents a critical reproducibility limitation. However, the published artifact [56] does not include a trained model, and the training data is no longer publicly available. We contacted the authors, who confirmed that the system cannot be reproduced in its original form. As a third option, we evaluated a rule-based heuristic used in prior web-tracking literature to identify third-party tracking cookies [2, 25, 48, 78]. We adopt these definitions to enable a basic comparison between our work and previous studies that focused on third-party tracking. This is justified because popular third-party cookies have migrated into the first-party context (e.g., Google Tag Manager [36]) and, thus, the heuristic might be a valid choice. The criteria are: (1) Longevity: The cookie is not a session cookie and has a lifetime exceeding 90 days. (2) Length: It contains at least eight bytes to ensure sufficient entropy to hold a user ID. (3) Uniqueness: It is unique in each measurement run, with the length of each value differing by no more than 25%. (4) Similarity: The cookie values are similar according to the Ratcliff/Obershelp string comparison algorithm [69], with a similarity threshold of 60% or less. In related work, the heuristic is applied to third-party tracking cookies. In our approach, we use the heuristic on first-party tracking cookies. As discussed, first-party cookies are used for various means where an ID is required, but user tracking cannot be assumed (esp., session identification). To validate that the heuristic can be applied in this context, we (1) evaluate manually 100 identified FPT cookies (the top 50 FPT cookies and 25 randomly sampled FPT cookies to test if the heuristic correctly identifies FPT cookies; and 25 randomly sampled non-FPT cookies to test for false negatives), (2) manually analyze 15 well-known FPT cookies to determine if they are correctly classified, and (3) cross-compare the identified cookies with the CookieGraph dataset [56, 57] to assess coverage. For the manual analysis, we used several online sources (e.g., provider documentation, open databases, and site owner) and Internet search engines (e.g., by searching for the cookie name) to identify its purpose. While being time-intensive, we could find a purpose for all manually analyzed cookies.

Christian Böttger, Tareq Khouja, Norbert Pohlmann, Nurullah Demir, and Tobias Urban

ID

Sites

Pages

HTTP Req.

Cookies

JavaScripts

EU1 EU2 US1 US2

24,976 24,975 23,533 24,981

192,470 192,322 181,689 192,479

15,822,039 15,742,516 21,792,272 22,936,063

5,017,332 4,985,296 5,966,304 6,490,947

4,200,529 4,175,046 9,831,813 10,160,264

Table 1: Overview of the measurement dataset.

The manual evaluation of the heuristic showed that it can be used for identifying first-party tracking cookies. For the 10 well-known tracking cookies, the heuristic identified one false negative and two edge cases (possible false positives). In one case (PHPSESSID), it appears a site may have abused PHP session IDs for user tracking. In the other case (AWSALB), load-balancing mechanisms were configured with very long-lasting routing information. In both cases, cookies were configured with very long lifetimes (>6 months) and hold a user ID. Further, the analysis of the 100 sampled cookies shows that 60% are directly related to advertising, 33% can be used for cross-site tracking but also serve other purposes (e.g., bot protection), and 7% are not directly tied to tracking. More detailed results of these validation steps are provided in Section D. Finally, we cross-compare our heuristic classification against the publicly available CookieGraph dataset [56, 57] to assess overlaps of both mechanisms. This comparison yields an 70% overlap of identified cookies. Of the cookies identified by CookieGraph but not by the used heuristic, manual validation of prominent examples shows that at least 41% are related to session management (e.g., _hjSession_) or are valid for only one session, and are therefore out of scope for our study. We therefore conclude that reproducing CookieGraph’s approach would not be expedient for our study. Identifying Known Trackers. To determine the URLs that are (knowingly) associated with user tracking, we used two popular ad-blocking and anti-tracking filter lists, namely EasyList (Version: 202505191305) and EasyPrivacyList (Version: 202505191305) [22, 23]. We use these lists as a baseline to: (1) evaluate the efficacy of current rule-based defenses against first-party tracking, and (2) benchmark our own detection mechanisms against known tracking entities. Filter lists identify trackers by matching URLs against a set of rules (e.g., domain names), a mechanism that does not necessarily transfer to the first-party context [7, 31].

3.3

Measurement Dataset Overview

In our experiment, we visited 758,960 pages, collected over 477,231 first-party cookies, and stored over 3 TB of data. Table 1 provides an overview of the measured data. Note that our goal with the four measurements is not to identify how different regulations (e.g., GDPR) impact first-party tracking, but rather to obtain a representative dataset [15, 16]. Observed Cookies. Overall, we collected 309,887 distinct cookie names and 577,963 distinct cookies (name, path, origin), of which 477,231 were first-party and 151,395 third-party. We identified 50,665 cookies that appear in both contexts across profiles; since each cookie is treated individually, this overlap has no impact on our analysis. On average, each profile contains 5,614,969 (min: 4,985,296,

max: 6,490,947, SD: 740,367) cookies of which 1,060,511 were classified as first-party cookies, we exclude all third-party cookies from further analysis. On average, each page includes 36 (min: 1, max: 11,319, SD: 92) cookies. 466,740 pages contains more than 10 cookies. Identifying Potential First-Party Tracking Cookies. As described in Section 3.3, we found 470k first-party cookies, and applied the defined heuristic (see Section 3.2) to identify potential first-party tracking cookies. After removing cookies with a too short lifespan and a too short length (criteria 1 longevity and 2 length), we have 452,380 distinct cookies and 33,072 distinct cookie keys. Next, we verify whether a cookie appears in more than one of our measurement profiles, so we can test criteria 3 (uniqueness) and 4 (similarity). 19,533 (59%) cookies were filtered out in this step. In the next step, we check if a cookie value is unique and has a similar length across all profiles (criterion 3 uniqueness). We removed 1,432 (4.3%) of the remaining cookies during this step. Finally, we check the similarity of the cookies across the profiles (criterion 4 similarity) and removed 9,712 (29.3%) cookies in this step. After applying the heuristic, we identified 6,249 distinct cookie names that potentially hold an ID. In our final dataset, we included all cookie keys if they were once classified as a potential tracking cookie (i.e., holding an ID). This step ensures that if a cookie of interest is set with a placeholder value (e.g., an empty string or dummy value), it is not excluded due to criteria 2, 3, or 4 of the heuristic. Our data showed that such behavior is not rare, and omitting this step would eliminate cookies such as _ga (Google tracking cookie) and _fbp (Facebook tracking cookie). To homogenize the analyzed cookie names, we use known cookie name patterns provided by cookies.is [13] (e.g., _ga_<USERID> or AMCV_<ORGID>@AdobeOrg), to unify the cookie names (e.g., changing _ga_<USERID> to _ga). This step allows us to provide a better, more interpretable overview of first-party cookie use, as cookie names are clustered. Afterward, we have a total of 25,136 (76%) first-party cookie names that might be used for FPT. Collected JavaScript Code. To analyze the server-side tracking ecosystem, we collected the JavaScript code, the parties that delivered it, and the contexts in which it was included. Overall, we stored 6,280,920 JavaScript files with 2,431,533 distinct MD5 hashes delivered by 24,911 parties (14,535 first parties and 10,376 third parties). Of these scripts, 639,947 interacted with a cookie (e.g., accessing or setting it) that we identified as a first-party tracking cookie (EU1: 337,884, EU2: 288,005, US1: 144,535, US2: 181,385). We exclude all other scripts from our analysis. To identify which party interacts with a first-party tracking cookie, we classify each script by a tuple (𝑑, 𝑠, 𝑡) of loading page, delivering party, and top-level site. A script is first-party if the eTLD+1 of 𝑠 matches 𝑡; a cookie is set in a first-party context if 𝑑 equals 𝑡, regardless of whether 𝑠 is a third party. In FPT deployments, a first-party may directly include a third-party tracking script (see Section 2), making cross-site script similarity a relevant indicator of shared tracking infrastructure. To understand whether similar tracking scripts are reused across different sites, we assess the structural similarity of all collected scripts. Identifying such reuse is essential because, in the first-party context, the hosting domain alone cannot determine whether a

21 1 11 90 9 9211

20000

Overview of Identified JavaScript

First, we provide an overview of the scripts used for FPT purposes to highlight their use in the field and assess whether migration patterns from third-party to first-party contexts are observable. The similar script code might be hosted and delivered directly by various first parties (see Section 2) or a third party. Thus, to identify the tracking code, one cannot simply rely on the party delivering the script; one must assess its content. To establish an understanding of the structural similarities and uniqueness of the collected scripts, we compute SimHash [11, 54] fingerprints for them. SimHashes allow us to compare similarities between scripts (e.g., scripts that only differ in a unique identifier that specifies the hosting party will have a similar or the same SimHash. This comparison enables us to quantify the degree of similarity and divergence between the observed scripts across all sites in the measurement profiles (see Section 4.2). We choose SimHash over abstract syntax trees (AST), as AST-based approaches incur O (𝑛 3 ) overhead versus O (𝑛) for SimHash, with no benefit for our use case; SimHash has further been established for source code comparison [81]. First, we compare the number of distinct SimHashes of each profile. Note that we excluded all JavaScript resources that do not interact with the identified potential first-party tracking cookies (see Section 3.3). Overall, we found 26,606 distinct scripts, according to their SimHash. Of those 12,073 (45%) were delivered in the first-party context and 15,451 (58%) in the third-party context. The numbers do not add up to the total number of identified scripts because we found 916 (3.5%) SimHash-identical scripts that are hosted in both first-party and third-party contexts, indicating that in some cases, the first party directly delivers a script that interacts with potential first-party tracking cookies, which are also delivered by a third party. Overall, these numbers indicate that potential FPT-tracking scripts are hosted in both contexts, suggesting that tracking is no longer limited to third parties. Furthermore, these numbers suggest that trackers are increasingly moving into firstparty contexts, making blocking more challenging. Figure 2 provides an overview of the UpSet analysis [52] of SimHashes in each profile. The UpSet analysis visualizes shared and unique elements across multiple datasets by quantifying their intersections. In contrast to Venn diagrams, it scales efficiently to a larger number of sets and highlights both overlapping and exclusive relationships. The UpSet analysis demonstrates both strong overlaps and distinct differences between the measured datasets. Both regional pairs show substantial overlap (EU: 16,528 shared scripts; US: 8,784), with cross-region intersections of comparable magnitude (7,7k to 7,8k).

71 97

41 36 97

4000

67 13 02 27 1 24 5 17 5

1 13 5 99

57

11

05 1

11

65

2000 0

In this section, we examine the FTP ecosystem by identifying potential FPT tracking scripts, clustering them by source code, attributing them to entities, and assessing the ecosystem’s structure.

4.1

6000

21

Intersection size

The First-Party Tracking Ecosystem

US1 US2 EU2 EU1

43 986 7 2

4

8000

11

script is tracking-related; content-based analysis is required (see Section 4.1). We use SimHashes and the SimHashIndex [54] to assess the similarity of all scripts collected for our analysis. Based on their SimHash, we found 291,542 distinct file contents over all profiles.

77 58

From Third-Party to First-Party: Measuring and Protecting Against Modern Web Tracking Mechanisms

0

Figure 2: Exclusive intersections between the observed scripts in the profiles. The bars on the lower-left show the total size of each dataset. The top bars, in combination with the point matrix, show the intersection sizes for each profile.

The results highlight a core of shared scripts across both EU and U.S. datasets, suggesting that tracking mechanisms are globally deployed. Further, the asymmetric differences indicate regional or context-dependent scripts (e.g., due to JavaScript bundling), potentially reflecting variations in website audiences, regulatory environments, or implementation details of tracking methods.

4.2

Clustering FPT JavaScript Code

As discussed, the same or highly similar code is hosted by firstor third-party providers. Thus, to assess whether tracking code is reused, the URL cannot serve as an indicator to identify FPTrelated requests. To gain a deeper understanding of FPT and the entities involved, we cluster the JavaScript code that interacts with potential FPT cookies. Method to Cluster JavaScript Code. Based on the computed SimHashes of the identified FPT-related JavaScripts, we build the SimHashIndex [54], which clusters scripts based on their sourcecode similarities. We modified the SimHashIndex Python library [1] to store the SimHashes in combination with a 3-tuple: (1) script URL from which the script was loaded, (2) the top-level URL where the script is included, and (3) whether the script is a first-party script. Our SimHashes have a fingerprint bit length of 𝑓 = 64 bits [54, 74]. To determine script similarity, we use the Hamming distance [38] with 𝑘 = 8, meaning two scripts are considered similar if their SimHash fingerprints differ by eight or fewer bits [54, 74, 76], following the near-duplicate detection approach for Web crawling [54, 74]. Clustering operates only on distinct SimHash values; duplicate scripts are assigned to their matching cluster post-hoc. Each cluster is then linked to its site data, allowing a cluster to span multiple sites and delivery parties. Overview of Clustered JavaScript Code. Overall, we found 24,914 cluster with a mean size of 68 (min: 1, max: 186,634, SD: 1,812, median: 4) site data (i.e., sites on which scripts from a cluster were loaded). It is notable that the cluster size is typically 1 or 2 (93% of all clusters), indicating that most clusters contain only a few distinct JavaScript files used by multiple sites. From those clusters, 95 (0.35%) use bundling, meaning a bundle of multiple JavaScripts.

Christian Böttger, Tareq Khouja, Norbert Pohlmann, Nurullah Demir, and Tobias Urban

Cumulative Distribution

1.0 0.8 0.6 0.4 0.2 0.0

Size by number of unique scripts Size by share of URLs 100

101

102 103 Cluster size (log scale)

104

105

Figure 3: Distributions of the number of unique scripts (i.e., SimHashes) in each cluster (blue line), and the number of URLs per cluster (orange line).

Higher 𝑘 values could lead to more scripts per cluster; however, as noted in prior work [54, 74], this would result in scripts that are no longer similar to one another. The number of scripts in the cluster provides an initial insight into the FPT tracking ecosystem, where some tracking scripts are used across multiple sites. While others are unique on distinct sites. It should be noted that the goal in this process is not to build large clusters, but to identify code re-usage (i.e., we do not aim to dissect JS-bundles [67]). Figure 3 provides the distribution of clusters by their sizes, measured by URLs in a cluster. The CDF chart indicates that the vast majority of clusters are relatively small, meaning the scripts are typically confined to a single page. In the context of FPT, some scripts are widely used across multiple sites. This indicates some dominant players in the FPT ecosystem. Specifically, 31% of the clusters contain only a single element of site data. Meaning that unique scripts (in terms of their SimHash) are used in these clusters. From those clusters, only 24 (0.09%) uses bundling. The numerous small clusters represent site-specific or rarely reused scripts, while the large clusters correspond to widely deployed, nearly identical scripts. The combination of a small median (4) and a large standard deviation (1,812) relative to the mean (68) indicates a rightskewed, heavy-tailed size distribution (CV ≈ 26), implying that a few mega-clusters [25] exist. This corresponds to observations that the third-party tracking ecosystem is dominated by a few central players [5, 28, 29, 70].

4.3

Attributing FPT Clusters

FPT decreases transparency as it is not easy for users to understand who (e.g., which third party) is serving tracking scripts (see Section 2). In the following, we aim to attribute the identified clusters and their corresponding tracking scripts to third parties (i.e., known trackers), even if they were served in a first-party context. The created clusters contain scripts loaded in the first- and third-party contexts, allowing us to determine which third party is responsible for distributing a script. Since third-party script URLs directly reveal the hosting domain, and thus the responsible provider. We use them to identify which companies operate the scripts contained in each cluster. To identify the tracking provider, we use the WhoTracksMe [45] database. Thus, we attribute a cluster to a third party based on the third-party domains from which the script is loaded. WhoTracksMe is based on the open-source project trackerdb [33], which can be incomplete. Therefore, we may not be able to attribute all providers.

If the third-party URL is related to a provider (e.g., Google), we can attribute a cluster to one provider. If there is more than one provider, we assign the cluster to the provider with the largest share of script URLs, which was the case for 127 (0.5%) clusters. We identify 10,399 (42%) clusters that do not contain any third-party script. Among the clusters that include at least one third-party script, our attribution method successfully assigns 8,477 (34%) clusters to a provider. Applying the same approach on the first-party-only clusters yields additional 663 (3%) attributed clusters. Overall, this results in 9,140 (37%) clusters that can be attributed to a specific provider. Although the WhoTracksMe database does not map every observed eTLD+1 to a third party, our attribution method still classifies 37% of all clusters as belonging to a tracking entity. These attributed clusters encompass 76% (91,209) of all measured script URLS. The results indicate that a substantial share of tracking infrastructure operates without visible third-party scripts, highlighting how FPT reduces transparency by shifting functionality to firstparty code. Further, it shows that large providers dominate the ecosystem, while many smaller on-server-side implementations remain difficult to detect. Top Cluster in the FPT Ecosystem. Due to the heavy-tailed distribution of entity sizes within the tracking ecosystem, a small number of actors account for a disproportionate share of the overall activity. The top 10 clusters represent 44% of the script URLs and are present on 74% of the sites and 72% pages. Examining the top 10 clusters based on site data thus provides a representative view of the dominant entities that shape the ecosystem’s structure and dynamics, while maintaining analytical tractability. For these clusters, 99% of the scripts are also loaded in a third-party context (see Table 2), allowing provider attribution via third-party URLs. In Table 2, we provide an overview of the analysis and attribution for the top 10 clusters. In total, we found 52,822 distinct URLs in the top 10 clusters. Google is the prominent actor in these clusters, which aligns with previous observations of the Web tracking ecosystem [6, 25]. Aggregated over all clusters, 8% of the requests are issued by the first-party context, showing that a substantial part of tracking is already happening in this context. In the top 10, only 2 clusters (overall 13,534; 50%) operate solely in the third-party context, highlighting a trend toward FPT. In these cases (i.e., Meta and HubSpot), the tracking scripts are loaded by a third-party request, but the scripts utilize FPT cookies. Further, we see no direct relation between the number of sites that employ a specific script from a cluster and the share of first-party requests. This observation suggests that there is not a small share of clusters responsible for most FPT, but rather several clusters. However, the ecosystem seems to be dominated by central players. Attribution of First-Party Provider. Overall, we could attribute clusters to 492 different providers. Table 3 provides an overview of the top 10 providers, which covers 5,448 (60%) of the attributed clusters. It is notable that Logicad (a demand-side platform used for real-time bidding) is the most attributed cluster, but overall, clusters attributed to companies such as Google, Adobe, or Amazon contain more sites, thereby increasing their relevance to the FPT ecosystem. Among the top 10 providers, Google has high coverage across sites and pages where the clusters are present, indicating its reach in the FPT ecosystem. The results show that tracking

From Third-Party to First-Party: Measuring and Protecting Against Modern Web Tracking Mechanisms

No.

Attribution

# Sites

# Pages

Cookies Used

Script URLs

Requests

1st Party Req.

3rd Party Req.

1 2 3 4 5 6 7 8 9 10

Google Google Google Google Google Google Meta Google HubSpot Google

5,141 2,990 4,311 2,889 3,532 2,121 3,458 1,252 555 678

44,954 27,916 36,467 22,379 28,270 18,013 31,955 10,688 5,077 6,585

597 489 523 521 614 389 518 283 123 150

14,611 7,599 33 11,106 9,162 5,461 7 2,894 1,785 1,177

186,634 125,637 81,832 81,094 75,940 55,799 52,186 44,395 24,356 20,485

1,411 1,131 292 234 1,198 77 0 572 0 334

185,223 124,506 81,540 80,860 74,742 55,722 52,186 43,823 24,356 20,151

Across all clusters

13,187

136,891

3,378

119,912

1,705,780

142,036

1,563,695

Table 2: Top 10 clusters by the number of observed HTTP requests loading potential FPT-related JavaScripts.

No.

Provider

1 2 3 4 5 6 7 8 9 10

Logicad Google Adobe Wingify Amazon Associates Tealium Alibaba HubSpot Siteimprove Microsoft

Clusters

Share

Sites

1,675 1,555 567 461 442 295 133 128 98 94

30.75% 28.54% 10.40% 8.46% 8.11% 5.41% 2.44% 2.39% 1.80% 1.73%

35 10,432 1,107 175 1,246 258 182 730 149 2,717

Table 3: Top 10 of the actors to which we found the most attributed clusters, ordered by cluster size.

providers known from the third-party context are also dominant in first-party tracking. Overall, the number of clusters per entity exhibits a long tail distribution. While these partners contribute fewer clusters overall (roughly 14% of all clusters), they are included on a substantial number of sites (e.g., Microsoft with 2,717 sites).

4.4

Usage of First-Party Tracking Cookies

We examine the most commonly used cookies and the distribution of cookies from first- and third-party scripts across the different clusters. To establish a consistent basis for comparing cookie usage across clusters, we first normalize cookie names. In many cases, cookie providers augment the base cookie name with suffixes (e.g., _ga_<ID>), which obscures their semantic equivalence. We therefore extract the shared prefix of each cookie by removing these identifiers, e.g., transforming _ga_<ID> into _ga. Following related work, we employ a pattern-list and wildcard-based approach to derive normalization rules [40]. We extracted the patterns from cookie.is [13] and applied them to our database to identify and collapse cookies into their canonical form. Using this method, we successfully normalized 37,647 cookies.

Cookie Usage by Clusters. After normalization, we examine the distribution of cookie usage across the identified clusters. On average, a cluster uses 3 (min: 1, max: 614, SD: 13, median: 1) first-party tracking cookies, and 11,071 (44%) of the clusters use more than one cookie. 56% of clusters use only a single cookie. These singlecookie clusters predominantly rely on __smn_fid (6.7%), _gcl_au (5.6%) from Google, _abck (4.7%) from Akamai, or _ga (1.5%) also from Google. In total, we identify 1,525 distinct cookies that occur exclusively in a single cluster. 13,749 (55%) of such clusters contain a single script responsible for setting that cookie, indicating highly customized FPT and SST deployments. The __smn_fid cookie, used by Search Marketing Networks (SMN) (e.g., Google Ads, Microsoft Advertising), exemplifies such tailored infrastructures. Notably, clusters with only one cookie have up to 5 unique JavaScripts that set it. Furthermore, 6,595 (27%) of these clusters rely solely on first-party scripts, meaning that roughly one-quarter are first-party–only configurations in which multiple unique scripts set a single identifier. Thus, this practice obscures detectability and decreases transparency for users. Additionally, 7,192 (29%) clusters without first-party scripts, indicating continued third-party dominance. Finally, only 56 (0.2%) of scripts in these clusters were loaded within a first- and third-party context, cases where a migration from third- to first-party could be happening. These clusters include 123 sites and 745 pages. Totally, clusters with only one cookie include 5,789 (24%) sites and 35,087 (5%) pages from our scope, where first-party only clusters have one percent more sites and pages than third-party only clusters. In FPT, a small set of cookies dominate clusters, including just one cookie. Most of them are attributed to a well-known third-party provider. This suggests that third-party tracking providers also play a significant role in the first-party tracking ecosystem. Among clusters using more than one cookie, 3,804 (15%) load all cookies exclusively in the first-party context, whereas 6,342 (25%) load them only in the third-party context. Third-party scripts occur 4 times more frequently, yet third-party code still influences tracking workflows even in first-party contexts. In the long tail, third-party context may slightly shift out, as first-party becomes more dominant, decreasing future third-party script influence. Further, we find identical scripts and cookies in both contexts illustrate

Christian Böttger, Tareq Khouja, Norbert Pohlmann, Nurullah Demir, and Tobias Urban

the intertwined FPT mechanisms. 925 (3.7%) of the clusters that include more than one cookie are loaded in the first- and third-party context. The ratio of third- to first-party URLs in those clusters is 23 : 1, indicating strong dominance of third-party URLs. Clusters that have cookies loaded in first- and third-party include 12,003 (49%) sites and 123,102 (16%) pages, indicating migration is significant. The number of tracking cookies across multiple clusters on nearly half of the sites indicates that third-party tracking providers dominate FPT. Cookie Cross Usage. Finally, we examine relations between cookies by studying their co-occurrence.The most common tuple combines the two most frequently used cookies overall. However, the intersection, only 11.5% of clusters containing both, reveals considerable functional heterogeneity in FPT deployments. Despite the broad adoption of individual cookies, their limited coexistence suggests that provider-specific, rather than universal, configuration strategies are used. This results in substantial configurational diversity, where specific combinations of identifiers align with distinct tracking workflows. Across sites, the top ten pairs appear in 47%–50% of all domains in our measurement scope, highlighting the widespread operational relevance of cookie pairings in the FPT ecosystem. These cross-cookie usage results map to and reduce findings of Bahrami et al. [59].

4.5

Structure of the FPT Ecosystem

To characterize the relational dependencies within the FPT ecosystem beyond scripts and cookies, we construct a network graph from the clustered JavaScript and observed cookies to reveal the emergent topology of FPT deployments. We define a node as a cookie or JavaScript cluster. Edges between cookies and clusters are built if a cookie is used (i.e., set or accessed) by a script in a cluster. Appendix C provides an overview of the top 5 clusters by site data. The graph contains 28,292 nodes with 72,097 edges and has an average connectivity of 2.5 edges per node. Overall, the graph is sparse, with only a small fraction of all possible cluster-cookie relationships. This observation indicates selective cookie reuse rather than arbitrary identifier deployment. From an ecosystem perspective, this structure implies that FPT is highly asymmetric, focusing on a small subset of cookies, and clusters likely enable disproportionate cross-site linkage. The ecosystem itself contains 162 components with the largest component of 25,901 nodes. This implies that clusters and cookies are structurally connected through shared vendors or infrastructure. From the perspective of privacy developers and researchers, this finding is a first indication that novel defense mechanisms, such as cookie or JavaScript-based ones, may be a path towards protecting users. We leave this for future work. Isolated components represent custom, first-party-only deployments with no dependencies. In FPT, clusters embedded within large components pose a higher privacy risk due to indirect identifier linkage. To further analyze the structural dependencies between identifiers, we project the cluster-cookie graph into a one-mode cookiecookie graph, where edges denote the co-occurrence of two cookies within the same cluster. While the original graph is highly

sparse, the resulting projection exhibits a pronounced edge explosion, yielding 3,181 cookie nodes connected by 625,486 edges. This indicates that cookies are not deployed independently but rather as tightly coupled bundles, where even moderately sized clusters induce near-clique structures in the projection. Applying modularity-based community detection to this graph reveals that detected communities primarily correspond to recurring cookie bundles rather than isolated identifiers. These communities capture standardized FPT configurations that are reused across multiple clusters and sites, reflecting shared infrastructure or template deployments. From a privacy perspective, this shows that tracking capability emerges from the collective behavior of co-deployed cookies, suggesting that reasoning about individual identifiers in isolation underestimates the effective tracking surface exposed by FPT systems.

5

Protecting Against FPT

As shown, tracking activities are increasingly moving into the firstparty context. This opens the question of whether current rulebased approaches sufficiently protect users’ privacy. To advance FPT detection, we propose a data-driven rule-based classification technique that derives blocking rules from structural patterns in URLs. Our approach uses patterns in URL query parameters, which are often indicative of tracking-related activity. We evaluate the rules and test if they can detect FPT-related URLs without breaking pages.

5.1

Dataset Construction

First, we assess whether current blocking lists are sufficient to protect against FPT. Therefore, we test how many of the identified URLs that serve FPT-related JavaScript (see Table 2) are flagged by EasyList or EasyPrivacy. We find that only 33,081 (27,5%) of the URLs would have been blocked by any of these two lists. Thus, current protection mechanisms do not yet provide adequate coverage for these emerging tracking technologies. To overcome this limitation of the blocklists, we develop an approach to derive rules tailored for FPT based on URL features. To build protection mechanisms against FPT, we curate two datasets ensuring that mined patterns reflect FPT-specific behavior rather than incidental measurement properties. Our analysis relies on two datasets collected during the largescale measurement. The first dataset contains FPT-related URLs that served JavaScripts that are not flagged by either list. We chose our approach so that it captures criteria that are not yet covered and does not identify patterns already present in current lists.The dataset contains 86,831 URLs. The second dataset contains the same number of randomly sampled ULRs that are not related to tracking, as determined by both our approach and the two lists. For both datasets, we used 90% of the URLs for training (78,147 URLs per dataset) and 10% for validation (8,684 URLs). We name the datasets that contain the FPT-related requests D𝐹 𝑃𝑇 (training) and V𝐹 𝑃𝑇 (validation), and accordingly the datasets that contain the nontracking-related requests D𝑂𝑡ℎ𝑒𝑟 and V𝑂𝑡ℎ𝑒𝑟 .

From Third-Party to First-Party: Measuring and Protecting Against Modern Web Tracking Mechanisms

5.3

104

Frequency (log scale)

103 102 101 100

0

200

400

600

Query Key Rank (1 = most frequent)

800

Figure 4: Rank–frequency distribution: keys are ordered by decreasing frequency. Note the logarithmic scale.

Cumulative % of Total Occurrences

100 80 60 40 20 0

N95 = 40 keys N99 = 161 keys

200

400

600

Number of Top Keys

800

Figure 5: Cumulative coverage curve for the identity keys.

5.2

Frequent Pattern Mining

Before mining feature combinations at scale, we performed an exploratory correlation-gap analysis as a proof-of-concept to verify that FPT-related traffic exhibits class-specific co-occurrence structure among query keys. Specifically, we selected the top 100 most frequent query keys and computed their pairwise association structure (a correlation matrix) separately for tracking and non-tracking requests. To quantify how strongly a candidate pattern 𝑝 separates the two classes, we define the Correlation Gap (CorrGap) as

Feature Extraction

Naturally, in FPT, the domain name in a URL is a weak indicator for tracking, as it changes from site to site. Therefore, to test whether FPT-related requests exhibit consistent structural patterns at the URL level, we only consider the set of query-parameter keys for our analysis (e.g., parameter names such as cid). Concretely, we extract all query keys from D𝐹 𝑃𝑇 and treat each key as a binary feature indicating its presence in a request. We observe 940 unique query keys, forming a highly skewed vocabulary. The rank-frequency curve (see Figure 4) exhibits a rapid decay on a logarithmic scale: a small subset of keys accounts for most occurrences, whereas a long tail of keys appears only sporadically. This Zipfian-like distribution suggests that most structurally informative variation is concentrated in the high-frequency region. Complementing this, the cumulative coverage curve in Figure 5 highlights the strong concentration of key occurrences: the top 161 keys account for approximately 99% of all key appearances. This Pareto-like property motivates restricting the feature space to the most frequent keys as a practical trade-off between coverage and feature dimensionality. Further, this restriction will yield fewer rules for more popular keys, bridging a trade-off between blocking lists that contain too many rules that are rarely or never used [7]. Based on this selection, we construct augmented datasets by adding binary indicator columns for each retained key. To prepare each training example (URL) for pattern mining, we tokenize its query string into query keys and retain only those keys contained in the selected vocabulary. Thus, each request is represented by a 161-dimensional binary feature vector indicating which keys are present.

CorrGap(𝑝) = |Pr(𝑝 | FPT) − Pr(𝑝 | Other)|

(1)

Here, Pr(𝑝 | tracking) denotes the empirical probability that a tracking-labeled request (i.e., all requests in D𝐹 𝑃𝑇 ) contains pattern 𝑝, and Pr(𝑝 | non-tracking) is defined analogously for requests in D𝑂𝑡ℎ𝑒𝑟 . We estimate both probabilities as relative frequencies over the respective datasets. In this proof-of-concept analysis, 𝑝 corresponds to a key pair (𝑘𝑖 , 𝑘 𝑗 ), i.e., the joint occurrence of two query keys within the same request. A higher CorrGap score indicates key pairs whose co-occurrence is substantially more (or less) common in FPT-related traffic than in other traffic. Empirically, this analysis showed a clear separation between tracking and non-tracking traffic for several query-key pairs, confirming the existence of a class-specific co-occurrence structure. As this pairwise analysis does not scale to thousands of features and multi-million-row datasets, we transition to scalable frequent pattern mining. We represent each HTTP request as a transaction containing the set of query keys present in its URL, and mine frequent itemsets using FP-Growth [39] (Frequent Pattern Growth). FP-Growth is well-suited for our setting because it avoids explicit candidate generation and remains tractable on large, sparse transactional data by compressing requests into an FP-tree and recursively mining conditional subtrees. We mine itemsets separately on D𝐹 𝑃𝑇 and D𝑂𝑡ℎ𝑒𝑟 , restricting the maximum itemset size to 3 keys to focus on short, interpretable structural interactions while limiting combinatorial growth. Further, analyzing more keys would lead to more complex blocking rules, which might be too slow to process at scale in a state-of-the-art ad blocker. We set the minimum support to 0.001 (i.e., an itemset must occur in at least 0.1% of requests) to retain only robust patterns that generalize beyond individual websites. Under this configuration, FP-Growth finds 456 frequent itemsets across both datasets.

5.4

Statistical Scoring and Rule Selection

FP-Growth returns frequent itemsets in a dataset, but frequency alone does not imply that a pattern is specific to FPT. Therefore, we apply a contrastive scoring procedure that quantifies, for each candidate itemset 𝐼 , how strongly it separates FPT-related from non-tracking requests. Let D𝐹 𝑃𝑇 and D𝑂𝑡ℎ𝑒𝑟 denote the tracking and non-tracking training datasets, respectively, and let 1[𝐼 ⊆ 𝑟 ] indicate whether request 𝑟 contains all keys in itemset 𝐼 . We compute class-specific supports as empirical probabilities: ∑︁ 1 supportFPT (𝐼 ) = 1[𝐼 ⊆ 𝑟 ], |D𝐹 𝑃𝑇 | 𝑟 ∈ D 𝐹 𝑃𝑇 (2) ∑︁ 1 supportOther (𝐼 ) = 1[𝐼 ⊆ 𝑟 ]. |D𝑂𝑡ℎ𝑒𝑟 | 𝑟 ∈ D 𝑂𝑡ℎ𝑒𝑟

Christian Böttger, Tareq Khouja, Norbert Pohlmann, Nurullah Demir, and Tobias Urban

We additionally record the corresponding absolute counts 𝑐 FPT (𝐼 ) and 𝑐 Other (𝐼 ). To quantify enrichment in tracking traffic, we define the support ratio as follows: SR(𝐼 ) =

supportFPT (𝐼 ) + 𝜖 supportOther (𝐼 ) + 𝜖

(3)

where 𝜖 is a small constant to avoid division by zero when an itemset never occurs in the D𝑂𝑡ℎ𝑒𝑟 (i.e., a set of keys only occurs in tracking requests). We also report log2 SR(𝐼 ) as an effect size on a multiplicative scale. Thus, high values of 𝑆𝑅(𝐼 ) indicate that 𝐼 is more frequent in D𝐹 𝑃𝑇 . Finally, we use a two-sided Fisher’s exact test to verify that the observed association between itemset presence and the FPT labels is statistically significant (i.e., unlikely to have arisen by chance). The results confirm that the vast majority of retained itemsets exhibit a significant association with the FPT label. Specifically, of the 456 mined itemsets, 435 (95%) are statistically significant, indicating that the observed enrichment of these patterns is not due to random variation. This scoring step prioritizes itemsets that are (1) sufficiently prevalent to be robust and (2) disproportionately more prevalent in FPT-related traffic (i.e., high support ratio), while deprioritizing patterns that occur frequently in both classes. We focus only on itemsets with SR(𝐼 ) > 1, as these are more frequent in tracking traffic and relevant for rule generation. Out of 456 itemsets, 242 meet this criterion. They show a wide spread in support ratios, with a mean of 422.8, a median of 31.9, and a maximum of 7166.98. The high maximum and standard deviation (979.2) are due to top itemsets that occur frequently in D𝐹 𝑃𝑇 but are absent D𝑂𝑡ℎ𝑒𝑟 . In contrast, the 214 itemsets with SR(𝐼 ) < 1 are more common in D𝑂𝑡ℎ𝑒𝑟 and are thus excluded. We select a threshold of SR(𝐼 ) ≥ 10, meaning that an itemset is at least ten times more likely to occur in D𝐹 𝑃𝑇 than in D𝑂𝑡ℎ𝑒𝑟 . This threshold was chosen to retain patterns that are strongly enriched in tracking traffic while avoiding overly restrictive filtering that would discard informative but less extreme itemsets. This threshold retains patterns strongly enriched in tracking traffic while avoiding overly restrictive filtering.

5.5

Building FPT Blocking Rules

To operationalize the statistically enriched itemsets from Section 5.4 as deployable countermeasures, we automatically translate retained query-key combinations into Adblock Plus (ABP)–compatible URL filter rules (i.e., rules that can be included into popular blocking lists like EasyList). This translation step is required because frequent itemsets are unordered sets of keys, whereas HTTP requests encode query parameters in an order that may vary across implementations. Rule Generation Approach. Frequent itemsets are inherently unordered, and the same set of query keys may appear in different orders in real traffic. To avoid emitting one rule per key permutation, we construct a single ABP-compatible regex that enforces set membership using positive lookaheads. Concretely, for an itemset with keys 𝑘 1, ..., 𝑘𝑚 , we emit a rule that (1) anchors at a query boundary and (2) requires each key to occur somewhere in the query string (before the fragment delimiter). An example for the itemset {if, r, v} is: /[\?&](?=[^#]*\bif=)(?=[^#]*\br=)(?=[^#]*\bv=)[^#]*/ The prefix /[\?&] anchors the match at the beginning of the query

string (after ?) or at a parameter boundary (after &). Each lookahead, e.g., (?=[^#]*\bif=), enforces that the corresponding key occurs somewhere in the query component before the fragment delimiter #. Because lookaheads do not consume characters, the required keys may appear in any order and may be separated by arbitrary intervening parameters. Finally, [^#]* consumes the remainder of the query string while ensuring the match does not cross into the fragment part of the URL. For single-key itemsets, we emit the simpler rule /[?&]k=/ without lookaheads. This procedure provides a systematic bridge from validated co-occurrence patterns to compact blocking rules that can be applied to existing URL-filtering methods. Rule Evaluation. Following the presented approach, we derived 181 filter list rules to protect against FPT. To evaluate these rules, we test them against our validation datasets V𝐹 𝑃𝑇 and V𝑂𝑡ℎ𝑒𝑟 . If our rules match any of the URLs in V𝐹 𝑃𝑇 , we assume that it would have blocked an FPT-related request, while blocking a request in V𝑂𝑡ℎ𝑒𝑟 is most likely a false positive that could lead to page breakage. We find that the rules correctly classified 5,482 (63%) of the URLs in V𝐹 𝑃𝑇 while EasyList and EasyPrivacy flagged none of these requests. Thus, our approach provides reliable protection against FPT with only a few filter rules (≈ 0.2% of the used EasyList). When applying the rules to V𝑂𝑡ℎ𝑒𝑟 , we find that the rules would have blocked 260 (3%) URLs. To better understand the potential impact of falsely blocking these requests, we perform a visual page-breakage analysis.

5.6

Visual Page Breakage Analysis

To evaluate the usability of our blocking rules in a real-world scenario. We perform a visual page breakage analysis [7, 57, 73] on the top 2,300 URLs from the Tranco list2 using the created set of 181 blocking rules. Therefore, we configured two OpenWPM instances to visit each site’s landing page, wait until the page loads (or 30 seconds), and take a screenshot of the full page. One crawling instance uses the AdBlock Plus extension [27], which loads our generated rules rather than the standard blocking lists used by the tool. The other instance is a vanilla OpenWPM instance serving as a baseline for the page-breakage analysis. We started both instances on two identically configured virtual machines at the same time. To identify visual page breakage, two authors compare screenshots of a site to look for clues that a page has stopped working. For this coding the authors used four different codes: (1) Working, indicating that the page seems to work as usual; (2) Broken, indicating that the page stopped working; (3) Blocked, indicating that the page is showing a warning message that an ad blocker is being used that should be deactivated to continue; (4) Missing, indicating that at least one screenshot of a page is missing (i.e., one of the instances could not access the page); (5) Denied, indicating an error (e.g., “access denied“ or bot detection check) on the page. Of the analyzed websites, 668 (29%) could not be analyzed in both instances (“Missing”), 135 (5.8% denied the access to the page (“Denied“). 32 (1.4% page detected the usage of an ad blocker (“Blocked”), and 1,464 (63.7%) seem to work as expected (“Working”). Consequently, 1 (0.04%) of the page did not work properly after applying 2 https://tranco-list.eu/list/X4N2N/1000000

From Third-Party to First-Party: Measuring and Protecting Against Modern Web Tracking Mechanisms

the blocking rules, suggesting that the approach is valid for building filter rules. It was expected that only a few pages would identify the use of an ad blocker, as pages typically do so by querying a known tracking URL to see if the request is being blocked. Our rules will not block these requests.

6

Related Work

El Farihi et al. found SST nearly as effective as client-side tracking on Meta, but with a 40% false-match rate [24]. Alegría et al. analyze GTM tags across the million most popular sites and identify violations of GTM’s permission system [3]. Our work situates GTM within the broader FPT/SST ecosystem rather than studying it in isolation. In a further approach, Munir et al. present CookieGraph [57]. In their work, they perform large-scale measurements to collect first- and third-party cookies, labeling them with a combination of filter lists and an ML-based approach to identify tracking requests. CookieGraph is trained with labeled data (supervised learning) to detect and block first-party tracking cookies. We aim to provide a broad overview of FPT, including its ecosystem. While CookieGraph mainly focuses on detecting first-party cookies. Nikkhah Bahrami et al. propose a browser-based mechanism to block unauthorized cross-domain cookie usages [59]. We dig deeper into FPT by not limiting ourselves to a specific platform or technique, but by providing a generalizable approach to identify them on the Web and by analyzing their ecosystem. Further, we provide a first approach to building privacy-enhancing technologies that protect against FPT. Fouad et al. focus on the non-compliant practices of SST in the context of the GDPR and ePrivacy Directive [32] and use a cloakingbased approach to identify potential SST activities. In our approach, we avoid cloaking techniques and instead derive a rule-based detection approach. The Web Almanac 2024 also reports a shift from third-party to first-party cookie usage. Major providers (e.g., Meta) largely disappeared from third-party cookie settings in 2024 [82], while their first-party cookie settings increased [81]. Our results extend these findings by providing a comprehensive view of the FPT ecosystem and related trends.

7

Conclusion

Our large-scale measurement study, incorporating two vantage points and four measurement profiles, demonstrates that first-party tracking is a growing phenomenon increasingly shifting into the first-party context. This shift poses several downsides for users, including reduced transparency, diminished control, and limited ability to block such tracking, as current filter lists are not optimized for first-party resources. The results show that, in terms of source code, tracking scripts sharing the same cookies operate in both contexts, indicating that the FPT ecosystem mirrors its third-party counterpart and is dominated by the same well-known players (e.g., Google and Meta). Based on the shared use of cookies and tracking scripts, we construct a network graph showing that the FPT ecosystem is highly interconnected, with dense co-deployment of cookies across clusters. To address the protection gap, we automatically derive filter rules tailored to FPT, demonstrating that they outperform current filter lists in the first-party context, underscoring the need for more effective blocking mechanisms. In conclusion, FPT poses

an emerging privacy threat on the Web for which existing defenses remain inadequate. Limitations and Future Work. Our analysis is limited to clientside indicators of FPT. We cannot assess site backends, so we cannot draw conclusions about server-side data flows. Future work could explore server-side mechanisms by deploying trackers in controlled environments to understand their backend logic. We further restrict our scope to cookie-based tracking within JavaScript, excluding techniques such as tracking pixels, which we consider part of future work.

Acknowledgments The authors gratefully acknowledge funding from the German Federal Ministry of Education and Research (grants 16KIS1629 “UbiTrans”) and the German Federal Ministry for Housing, Urban Development and Building. We also thank Google for the generous funding that supported this research.

References [1] 1e0ng on GitHub. 2013. SimHash: a Python implementation of the Simhash algorithm. https://github.com/1e0ng/simhash. [2] Gunes Acar, Christian Eubank, Steven Englehardt, Marc Juarez, Arvind Narayanan, and Claudia Diaz. 2014. The Web Never Forgets: Persistent Tracking Mechanisms in the Wild. https://doi.org/10.1145/2660267.2660347. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS ’14). Association for Computing Machinery, New York, NY, USA, 674–689. doi:10.1145/2660267.2660347 [3] Javiera Alegría, Ivana Bachmann, and Javier Bustos-Jiménez. 2025. Google Tag Manager and Its Privacy Issues. https://doi.org/10.1007/978-3-032-06155-3_10. In Security and Trust Management: 21st International Workshop, STM 2025, Toulouse, France, September 25–26, 2025, Proceedings (Toulouse, France). Springer-Verlag, Berlin, Heidelberg, 173–189. [4] Adam Barth. 2011. RFC 6265: HTTP State Management Mechanism. https: //datatracker.ietf.org/doc/html/rfc6265. doi:10.17487/RFC6265 [5] Reuben Binns, Ulrik Lyngs, Max Van Kleek, Jun Zhao, Timothy Libert, and Nigel Shadbolt. 2018. Third Party Tracking in the Mobile Ecosystem. https://doi.org/10.1145/3201064.3201089. In Proceedings of the 10th ACM Conference on Web Science (Amsterdam, Netherlands) (WebSci ’18). Association for Computing Machinery, New York, NY, USA, 23–31. [6] Nils Bonfils. 2025. An Empirical Inquiry into Surveillance Capitalism: Web Tracking. https://arxiv.org/abs/2508.07454. arXiv:2508.07454 [cs.CY] [7] Christian Böttger, Nurullah Demir, Jan Hörnemann, Bhupendra Acharya, Norbert Pohlmann, Thorsten Holz, Matteo Grosse-Kampmann, and Tobias Urban. 2025. Understanding Regional Filter Lists: Efficacy and Impact. http://dx.doi.org/10. 56553/popets-2025-0063. Proceedings on Privacy Enhancing Technologies 2025, 2 (April 2025), 309–325. doi:10.56553/popets-2025-0063 [8] Aaron Cahn, Scott Alfeld, Paul Barford, and S. Muthukrishnan. 2016. An Empirical Study of Web Cookies. https://doi.org/10.1145/2872427.2882991. In Proceedings of the 25th International Conference on World Wide Web (Montréal, Québec, Canada) (WWW ’16). International World Wide Web Conferences Steering Committee, Republic and Canton of Geneva, CHE, 891–901. [9] Stefano Calzavara, Tobias Urban, Dennis Tatang, Marius Steffens, and Ben Stock. 2021. Reining in the Web’s Inconsistencies with Site Policy. In Symposium on Network and Distributed System Security (NDSS). doi:10.14722/ndss.2021.23091 [10] Captain Compliance. 2026. _abck Cookie: What Does it Mean? https:// captaincompliance.com/education/_abck/. [11] Moses S. Charikar. 2002. Similarity Estimation Techniques from Rounding Algorithms. In Proceedings of the 34th Annual ACM Symposium on Theory of Computing (STOC ’02). Association for Computing Machinery, New York, NY, USA, 380–388. doi:10.1145/509907.509965 [12] Cookiedatabase.org. 2026. s_v_web_id – Summary. https://cookiedatabase.org/ cookie/tiktok/s_v_web_id/. [13] CookieHub. 2026. Cookie Database — cookie.is. https://www.cookie.is/. [14] Ha Dao, Johan Mazel, and Kensuke Fukuda. 2021. CNAME Cloaking-Based Tracking on the Web: Characterization, Detection, and Protection. IEEE Transactions on Network and Service Management 18, 3 (2021), 3873–3888. doi:10.1109/ TNSM.2021.3072874 [15] Nurullah Demir, Matteo Große-Kampmann, Tobias Urban, Christian Wressnegger, Thorsten Holz, and Norbert Pohlmann. 2022. Reproducibility and Replicability of Web Measurement Studies. In Proceedings of the ACM Web Conference 2022

Christian Böttger, Tareq Khouja, Norbert Pohlmann, Nurullah Demir, and Tobias Urban

(Virtual Event, Lyon, France) (WWW). Association for Computing Machinery, New York, NY, USA, 533–544. doi:10.1145/3485447.3512214 [16] Nurullah Demir, Jan Hörnemann, Matteo Große-Kampmann, Tobias Urban, Norbert Pohlmann, Thorsten Holz, and Christian Wressnegger. 2023. On the Similarity of Web Measurements Under Different Experimental Setups. https://doi.org/10.1145/3618257.3624795. In Proceedings of the 2023 ACM on Internet Measurement Conference (Montreal QC, Canada) (IMC ’23). Association for Computing Machinery, New York, NY, USA, 356–369. [17] Nurullah Demir, Daniel Theis, Tobias Urban, and Norbert Pohlmann. 2022. Towards Understanding First-Party Cookie Tracking in the Field. https://arxiv.org/ abs/2202.01498. CoRR abs/2202.01498 (2022). arXiv:2202.01498 [18] Nurullah Demir, Tobias Urban, Kevin Wittek, and Norbert Pohlmann. 2021. Our (in)Secure Web: Understanding Update Behavior of Websites and Its Impact on Security. In Conference on Passive and Active Measurement (PAM). SpringerVerlag, Berlin, Heidelberg, 76–92. doi:10.1007/978-3-030-72582-2_5 [19] Nurullah Demir, Tobias Urban, Christian Wressnegger, and Norbert Pohlmann. 2024. A Large-Scale Study of Cookie Banner Interaction Tools and Their Impact on Users’ Privacy. https://doi.org/10.56553/popets-2024-0002. Proceedings on Privacy Enhancing Technologies 2024, 1 (2024), 5–20. doi:10.56553/popets-20240002 [20] Demir, Nurullah. 2023. MultiCrawl. https://github.com/nrllh/multicrawl. Used version: MultiCrawl (v0.1.2). [21] Google Developers. 2024. What is SST? - SST Fundamentals. https://developers. google.com/tag-platform/learn/sst-fundamentals/2-what-is-sst. [22] The EasyList authors. 2023. EasyList. https://easylist.to/easylist/easylist.txt. Used list from March 23, 2023; version 202303230338. [23] The EasyList authors. 2024. EasyPrivacy. https://easylist.to/easylist/easyprivacy. txt. Used list from July 22, 2024; version 202407221302. [24] Asmaa El fraihi, Nardjes Amieur, Walter Rudametkin, and Oana Goga. 2024. Client-side and Server-side Tracking on Meta: Effectiveness and Accuracy. https: //hal.science/hal-04665102. In PETS 2024 - 24th Privacy Enhancing Technologies Symposium, Vol. 2024. Bristol, United Kingdom, 431–445. doi:10.56553/popets2024-0086 [25] Steven Englehardt and Arvind Narayanan. 2016. Online tracking: A 1-millionsite measurement and analysis. In Proceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 1388–1401. doi:10.1145/ 2976749.2978313 [26] 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. https: //doi.org/10.1145/2736277.2741679. In Proceedings of the 24th International Conference on World Wide Web (Florence, Italy) (WWW ’15). International World Wide Web Conferences Steering Committee, Republic and Canton of Geneva, CHE, 289–299. doi:10.1145/2736277.2741679 [27] eyeo GmbH. 2024. Adblock Plus Extension, Version 4.32.2.1. https://adblockplus. org/. Browser extension for ad blocking. Available for Chrome, Firefox, Edge and others.. [28] Marjan Falahrastegar. 2017. The complex third-party tracking ecosystem: a multidimensional perspective. Ph. D. Dissertation. Queen Mary, University of London. PhD thesis. [29] Marjan Falahrastegar, Hamed Haddadi, Steve Uhlig, and Richard Mortier. 2014. Anatomy of the Third-Party Web Tracking Ecosystem. https://arxiv.org/abs/ 1409.1066. arXiv:1409.1066 [cs.SI] [30] Ben Fisher. 2020. Improve performance and security with ServerSide Tagging. https://blog.google/products/marketingplatform/360/improveperformance-and-security-server-side-tagging/. [31] Imane Fouad, Nataliia Bielova, Arnaud Legout, and Natasa Sarafijanovic-Djukic. 2020. Missed by Filter Lists: Detecting Unknown Third-Party Trackers with Invisible Pixels. https://doi.org/10.2478/popets-2020-0038. Proceedings on Privacy Enhancing Technologies 2020, 2 (April 2020), 499–518. doi:10.2478/popets-20200038 [32] Imane Fouad, Cristiana Santos, and Pierre Laperdrix. 2024. The Devil is in the Details: Detection, Measurement and Lawfulness of Server-Side Tracking on the Web. http://dx.doi.org/10.56553/popets-2024-0125. Proceedings on Privacy Enhancing Technologies 2024, 4 (Oct. 2024), 450–465. doi:10.56553/popets-20240125 [33] Ghostery, Inc. 2023. Ghostery TrackerDB. https://github.com/ghostery/ trackerdb. [34] Roberto Gonzalez, Lili Jiang, Mohamed Ahmed, Miriam Marciel, Ruben Cuevas, Hassan Metwalley, and Saverio Niccolini. 2017. The Cookie Recipe: Untangling the Use of Cookies in the Wild. https://doi.org/10.23919/TMA.2017.8002896. In Proceedings of the 1st Network Traffic Measurement and Analysis Conference (TMA 2017). IEEE, Washington, DC, USA, Article 1, 9 pages. doi:10.23919/TMA.2017. 8002896 [35] Google. 2020. Improve performance and security with server-side tagging. https://blog.google/products/marketingplatform/360/improve-performanceand-security-server-side-tagging/.

[36] Google Developers. 2025. Introduction to server-side tagging in Google Tag Manager. https://developers.google.com/tag-platform/tag-manager/serverside/intro. [37] Aric A. Hagberg, Daniel A. Schult, and Pieter J. Swart. 2008. Exploring Network Structure, Dynamics, and Function using NetworkX. http://conference.scipy. org.s3-website-us-east-1.amazonaws.com/proceedings/SciPy2008/paper_2/. In Proceedings of the 7th Python in Science Conference (SciPy 2008), Gaël Varoquaux, Travis Vaught, and Jarrod Millman (Eds.). 11 – 15. [38] Richard W. Hamming. 1950. Error Detecting and Error Correcting Codes. Bell System Technical Journal 29, 2 (1950), 147–160. doi:10.1002/j.1538-7305.1950. tb00463.x [39] Jiawei Han, Jian Pei, and Yiwen Yin. 2000. Mining frequent patterns without candidate generation. https://doi.org/10.1145/342009.335372. In Proceedings of the 2000 ACM SIGMOD International Conference on Management of Data (Dallas, Texas, USA) (SIGMOD ’00). Association for Computing Machinery, New York, NY, USA, 1–12. doi:10.1145/342009.335372 [40] Xuehui Hu, Nishanth Sastry, and Mainack Mondal. 2021. CCCC: Corralling Cookies into Categories with CookieMonster. https://doi.org/10.1145/3447535. 3462509. In Proceedings of the 13th ACM Web Science Conference 2021 (Virtual Event, United Kingdom) (WebSci ’21). Association for Computing Machinery, New York, NY, USA, 234–242. [41] Anders Jensen, Mads Mølgaard Kristensen, Thomas Tønnesen Schultz, Thomas Hildebrandt, and Michael Andersen. 2021. Consent-O-Matic. https://github. com/cavi-au/Consent-O-Matic. Browser extension for automatic GDPR consent management. Accessed: 2025-04-16. [42] JENTIS. 2024. How to find and implement the ideal server-side tracking solution. Technical Report. JENTIS GmbH. [43] JENTIS. 2025. Meta Signals Gateway: New strategic approach to server-side tracking. https://www.jentis.com/en/article/blog-meta-signals-gateway/. [44] Joel Järvinen and Heikki Karjaluoto. 2015. The use of Web analytics for digital marketing performance measurement. Industrial Marketing Management 50 (2015), 117–127. doi:10.1016/j.indmarman.2015.04.009 [45] Arjaldo Karaj, Sam Macbeth, Rémi Berson, and Josep M. Pujol. 2018. WhoTracks.Me: Shedding light on the opaque world of online tracking. arXiv:1804.08959 [cs.CY] [46] Mohammad Taha Khan, Joe DeBlasio, Geoffrey M. Voelker, Alex C. Snoeren, Chris Kanich, and Narseo Vallina-Rodriguez. 2018. An Empirical Analysis of the Commercial VPN Ecosystem. In Proceedings of the 2018 ACM SIGCOMM Internet Measurement Conference (IMC’18). ACMPress, New York, NY, USA, 15 pages. [47] Konrad Kollnig, Reuben Binns, Max Van Kleek, Ulrik Lyngs, Jun Zhao, Claudine Tinsman, and Nigel Shadbolt. 2021. Before and after GDPR: Tracking in mobile apps. https://doi.org/10.14763/2021.4.1611. Internet Policy Review 10, 4 (2021). doi:10.14763/2021.4.1611 [48] Martin Koop, Erik Tews, and Stefan Katzenbeisser. 2020. In-Depth Evaluation of Redirect Tracking and Link Usage. https://api.semanticscholar.org/CorpusID: 220531844. Proceedings on Privacy Enhancing Technologies 2020 (2020), 394 – 413. [49] Michael Kretschmer, Jan Pennekamp, and Klaus Wehrle. 2021. Cookie Banners and Privacy Policies: Measuring the Impact of the GDPR on the Web. https://doi.org/10.1145/3466722. ACM Trans. Web 15, 4, Article 20 (July 2021), 42 pages. doi:10.1145/3466722 [50] Benjamin Krumnow, Hugo Jonker, and Stefan Karsch. 2022. How gullible are web measurement tools? a case study analysing and strengthening OpenWPM’s reliability. https://doi.org/10.1145/3555050.3569131. In Proceedings of the 18th International Conference on Emerging Networking EXperiments and Technologies (Roma, Italy) (CoNEXT ’22). Association for Computing Machinery, New York, NY, USA, 171–186. doi:10.1145/3555050.3569131 [51] Victor Le Pochat, Tom Van Goethem, Samaneh Tajalizadehkhoob, Maciej Korczyński, and Wouter Joosen. 2019. Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation. In Proceedings of the 26th Annual Network and Distributed System Security Symposium (NDSS 2019). doi:10.14722/ndss. 2019.23386 [52] Alexander Lex, Nils Gehlenborg, Hendrik Strobelt, Romain Vuillemot, and Hanspeter Pfister. 2014. UpSet: Visualization of Intersecting Sets. IEEE Transactions on Visualization and Computer Graphics 20, 12 (2014), 1983–1992. doi:10.1109/TVCG.2014.2346248 [53] Zengrui Liu, Umar Iqbal, and Nitesh Saxena. 2024. Opted out, yet tracked: Are regulations enough to protect your privacy? Proc. Priv. Enhancing Technol. 2024, 1 (Jan. 2024), 280–299. [54] Gurmeet Singh Manku, Arvind Jain, and Anish Das Sarma. 2007. Detecting near-duplicates for web crawling. https://doi.org/10.1145/1242572.1242592. In WWW 07: Proceedings of the 16th international conference on World Wide Web (Banff, Alberta, Canada) (WWW ’07). Association for Computing Machinery, New York, NY, USA, 141–150. [55] Mozilla Foundation. 2025. Public Suffix List. https://publicsuffix.org/list/public_ suffix_list.dat. [56] Shaoor Munir, Sandra Siby, Umar Iqbal, Steven Englehardt, Zubair Shafiq, and Carmela Troncoso. 2023. CookieGraph: Artifact Repository. https://github.com/ cookiegraph/CookieGraph.

From Third-Party to First-Party: Measuring and Protecting Against Modern Web Tracking Mechanisms

[57] Shaoor Munir, Sandra Siby, Umar Iqbal, Steven Englehardt, Zubair Shafiq, and Carmela Troncoso. 2023. CookieGraph: Understanding and Detecting First-Party Tracking Cookies. https://doi.org/10.1145/3576915.3616586. In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (Copenhagen, Denmark) (CCS ’23). Association for Computing Machinery, New York, NY, USA, 3490–3504. doi:10.1145/3576915.3616586 [58] Trung Tin Nguyen, Michael Backes, and Ben Stock. 2022. Freely Given Consent? Studying Consent Notice of Third-Party Tracking and Its Violations of GDPR in Android Apps. https://doi.org/10.1145/3548606.3560564. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS ’22). ACM, New York, NY, USA, 2369–2383. doi:10.1145/3548606.3560564 [59] Pouneh Nikkhah Bahrami, Aurore Fass, and Zubair Shafiq. 2025. 𝐶𝑜𝑜𝑘𝑖𝑒𝐺𝑢𝑎𝑟𝑑 : Characterizing and Isolating the First-Party Cookie Jar. https://doi.org/10.1145/3730567.3764490. In Proceedings of the 2025 ACM Internet Measurement Conference (USA) (IMC ’25). Association for Computing Machinery, New York, NY, USA, 645–661. [60] NordVPN. 2025. NordVPN Official Website. https://nordvpn.com. [61] Midas Nouwens, Rolf Bagge, Janus Bager Kristensen, and Clemens Nylandsted Klokmose. 2022. Consent-O-Matic: Automatically Answering Consent Pop-ups Using Adversarial Interoperability. https://doi.org/10.1145/3491101.3519683. In Extended Abstracts of the 2022 CHI Conference on Human Factors in Computing Systems (New Orleans, LA, USA) (CHI EA ’22). Association for Computing Machinery, New York, NY, USA, Article 238, 7 pages. doi:10.1145/3491101.3519683 [62] Midas Nouwens, Janus Bager Kristensen, Kristjan Maalt, and Rolf Bagge. 2025. A Cross-Country Analysis of GDPR Cookie Banners and Flexible Methods For Scraping Them. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems (CHI ’25). Association for Computing Machinery, New York, NY, USA, Article 858, 28 pages. doi:10.1145/3706598.3713648 [63] OneTrust LLC. 2026. Cookiepedia – All You Need to Know About Cookies. https://cookiepedia.co.uk/. [64] Outis Nemo Ltd. . 2026. Akamai _abck Cookie. https://kameleo.io/glossary/ akamai-abck-cookie/. [65] PricewaterhouseCoopers and Interactive Advertising Bureau. 2024. Internet Advertising Revenue Report. https://www.iab.com/wp-content/uploads/2025/ 04/IAB_PwC-Internet-Ad-Revenue-Report-Full-Year-2024.pdf. [66] Christine Prince, Nessrine Omrani, and Francesco Schiavone. 2024. Online privacy literacy and users’ information privacy empowerment: the case of GDPR in Europe. https://doi.org/10.1108/ITP-05-2023-0467. Information Technology & People 37, 8 (01 2024), 1–24. arXiv:https://www.emerald.com/itp/articlepdf/37/8/1/9465373/itp-05-2023-0467.pdf doi:10.1108/ITP-05-2023-0467 [67] Jeremy Rack and Cristian-Alexandru Staicu. 2023. Jack-in-the-box: An Empirical Study of JavaScript Bundling on the Web and its Security Implications. https://doi. org/10.1145/3576915.3623140. In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (Copenhagen, Denmark) (CCS ’23). Association for Computing Machinery, New York, NY, USA, 3198–3212. doi:10. 1145/3576915.3623140 [68] Ali Rasaii, Ha Dao, Anja Feldmann, Mohammadmahdi Javid, Oliver Gasser, and Devashish Gosain. 2025. Intractable cookie crumbs: Unveiling the nexus of stateful banner interaction and tracking cookies. Proc. Priv. Enhancing Technol. 2025, 4 (Oct. 2025), 429–445. [69] J.W. Ratcliff and D.E. Metzener. 1988. Pattern Matching: The Gestalt Approach. Dr Dobbs Journal 13, 7 (1988). [70] Abbas Razaghpanah, Rishab Nithyanand, Narseo Vallina-Rodriguez, Srikanth Sundaresan, Mark Allman, Christian Kreibich, and Phillipa Gill. 2018. Apps, Trackers, Privacy, and Regulators: A Global Study of the Mobile Tracking Ecosystem. https://dspace.networks.imdea.org/handle/20.500.12761/507. In Proceedings of the 2018 Network and Distributed System Security Symposium (NDSS). Paper. [71] Cristiana Santos, Midas Nouwens, Michael Toth, Nataliia Bielova, and Vincent Roca. 2021. Consent Management Platforms Under the GDPR: Processors and/or Controllers?. In Privacy Technologies and Policy. Springer International Publishing, Cham, 47–69. [72] SIDN fonds. 2026. Cookiedatabase – Understanding tracking with Cookiedatabase.org. https://www.cookiedatabase.org/. [73] Michael Smith, Peter Snyder, Moritz Haller, Benjamin Livshits, Deian Stefan, and Hamed Haddadi. 2022. Blocked or Broken? Automatically Detecting When Privacy Interventions Break Websites. https://arxiv.org/abs/2203.03528. arXiv:2203.03528 [cs.CR] [74] Sadhan Sood and Dmitri Loguinov. 2011. Probabilistic near-duplicate detection using simhash. https://doi.org/10.1145/2063576.2063737. In Proceedings of the 20th ACM International Conference on Information and Knowledge Management (Glasgow, Scotland, UK) (CIKM ’11). Association for Computing Machinery, New York, NY, USA, 1117–1126. doi:10.1145/2063576.2063737 [75] TikTok Inc. 2025. TikTok Pixel Template for Google Tag Manager. https://github. com/tiktok/gtm-template-pixel. Official GitHub repository providing the TikTok Pixel Tag template for Google Tag Manager. Accessed: 2025-10-21.. [76] Md. Sharif Uddin, Chanchal K. Roy, Kevin A. Schneider, and Abram Hindle. 2011. On the Effectiveness of Simhash for Detecting Near-Miss Clones in Large Scale Software Systems. In 2011 18th Working Conference on Reverse Engineering. 13–22.

doi:10.1109/WCRE.2011.12 [77] Tobias Urban, Martin Degeling, Thorsten Holz, and Norbert Pohlmann. 2019. "Your hashed IP address: Ubuntu.": perspectives on transparency tools for online advertising. https://doi.org/10.1145/3359789.3359798. In Proceedings of the 35th Annual Computer Security Applications Conference (ACSAC), David M. Balenson (Ed.). ACM, 702–717. doi:10.1145/3359789.3359798 [78] Tobias Urban, Martin Degeling, Thorsten Holz, and Norbert Pohlmann. 2020. Beyond the Front Page: Measuring Third Party Dynamics in the Field. In International Conference on World Wide Web (TheWebConf). Association for Computing Machinery, New York, NY, USA, 1275–1286. doi:10.1145/3366423.3380203 [79] Tobias Urban, Dennis Tatang, Martin Degeling, Thorsten Holz, and Norbert Pohlmann. 2020. Measuring the Impact of the GDPR on Data Sharing in Ad Networks. https://doi.org/10.1145/3320269.3372194. In Proceedings of the 15th ACM Asia Conference on Computer and Communications Security (ASIA CCS ’20). ACM, New York, NY, USA, 222–235. doi:10.1145/3320269.3372194 [80] Christine Utz, Martin Degeling, Sascha Fahl, Florian Schaub, and Thorsten Holz. 2019. (Un)informed Consent: Studying GDPR Consent Notices in the Field. https://doi.org/doi/10.1145/3319535.3354212. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS ’19). ACM, New York, NY, USA, 973–990. doi:10.1145/3319535.3354212 [81] Yash Vekaria, Benjamin Standaert, Max Ostapenko, Abdul Haddi Amjad, Yana Dimova, Shaoor Munir, Chris Böttger, Umar Iqbal, Alberto Fernandez-de Retana, and Barry Pollard. 2024. Privacy. HTTP Archive, Chapter 12. doi:10.5281/zenodo. 14261510 [82] Web Almanac. 2024. The 2024 Web Almanac: A Comprehensive Report on the State of the Web. https://almanac.httparchive.org/en/2024/.

A

Open Science

To foster future research, we publish our analysis code, measurement data, data processing pipeline, and other supplementary information online at: https://github.com/internet-sicherheit/FromThird-Party-to-First-Party-Measuring-and-Protecting-Against-ModernWeb-Tracking-Mechanisms. A detailed description of how to use the developed tools to reproduce the analysis and rerun the crawling is available in the anonymous repository (see the README.md file).

B

Ethical Considerations

As with all large-scale Web measurement studies, our study faces ethical challenges that must be considered. By running our crawler, we generate traffic and utilize resources, particularly those of the hosting parties for the analyzed sites (e.g., energy), which could be used otherwise. Furthermore, the visited page might serve ads to our crawler, thereby consuming some of the advertiser’s ad budget. Since each crawler visits each page only once, we assume these issues are minor and are widely accepted within the Web measurement community.

C

Overview of the Top 5 Clusters in the Ecosystem

Figure 6 shows a graph of the top 5 clusters by site data. It is notable that we perform analysis on the complete graph but choose a subgraph for visualization. Therefore, we utilize the Python NetworkX library [37] to build the network graph. The figure shows the top five clusters and all the cookies associated with them. We define a node as a cookie (red dots) or cluster (gray dots). Edges (blue lines) between cookies and clusters represent whether a cookie is used by a script in a cluster.

Christian Böttger, Tareq Khouja, Norbert Pohlmann, Nurullah Demir, and Tobias Urban

Figure 6: Network graph of the top 5 clusters by site data. Red dots represent cookies, and edges represent whether a cookie is used by a cluster (grey dots).

D

Overview of the Heuristic Tests for Tracking Cookies

In Table 4, we provide an overview of the cookies we tested using the heuristic introduced in Section 3.2, and indicate at which step each cookie failed to meet the criteria for a tracking cookie. In these explorative tests, the heuristic did not flag any non-tracking cookies as tracking in the set of cookies we used to evaluate. Further, it did not flag the s_v_web_id cookie (which is only valid for a session), as it is used to identify videos a user has seen, according to its description [12]. Thus, we assume that our approach provides a lower bound. To validate the heuristic, we manually analyze the top 15 cookies identified by the heuristic to determine whether they are or could be used for user tracking; Table 5 shows the top 10 of these. For testing classification, we relied on sources such as Cookiepedia [63], Cookiedatabase [72], and general Internet searches. Of the top ten cookies, six are directly related to tracking or analytics services and are therefore correctly classified. For the other four (depicted with ❉ in Table 5), a more detailed analysis is needed, as they are not only used for tracking. The cookie _abck is primarily used by Akamai for bot detection, but it is also used for user tracking and analytics services [10, 64]. OptanonConsent is used by OneTrust to store users’ consent preferences. Various studies show that such consent management platform (CMP) providers can act as crosssite trackers, tracking users’ choices across the Web [53, 62, 68, 71]. Amazon Web Services uses the cookie AWSALB primarily to enable load balancing. Yet, a primary use case of the cookie is to store session data locally on a specific server (here, AWS instance) rather than in a shared database. While technically not always linked to user tracking, it enables user tracking when scaling an application horizontally. Due to an encrypted value that increases entropy and due to “sticky sessions” (i.e., long expired times), the cookie passes the heuristic checks. Finally, PHPSESSID is a configurable cookie commonly used by PHP frameworks to store session IDs,

which are not a form of user tracking that we are interested in. However, when manually inspecting the cookies flagged by the heuristic, we noticed that the applications set the cookie’s lifetime to “infinity” (i.e., 9999-12-31 23:59:59 UTC; the maximum value in the YYYY-MM-DD format). An infinite session can be used for user tracking. We consider the last two cases as edge cases (probable false positives). To further validate the heuristic, we tested the distinct cookies identified in our clusters against Cookiepedia classifications. Of the 3,378 distinct cluster cookies, 1,829 (54%) could not be classified by the database. About 262 (8%) are classified as “Targeting/Advertising”. By looking into the remaining 38% of the cookies, we need to evaluate the heuristic. Those 38% are distributed to “Performance” (805, 24%), “Strictly Necessary” (266, 8%), and “Functionality” (217, 6%). Which leads to a 14% false-positive rate. As we learned from related work, some “Performance” cookies (e.g., _ga) can be used for tracking [8]. An extended evaluation covering 100 sampled cookies is available in our repository (see Appendix A).

From Third-Party to First-Party: Measuring and Protecting Against Modern Web Tracking Mechanisms

Cookie Name

Lifetime

Purpose

Provider

1

Criteria 2 3 4

_ga NID SSID _gat _gid

2 years 6 months 2 years session 24 hours

Performance: used to distinguish unique users Targeting/Advertising: optimize targeted ad Targeting/Advertising: info on ads seen by the user Performance: bot detection Performance: Used to distinguish users

Google Google Google Google Google

✓ ✓ ✓ ✗ ✓

✓ ✓ ✓ — ✓

✓ ✓ ✓ — ✓

✓ ✓ ✗ — ✓

✓ ✓ ✗ ✗ ✓

_fbp xs fr

90 days session 90 days

Targeting/Advertising: track visits across websites Targeting/Advertising: unique session ID Targeting/Advertising: ad delivery or retargeting

Meta Meta Meta

✓ ✗ ✓

✓ — ✓

✓ — ✓

✓ — ✓

✓ ✗ ✓

ttwid s_v_web_id

1 year session

Targeting/Advertising: track user content interaction Targeting/Advertising: identify videos seen by the user

TikTok TikTok

✓ ✗

✓ —

✓ —

✓ —

✓ ✗

mbox AMCV s_fid s_vi demdex

30 minutes 2 years 2 years 2 years 6 months

Functionality: Session ID, ID for browser Targeting/Advertising: Unique identifier Performance: contains a unique id Performance: contains a unique ID and timestamp Targeting/Advertising: Identification, ID synchronization

Adobe Adobe Adobe Adobe Adobe

✓ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓ ✗

✓ ✓ ✓ ✓ —

✓ ✓ ✓ ✓ ✗

Result

Table 4: Overview of the test to verify if the heuristic correctly identifies known first-party tracking cookies. Criteria 1: Longevity, 2: Length, 3: Uniqueness, 4: Similarity.

No.

Cookie Name

1 2 3 4 5 6 7 8 9 10

_gcl_au _ga _abck __smn_fid AMCV OptanonConsent AWSALB _vwo_uuid_v2 _fbp PHPSESSID

Clusters

1st Party

3rd Party

5,102 4,907 2,262 1,671 1,601 1,506 1,108 1,077 972 860

1,417,269 1,365,268 1,195,751 1,791 1,228,951 1,251,312 1,192,422 1,262,926 1,203,112 1,201,277

54,447 49,366 29,706 0 33,951 22,862 20,959 28,539 20,419 18,874

Attributed to Google Google Akamai Ladsp Adobe OneTrust Amazon Web Services Visual Website Optimizer Meta (Facebook) Unknown

Tracking ✓ ✓ ❉ ✓ ✓ ❉ ❉ ✓ ✓ ❉

Purpose Analytics Performance Bot detection Targeting Targeting Consent mgnt Load balancing Analytics Targeting Session mgnt

Table 5: Top 10 cookies by their occurrence in the clusters. ❉ indicates that tracking is not the primary purpose of the cookie, but using it for tracking is possible.