CookieGraph: Understanding and Detecting First-Party Tracking Cookies

As third-party cookie blocking is becoming the norm in mainstream web browsers, advertisers and trackers have started to use first-party cookies for tracking. To understand this phenomenon, we conduct a differential measurement study with versus without third-party cookies. We find that first-party cookies are used to store and exfiltrate identifiers to known trackers even when third-party cookies are blocked. As opposed to third-party cookie blocking, first-party cookie blocking is not practical because it would result in major breakage of website functionality. We propose CookieGraph, a machine learning-based approach that can accurately and robustly detect and block first-party tracking cookies. CookieGraph detects first-party tracking cookies with 90.18% accuracy, outperforming the state-of-the-art CookieBlock by 17.31%. We show that CookieGraph is robust against cookie name manipulation, while CookieBlock's accuracy drops by 15.87%. While blocking all first-party cookies results in major breakage on 32% of the sites with SSO logins, and CookieBlock reduces it to 10%, we show that CookieGraph does not cause any major breakage on these sites. Our deployment of CookieGraph shows that first-party tracking cookies are used on 89.86% of the top-million websites. We find that 96.61% of these first-party tracking cookies are in fact ghostwritten by third-party scripts embedded in the first-party context. We also find evidence of first-party tracking cookies being set by fingerprinting scripts. The most prevalent first-party tracking cookies are set by major advertising entities such as Google, Facebook, and TikTok.


INTRODUCTION
Major browser vendors such as Safari, Firefox, and Google Chrome have either blocked or are in the process of blocking third-party cookies -cookies set on domains that differ from the domain of the site visited by a user [25,82,91].Because third-party cookies are accessible across different sites that a user visits, they are used for cross-site tracking (i.e., linking a user's browsing activity across different sites).Due to their ubiquitous use in tracking, the question arises as to how trackers will respond to third-party cookie blocking.First-party cookies -cookies that are set on the same domain as that being visited by a user -are of particular interest to advertisers and trackers because they will still be available in the face of thirdparty cookie blocking.However, since first-party cookies are only accessible from the setting domain, it remains to be seen how they can be used in lieu of third-party cookies for cross-site tracking.
Prior literature has shown that first-party cookies set by thirdparty scripts can be exfiltrated to tracking endpoints [44,54,77].Prior work has also shown that trackers use browser fingerprinting to re-spawn first-party cookies [55].Yet, there is no work studying the full spectrum of tracking possible through first-party cookies; and crucially, no countermeasures exist to specifically detect and block first-party tracking cookies.To fill this gap, we first investigate the use of first-party cookies by known trackers and then use our findings to develop a machine-learning based approach, CookieGraph, to detect and block first-party tracking cookies.
We first perform a differential measurement study comparing the use of first-and third-party cookies on a 20% sample of topmillion websites across parallel crawls, with third-party cookies enabled and blocked.We show that third-party cookie blocking does not significantly impact the sharing of identifiers to known tracking endpoints because major trackers are already using firstparty cookies.Our analysis reveals that these trackers store identifiers in first-party cookies based on probabilistic and deterministic information.
Unlike third-party cookies, blocking all first-party cookies is not practical, as some of these cookies might be required for legitimate website functionality.An alternative could be the use of privacy-enhancing request blocking tools [62,79,80] that would also block the cookies set by the requested resources.Unfortunately, our evaluation shows that these tools also cause breakage because tracking cookies are often set by domains that also set functional cookies.Researchers have recently started to develop approaches to detect and block (both first-party and third-party) tracking cookies [42,59].However, these approaches rely on content-based features such as cookie names and values, which can lead to a high number of false positives (and consequently major website breakage) while also being susceptible to evasion [79].
To address these limitations, we design and implement Cook-ieGraph, a machine-learning approach to specifically detect firstparty tracking cookies.Instead of using content-based features, CookieGraph attempts to capture fundamental tracking behaviors exhibited by first-party cookies that we discover in our differential measurement study.CookieGraph is able to detect first-party tracking cookies with 90.18% accuracy, outperforming the state-ofthe-art CookieBlock [42] by 17.31%.We also show that blocking all first-party cookies results in major breakage on 32% of the sites with SSO logins, which is improved to 10% by CookieBlock.In contrast, CookieGraph does not cause any major breakage on these sites.Moreover, CookieGraph is robust to evasion through cookie name manipulation, while CookieBlock's accuracy degrades by 15.87%.
We deploy CookieGraph on a 20% sample of the top-million websites to find 108,947 first-party tracking cookies on 89.86% of the websites.The most prevalent first-party tracking cookies are set by major advertising entities, such as Google, Facebook, and TikTok, and then exfiltrated to a large number of other advertising and tracking endpoints.We find that 96.61% of the first-party tracking cookies are in fact ghostwritten by third-party scripts, 223 of which also conduct fingerprinting, that are served from a total of 2,099 distinct third-party domains.
In summary, our key contributions are as follows: (1) We conduct a large-scale differential measurement study to understand the usage of first-party cookies by trackers when third-party cookies are blocked.Our analysis shows that blocking third-party cookies does not reduce the number of tracking requests containing identifiers and provides evidence that trackers already use first-party cookies in lieu of third-party cookies for tracking.(2) We introduce CookieGraph, a machine-learning based countermeasure to detect and block first-party tracking cookies.CookieGraph captures fundamental tracking behaviors of first-party cookies that.CookieGraphoutperforms the state-of-the-art in terms of accuracy, robustness, and breakage minimization.(3) We deploy CookieGraph on a 20% sample of the topmillion websites to measure the prevalence of first-party tracking cookies.We detect a total of 2,099 distinct domains that set first-party tracking cookies, including major advertising entities such as Google, and show that fingerprinting scripts set first-party cookies on 1,908 sites.
Paper Organization: The rest of this paper is organized as follows: Section 2 provides an overview of the recent developments and related work on cookies.Section 3 describes the threat model of first-party cookies.Section 4 presents our differential measurement study to evaluate the impact of third-party cookie blocking on the use of first-party cookies by trackers.Section 5 describes the design and evaluation of CookieGraph.Section 6 presents results from our deployment of CookieGraph.We discuss the limitations of CookieGraph in Section 7 and conclude in Section 8.

BACKGROUND & RELATED WORK 2.1 Adoption of third-party cookies for tracking
Cookies were originally designed to recognize returning users, e.g., to maintain virtual shopping carts [70].Soon, they were adopted by third-parties to track users across websites and serve targeted ads [7].Early standardization efforts focused on limiting unintended cookie sharing across domains [47] and, despite well-known privacy concerns [1], largely ignored the misuse of cookies by third-parties for cross-site tracking.Over the years, the use of third-party cookies for cross-site tracking has become prevalent [43,48,76,77].Prior research shows that the vast majority of third-party cookies are set by advertising and tracking services (ATS) [48] and third-party cookies outnumber first-party cookies by a factor of two [43] -and up to four when they contain identifiers [77].[25].Partitioning ensures that cookies set by a third party on one site are distinct from those set by the same third-party on other websites, eliminating the third party's ability to track users across those websites.

Internet Explorer and Microsoft
Edge.Amongst the mainstream browsers that have deployed countermeasures against thirdparty cookies, Internet Explorer (IE) and Microsoft Edge have the most permissive protections.IE blocked third-party cookies from domains that did not specify their cookie usage policy with the P3P response header [2].However, website owners often misrepresented their own cookie usage policies, which rendered P3P ineffective [68].Since 2019, Microsoft Edge has blocked access to cookies and storage in a third-party context from some trackers, based on Disconnect's tracking protection list [6, 15, 82].

2.2.4
Chrome.Google Chrome is the only mainstream browser that does not restrict third-party cookies in any way in its default mode.In 2020, Google announced plans to phase out third-party cookies in Chrome by 2022 [78].However, the plan has been postponed several times and the latest timeline suggests the phasing out of cookies by late 2024 [56].

Adoption of first-party cookies for tracking
While third-party cookies are widely considered as the main mechanism for cross-site tracking, trackers have also relied on first-party cookies for various forms of tracking, as described below.
Same-site tracking.As early as 2012, Roesner et al. [76], noted that third-party tracking scripts, embedded on the main webpage (i.e., in first-party context), set first-party cookies.First-party cookies enable same-site tracking, where trackers can determine whether a user is revisiting a website or internal pages of a site.While not as invasive as tracking users across different sites, significant information about a user can be gleaned from tracking their activity on the sites they frequent (e.g., a social media or news site).
Cross-domain same-site tracking.First-party cookies can also be used for cross-domain same-site tracking, where a website's cookies are shared by trackers to other domains.In 2020, Fouad et al. [54] found that trackers sync first-party cookies to several third-parties on as many as 67.96% of the websites they tested.In 2021, Chen et al. [44] found that more than 90% of the websites contain at least one first-party cookie that is set by a third-party script.Similar to Fouad et al., they found that at least one first-party cookie is exfiltrated to a third-party domain on more than half of the tested websites, raising concerns that these cookies might be used for tracking.Sanchez et al. [77] echoed these concerns, uncovering several instances where first-party cookies were ghostwritten by third-parties and then exfiltrated to other third-parties.They conclude, through a largescale measurement study of top websites and multiple case studies, that even after blocking third-party cookies, users are still at risk of first-party cookie based tracking.
Cross-domain sharing of first-party cookies presents a bigger privacy issue for users than same-site tracking.While same-site tracking is only restricted to domains that are able to set first-party cookies, cross-domain sharing of first-party cookies allows other trackers, which are not collaborating with the first-party domains, to receive information about user activity.This simplifies operations for trackers as instead of collaborating with each different publisher to set first-party cookies, they can instead leverage tracking cookies set by another tracker to monitor user activity.With this practice, not only the third-party domains that are setting first-party cookies can track users' activities on the site, but tracking is also extended to other domains that receive these first-party cookies.
Cross-site tracking.While third-party cookies have been used extensively in cross-site tracking, i.e., where a tracker links a user's activity across sites, the mechanisms by which first-party cookies are used in cross-site tracking have not been studied so far.Oh et al. [72] investigated the sharing of first-party data with trackers in lieu of third-party cookie blockage, determining that identifiers such as email addresses were also shared to popular trackers.Their experiments show that trackers make use of identifiers like email addresses to link user activity across different sites.They make use of this knowledge to perform identity entanglement, where an attacker can make use of an email address or other identifiers to influence the advertisements shown to a victim.This sharing of additional information when third-party cookies are blocked allows trackers to track users across different sites.
Previous research has also shown that it is non-trivial to generate first-party identifiers that are accessible across websites.Prior research has found that trackers often leverage browser fingerprinting to generate first-party tracking cookies [55].Browser fingerprinting provides unique identifiers that are accessible across websites but drift over time [65].However, identifiers generated through browser fingerprinting can be stored in cookies that persist even after fingerprints change.In addition to browser fingerprinting, several advertising and tracking services, such as Google Ad Manager [20] and ID5 [29], specify in their documentation that they also use publisher-provided identifiers (PPIDs), such as email addresses, to set first-party cookies.
We note that techniques such as CNAME cloaking also allow advertisers and trackers to use first-party cookies.However, as prior work has extensively studied first-party cookie leaks due to CNAME cloaking, we do not focus on CNAME cloaking in this paper.

Countermeasures against first-party cookies
2.4.1 Deployed countermeasures.Safari is the only mainstream browser that has deployed protections against first-party tracking cookies.Safari's ITP expires first-party cookies and storage set by scripts in 7 days if users do not interact with the website [84].This limit is lowered to 24 hours if ITP detects link decoration being used for tracking [84].However, first-party cookie tracking does not require link decoration to be effective.In cases where link decoration is not used, trackers can still track users within the 7-day window and beyond if users interact with the website within the 7-day window.

Countermeasures proposed by prior research.
There exist two machine-learning based approaches to detect tracking cookies.Hu et al. [59]'s approach uses sub-strings in cookie names (e.g., track, GDPR) as features to detect first-party and third-party tracking cookies.Bollinger et al. [42] proposed CookieBlock.CookieBlock uses several cookie attributes such as the domain name of the setter, cookie name, path, value, expiration, etc. as features to detect first-party and third-party tracking cookies.These approaches rely on hard-coded content features, which makes them susceptible to adversarial evasions (as we show later in Section 5.5.3).Moreover, these approaches mainly rely on self-disclosed cookie labels as ground truth, which can be unreliable [83].

Request blocking approaches.
Request blocking through browser extensions, such as Adblock Plus [3], and machine-learning-based tracker detection approaches proposed by prior research, e.g., [79], can block first-party cookies set by tracking requests.However, request blocking is prone to cause breakage because it blocks access to content or cookies that might be essential for website functionality.We confirm this is the case in Section 5.5.3)Unique focus of this paper.Prior work has only incidentally measured the usage of first-party tracking cookies, and existing approaches to detect first-party tracking cookies are lacking.In this paper, we fill this void by conducting a large-scale study to measure the prevalence of first-party tracking cookies and develop an accurate and robust machine-learning approach, CookieGraph, aimed at detecting first-party cookies.

THREAT MODEL
In this section, we describe the threat model of tracking via firstparty cookies. 1   First-vs third-party cookies.Before describing the threat model, we define what we mean by first-and third-party cookies.Cookies can either be set by the Set-Cookie HTTP response header or by using document.cookiein JavaScript.Cookies set via response header from the same domain as the first-party are first-party cookies.Similarly, cookies set via response header from a different domain than the first-party are third-party cookies.When cookies are set by a script, their classification depends on whether the script is embedded in a first-or third-party execution context.The cookies set by third-party scripts running in the first-party context are firstparty cookies.The cookies set by third-party scripts running in a third-party context (e.g., third-party iframes) are third-party cookies.There are three main entities in this threat model: users (the victim), trackers (the adversary), and publishers.
We assume that the user: • visits different websites using one or more desktop/mobile devices that have distinct fingerprints [64] • is not averse to logging in to those websites and providing PII (personally identifiable information) such as email addresses • has third-party cookies disabled and first-party cookies enabled We assume that the publisher: • controls the content on the site being visited by the user • embeds the tracker in the first-party context, allowing the tracker to set first-party cookies • shares email and other deterministic identifiers (e.g., username, phone number) with the tracker, if provided by the user We assume that the tracker: • is present in a first-party context on the publisher's site • can set and read first-party cookies using document.cookie• can collect information such as IP addresses, screen resolution etc., which can be used to construct a device fingerprint Trackers can use the information shared by the publisher, and the fingerprints collected by their own scripts to perform same-site, cross-domain same-site, and cross-site tracking, described below: 1 This threat model is informed by prior literature [44,54,55,72,77] and our case studies of popular tracking services described in Appendix A.1 Initially, the user visits publishers 1 and 2 from one device.Tracker A, on publishers 1 and 2, collects and sends fingerprint  to the identity graph.The identity graph returns a   for all the publisher visits, by matching fingerprints sent by each respective publisher.A publisher-provided ID, , is also sent when visiting publisher 2. The user visits publisher 3 on a different device, thus tracker A is unable to construct a fingerprint that matches  .Publisher 3 sends a publisher-provided ID that matches  provided by publisher 2. As a result, the identity graph matches and returns the same   for publisher 3.This ID is stored in first-party cookies on the user's device for each respective publisher.
Same-site tracking.A user visits the same publisher's site multiple times.During the first visit of the user, tracker A sets a first-party cookie on the user's device.Upon subsequent visits by the user, tracker A can read the first-party cookie set and know that it is the same user who is revisiting the site.When performing same-site tracking, tracker A is able to gather information about the user across the pages maintained by the same publisher.
Same-site cross-domain tracking.After setting a first-party cookie on a user's device, tracker A also shares the first-party cookie with a different tracker B that is not present in the firstparty context (and thus is unable to set a first-party cookie of its own).On each subsequent visit of the user, tracker A shares the first-party cookie and the pages visited by the user with tracker B. Thus, without setting its own first-party cookie and directly colluding with the publisher, tracker B is also able to track the user's activity on the same site.
Cross-site tracking.Consider a scenario in which a user visits three different sites (publishers 1, 2, 3) where tracker A is embedded in the first-party context.The user visits sites 1 and 2 on one device and site 3 on a different device.Publishers 2 and 3 ask the user for a deterministic identifier (e.g., email address) which we denote as  (Publisher-Provided ID).Tracker A also constructs fingerprints on sites 1 and 2, denoted by   , where  denotes the publisher visited.
When the user visits sites 1 and 2, tracker A collects fingerprints  1 and  2 , which are the same (i.e.,  1 =  2 =  ) as they are all constructed for the same device.This allows tracker A to infer that the same user/device is visiting both sites.Tracker A links the deterministic identifiers and fingerprints belonging to the same user/device by constructing an identity graph (refer to Appendix A.1 for examples).The gray edge in Figure 1 shows the link in the identity graph constructed by tracker A for the fingerprints on sites 1 and 2.
The user then visits site 3 from a different device where tracker A is not able to construct the same fingerprint  .Publisher 3 asks the user for a deterministic identifier (e.g., email address), which is the same as the   provided by the user to publisher 2. Based on this additional information, tracker A can add a black edge to the identity graph.
Tracker A is finally able to connect all nodes in the identity graph to the user.Tracker A then assigns all connected nodes in the identity graph the same ID  , which it can store in a first-party cookie on each of the sites.On each subsequent visit by the user to any of the sites, tracker A can now simply read the first-party cookie containing  .Because   is the same across sites 1, 2, and 3, this allows tracker A to track the user across different sites.

MEASUREMENTS
In this section, we conduct a preliminary measurement study to investigate the usage of first-party cookies by advertising and tracking services (ATS) when third-party cookies are blocked.

Data Collection
Data collection.We use OpenWPM (v0.17.0) and Firefox (v102) [52] to crawl a sample of 20K out of the top-million websites.To ensure that our crawls cover websites of variable popularity, we crawl the top 1K sites -ensuring coverage of the most popular websites-uniformly sample 9K sites from the sites ranked 1K-100K, and another 10K from sites ranked 100k-1M in the Tranco list [74].To capture behaviors that may be different in the landing and internal pages of a website [40], we perform an interactive crawl that covers both kinds of pages.Specifically, for each site, we crawl its landing page and then select up to 20 internal pages to visit at random.We conduct four parallel crawls: two with third-party cookies enabled (3P-Allowed) and two with third-party cookies blocked (3P-Blocked).Parallelizing the crawls minimizes temporal variations across crawls and mitigates the effect of the dynamic behavior of websites.
We also turn off additional protections against tracking provided by Firefox [10].We repeat failed crawls up to four times.We successfully conducted the four parallel crawls for 99.31% of the 20K websites.
Labeling tracking activity.To label tracking, we use EasyList [8] and EasyPrivacy [9].Specifically, we use them to label requests as tracking (ATS) or not tracking (Non-ATS).We label a request as tracking (ATS) if its URL matches the rules in either one of the lists.Otherwise, we label it as not tracking (Non-ATS).
Since the basic premise of tracking is to identify users, we are particularly interested in sharing of identifiers in these tracking requests.In line with prior work [53,63], we define identifiers as a string that is longer than 8 characters and matches the regex Using this definition, we look for identifiers in URL query parameters [75] and cookie values [43,44,49,77].

Tracking When Third-Party Cookies Are Blocked
We first study whether blocking third-party cookies effectively eliminates ATS requests.We compare the number of requests containing identifiers with and without third-party cookies.Table 1 shows the average number of requests for two parallel crawls conducted with third-party cookies allowed and blocked.We see that there is only a modest reduction in the overall number of ATS requests when third-party cookies are blocked.The difference in the number of ATS requests containing identifiers is 10.82%.This is surprising because cookie syncing, which is widely used for samesite-cross-domain and cross-site tracking [54,73], entails sharing third-party identifier cookies in query parameters [43,44,49].With third-party cookies blocked, cookie syncing between third-parties cannot occur, and we would expect to see a larger drop in identifiers shared in ATS requests.We conclude that third-party cookie blocking does not effectively limit the exfiltration of identifiers to trackers.) first-party identifier cookies set when third-party cookies are blocked ( ) third-party identifier cookies set when third-party cookies are allowed Next, we analyze whether third-party cookie blocking disparately impacts different ATS domains (eTLD+1).Figure 2 plots the percentage of sites with at least one ATS request with identifiers.Six of the top-10 ATS domains, all owned by Google, show only a negligible reduction in the number of ATS requests with identifiers when third-party cookies are blocked.In contrast, three other ATS domains, owned by Pubmatic, Rubicon, and OpenX, show a significant reduction.

Tracking Through First-Party Cookies
Table 1 shows that even after blocking third-party cookies, there is only a small decrease in ATS requests containing identifiers (10.82%).The identifiers in these ATS requests are likely originating from some storage mechanism other than third-party cookies.Since recent prior work has shown that ATS are increasingly using first-party cookies [44,77], we next investigate whether first-party cookies are being used in lieu of third-party cookies to circumvent third-party cookie blockage.
We first compare the average number of first-party cookies in 3P-Allowed and 3P-Blocked crawls in Table 2.We observe only a minor difference in the average number of first-party cookies set with third-party cookies allowed/blocked.It is also noteworthy that 83.15% of the first-party cookies are set by ATS scripts.A further 57.94% of them are identifier cookies.We conclude that the vast majority of first-party cookies are in fact set by ATS and that they are not significantly impacted by third-party cookie blocking.
Next, we compare the setting of first-and third-party identifier cookies by ATS domains (eTLD+1 of the setting script URL) to understand if first-party cookie usage is equally prevalent across different ATSes.Figure 3 plots the percentage of sites where at least one first-party and/or third-party identifier cookie is set by a top-10 ATS domain.
For the six Google-owned ATS domains, which showed a negligible difference in requests containing identifiers after blocking third-party cookies, there is also little to no change in the use of firstparty identifier cookies across both crawls.Two of these domains (doubleclick.netand google.com)set a large number of third-party cookies, while the remaining four (google-analytics.com,googletagmanager.com,googlesyndication.com, and googleadservices.com)do not.We show in section 6 that the former two domains are a popular syncing endpoint for first-party cookies set by the other ATS domains, which explains their resilience to third-party cookie blocking.
On the contrary, the other set of ATS domains for which we observe a reduction of identifiers (i.e., Pubmatic, Rubicon, and OpenX) do use more third-party identifier cookies than first-party identifier cookies when third-party cookies are authorized.This observation also explains the drastic drop in the number of requests containing identifiers to these other ATS domains after blocking third-party cookies in Figure 2. We conclude that trackers that are not affected by third-party cookie blocking are using first-party cookies as a replacement.

Takeaway
Our differential measurement study reveals that third-party cookie blocking does not effectively prevent tracking.There is only a negligible reduction in the exfiltration of identifiers to trackers when third-party cookies are blocked.We find that this is because ATSes use first-party cookies in lieu of third-party cookies.
We also find that the impact of third-party cookie blocking is not uniform across different trackers.Some ATS domains show more reduction in the exfiltration of identifiers than others.This disparity exists because some trackers only use first-party cookies regardless of the availability of third-party cookies; while others are using both first-party and third-party cookies to store identifiers.

COOKIEGRAPH: DETECTING FIRST-PARTY TRACKING COOKIES
In this section, we describe CookieGraph, a graph-based machine learning approach to detect first-party ATS cookies.CookieGraph creates a graph representation of a webpage's execution based on HTML, network, JavaScript, and storage information collected

Design and Implementation
Browser instrumentation.CookieGraph uses our extended version of OpenWPM [52] to capture webpage execution information across HTML, network, JavaScript, and the storage layers of a webpage.Our analysis reveals significant usage of localStorage in addition to cookies.In total, we found 217,444 unique first-party cookie names and 99,682 unique localStorage names.In addition to this, we found 13,571 instances where the same first-party cookie was also stored in local storage.Thus, we use the term "storage" to refer to both cookies and localStorage.In most cases, the description for cookies is also applicable to localStorage and vice versa.
CookieGraph captures HTML elements created by scripts, network requests sent by HTML elements (as they are parsed) and scripts, responses received by the browser, exfiltration/infiltration of identifiers in network requests/responses, and read/write operations on the browser's storage mechanisms.
Graph construction.The nodes in CookieGraph's graph represent HTML elements, network requests, scripts, and storage elements.When localStorage and first-party cookie nodes share the exact same name, CookieGraph considers them as one storage node.CookieGraph's edges represent a wide range of interactions among different types of nodes e.g., scripts sending HTTP requests, scripts setting cookies etc.In addition to interactions considered by prior work [79], CookieGraph incorporates edges that model the actions associated to tracking using first-party cookies.We identify these actions from the result of our measurement study in Section 4, and the case studies described in Appendix A. In this example, a third-party script from tracker1.comexecutes in a first-party context on the webpage, example.com.The script first reads infoCookie (1), which contains tracking information such as the publisher ID and a user signature.Then, the script sends the content of the cookie to tracker1.com'ssync endpoint via an HTTP POST request (2).The endpoint returns a user ID (UID) in the response body (3), which is stored in both a first-party cookie and localStorage named IDStore (4).At a later point, the script reads the value from IDStore (5) and exfiltrates the UID to two other tracking endpoints: to tracker2.comvia a URL parameter (6) and to tracker3.comvia an HTTP header (7).
Figure 6 shows the graph representation that CookieGraph generates for the execution of the example script.The nodes in the graph represent the script, the storage, and the network endpoints.The edge numbers show the actions performed in Figure 5.The dotted and dashed lines in the graph show the infiltration and exfiltration behaviors captured by CookieGraph.CookieGraph is not only able to capture the interactions of the script with the storage and the network endpoints, but is also able to precisely link exfiltration and infiltration of the first-party cookie via an edge from the cookie node to the endpoint.

Feature extraction. We use CookieGraph's representation to extract two kinds of features.
Structural features represent relationships between nodes in the graph, such as ancestry information and connectivity.Structural features capture the relationships between the first-party cookie nodes and scripts on the page.For example, how many scripts interacted with a cookie or whether a script that interacted with a cookie also interacted with other cookies.
Flow features represent first-party ATS cookie behavior.We extract three types of flow features.First, we count the number of   times a cookie was read or written.Second, we count the number of times a cookie was infiltrated via HTTP responses or exfiltrated via URL parameters, request headers, or request bodies.Third, features related to the setter of the cookie.Concretely, whether the setter's domain also acted as an end-point for other cookie exfiltrations, and whether the setter's domain was involved in redirect chains (since redirects are commonly used in tracking).The intuition behind the third category of features is that domains involved in setting first-party ATS cookies are also involved in sharing information with other ATSes.
CookieGraph does not use content features, such as cookie names, as they can be trivially modified to evade detection [63,79].

Evaluation
Similar to previous work on graph-based webpage modelling [62,79], we use a random forest classifier to distinguish between ATS and Non-ATS cookies.We first train and test the accuracy of this classifier on a carefully labeled dataset.Then, we deploy it on our 20K website dataset.

Ground truth labeling.
We use two complementary approaches to construct our ground truth for first-party ATS cookies.We represent each first-party cookie as a cookie-domain pair since the same cookie name can occur on multiple sites.
Filter lists.We rely on filter lists [8, 9] as previous work has found them to be reasonably reliable in detecting ATS endpoints [62,79].Filter lists are designed to label resource URLs, rather than cookies.We adapt them to label cookies by assigning the label of a particular resource to all the cookies set by that resource.Since both ATS and Non-ATS cookies can be set by the same resource, this labeling procedure could result in a non-trivial number of false positives.To limit the number of false positives in our ground truth, we only label Non-ATS cookies based on filter lists: i.e., if a script that sets a cookie is not marked by any of the filter lists, we label these cookies as Non-ATS.Conservatively, if any one of the filter lists marks the cookie's setter as ATS, we label the cookie as Unknown.
Cookiepedia.Inspired by prior work [42], we use Cookiepedia [14] as an additional source of cookie labels.Cookiepedia is a database of cookies maintained by a well-known Consent Management Platform (CMP) called OneTrust [42,58].For each cookie/domain pair, Cookiepedia provides its purpose, defined primarily through the cookie integration with OneTrust.Each cookie is assigned one of four labels: strictly necessary, functional, analytics, and advertising/tracking.As Cookiepedia-reported purposes are self-declared, we adopt a conservative approach: we only label a cookie-domain pair as ATS if a cookie's purpose is declared as advertising/tracking or analytics in a particular domain.If the declared purpose is strictly necessary or functional, we label the cookie as Unknown, as the cookie might have been, mistakenly or intentionally, mislabeled.
We combine the results of the labeling approaches to obtain a final label for the cookies.If both approaches label a cookie as Unknown, its final label is Unknown.If only one of the approaches has a known label, this is the final label.If Cookiepedia marks a cookie as ATS and filter lists mark it as Non-ATS, we give precedence to the Cookiepedia label and assign the final label as ATS because websites are unlikely to self-declare their Non-ATS cookies as ATS.
Using this labeling process, 82,098 out of 304,162 (26.99%) firstparty cookie and domain pairs have a known (ATS or Non-ATS) label and the rest are labeled as Unknown.We observe that cookies set by the same script across two different sites are often labeled ATS in one instance and Unknown in another instance because Cookiepedia does not have data for the latter.As it is unlikely that an ATS script changes purpose across sites, we propagate the ATS label to all instances set by the same script.Using this label propagation, we label 37.92% of the data, with 53,183 (46.10%)ATS and 62,184 (53.90%)Non-ATS labels.

Classification.
We train and test the classifier on the labeled dataset using standard 10-fold cross-validation.We ensure that there is no overlap in the websites used for training and testing in each fold.Similar to Section 5.1, we limit the classifier to cookies whose value is at least 8 characters long.The classifier has 90.07%precision and 92.09% recall, with an overall accuracy of 90.18%, indicating that the classifier is successful in detecting ATS cookies.We conduct feature analysis to understand the most influential features in the classification of cookies.We find that the most influential features are the flow features, which capture cookie exfiltrations, set operations, and redirections by cookie setters.Figure 7 shows the distributions for the number of cookie exfiltrations (top) and the number of times a cookie is set (bottom), for ATS and Non-ATS cookies.ATS cookies are much more likely to be exfiltrated than Non-ATS cookies: ATS have a median number of 6 exfiltrations (mean/std is 11.11/15.95)as compared to a median of 0 for Non-ATS (mean/std is 0.62/5.29).Also, ATS cookies tend to be set much more frequently by scripts, with a median of 3 set operations (mean/std is 4.86/6.99)as compared to 1 for Non-ATS cookies (mean/std is 2.17/6.08).

Feature Analysis
Our analysis of 26,242 first-party ATS cookies which were set more than 3 times on the same site on our crawls shows that 50.2% percent of these cookies were set with the same value but different expiry values.This points towards periodically re-setting a cookie being an approach used by trackers to evade expiry limits enforced by ITP (Safari) [87] and ETP (Firefox) [10].For the rest of the ATS cookies, it appears the most common use case of re-setting is to update the ID value stored in the cookie.As we described in our threat model and case studies, the ID values stored in these cookies are updated when the ATS obtains more information about the user and finds a new match in the ID graph.Thus, it is not surprising that these ATS cookies are continuously being updated with new, improved identifiers for the user.
These findings confirm our conclusions in Section 4: first-party ATS cookies are used to store identifiers which are then exfiltrated to multiple endpoints.
Error analysis.We conduct a manual analysis of CookieGraph's false positives and false negatives to understand failures.
We find that the cookies that were most misclassified as ATS are those whose publicly available descriptions indicate they are used to track visitors on a page (e.g., __attentive_id, messagesUtk, omnisendAnonymousID) [4, 11,13].We also find a few instances of well-known Google Analytics cookies _ga and _gid that are labeled in ground truth as Non-ATS, but are classified by CookieGraph as ATS.Our manual inspection also shows that the false positives are not caused by misclassifications, but mostly that the tracking cookies flagged by CookieGraph were mislabeled as Non-ATS in the ground truth.In other words, CookieGraph has likely correctly classified these tracking cookies.We note that even after our procedures to improve ground truth labels, there may be cookies that did not have self-disclosed labels or were served from slightly different scripts (thereby missing our hash-based script matching).This is a limitation of our ground-truth, as it relies on either the selfdeclaration of the cookie purpose or a match between the setting scripts to determine if a cookie is ATS.We leave the investigation of methods of improving the ground truth labeling to future work.
Regarding false negatives, i.e., ATS cookies missed by Cookie-Graph, we mainly observe two cases.First, we have the case of finite coverage of encodings.A representative case is the _pin_unauth cookie.Its value is double-base64-encoded, which is not included in the list of potential encoding schemes used by CookieGraph to detect exfiltration.These false negatives can be averted by using a more comprehensive list of encoding schemes or by performing full-blown information flow tracking instead of approximating exfiltration flows; however, the latter would come at a performance cost, as we discuss in Section 5.4.
Second, we have the case of lack of coverage of actions.Our crawl to create the graphs in CookieGraph may not capture all possible actions on a webpage.If CookieGraph does not capture sufficient activity during webpage execution, some cookies may not be triggered and therefore, the analysis will miss them.We further discuss these cases of false negatives in Section 7.1

Comparison with Existing Countermeasures
In this section, we compare CookieGraph with existing countermeasures that are used to restrict the effect of first-party cookies.
Intelligent Tracking Prevention (ITP) is used by Safari as a broad countermeasure against online tracking activities.Under ITP, Safari limits the maximum expiry time of a first-party cookie set through JavaScript and HTTP requests received from IP addresses different from the host website to seven days [84].In addition, Safari limits this time to only 24 hours for known trackers. 2This can be a prudent countermeasure if the first-party tracking cookies were meant to be a storage for the identifier for the repeat visits of the user.However, as we have shown in the previous section, first-party tracking cookies are shared with a large number of other domains immediately after being set.This sharing of identifiers among different trackers is meant to enhance their ability to track users across different sites.Limiting the amount of time that a cookie is set for will not be able to stop this sharing of information, thus proving ineffective in protecting user privacy.

Comparison to classifier-based blocking
Next, we compare CookieGraph with state-of-the-art countermeasures against ATS, CookieBlock [42] and WebGraph [79], in terms of detection accuracy, website breakage, and robustness.
CookieBlock [42] is a state-of-the-art approach to classify cookies, including advertising/tracking and analytics.It makes use of both manually curated allow lists and a machine learning classifier, which mainly relies on features based on cookie attributes (cookie names and values).
WebGraph [79] is the state-of-the-art graph-based approach to classify ATS requests.As WebGraph is not designed to directly classify cookies, we adapt it by identifying ATS resources identified by WebGraph in 3P-Blocked and generating a block list of cookies for each domain set by those resources.This list is meant to mimic the effect of blocking these resources on first-party ATS cookies.We also compared CookieGraph's performance against popular filter lists [8, 9].We found that 52.51% (834) third-party script domains that set first-party ATS cookies identified by CookieGraph are not blocked by filter lists.Some of the most common examples include dynamicyield.com,pinimg.com,auryc.coml,tinypass.com,and driftt.com.Some of the scripts loaded from these domains might be blocked by filter lists, but our tool finds and blocks tracking cookies from scripts that are either missed by filter lists, or are exempted due to breakage issues.For example, some scripts from assets.adobedtm.comare blocked while others scripts are allowed and set s_sq tracking cookie.CDNs like CloudFront are a common example of such domains that are used to serve both functional and tracking scripts.

Website Breakage.
We manually analyze the breakage caused by CookieGraph, CookieBlock and WebGraph's on 50 sites that are sampled from the 20K sites used in Section 4 (25 sites chosen randomly from the top 100 and other 25 from the rest). 3e divide our breakage analysis into four categories of typical website usage: navigation (from one page to another), SSO (initiating and maintaining login state), appearance (visual consistency), and miscellaneous functionality (chats, search, shopping cart, etc.).We label breakage as major or minor for each category: major breakage -when it is not possible to use the functionality of the site included in any of the aforementioned categories, and minor breakage -when it is difficult, but not impossible, for the user to make use of the functionality.To assess breakage, we compare a vanilla Chrome browser (with no countermeasures against first-party cookies) with browsers enhanced with an extension that blocks first-party cookies classified as ATS by CookieGraph, enhanced with an extension which blocks all cookies set by resources labeled as ATS by Web-Graph, and enhanced with the official CookieBlock extension [22].In this analysis, we also include two additional configurations: filter lists [8, 9], and a Google Chrome with all cookies blocked.We used two reviewers to perform the breakage analysis to mitigate the impact of biases or subjectivity.Any disagreements between the reviewers were resolved after careful discussion.
Out of the 50 sites, CookieGraph only had major breakage on one site where a cookie popup kept freezing up and preventing navigation around the website due to the deletion of a cookie that stores user preferences.In contrast, WebGraph, CookieBlock, and filter lists cause major breakage in one of the four categories on at least 6% of the sites.For example, WebGraph causes issues with cart functionality on etsy.com,complete homepage breakage on aliexpress.us, and SSO issues on other sites.Most of the breakage issues of CookieBlock relate to SSO logins and additional logindependent functionality (e.g., missing profile picture).Our results, that CookieBlock causes breakage on 10% of the sites with SSO logins, are similar to the 7-8% breakage reported by the authors [42].Blocking all cookies results in major breakage on 32 percent of the sites tested, with SSO and cart functionality proving to be the most recurring issue.
We also find that WebGraph blocks some additional first-party cookies that are important for server-side functionality, but not directly related to user experience and therefore not immediately perceptible.For example, WebGraph blocks essential cookies such as Bm_sz cookie used by Akamai for bot detection, XSRF-TOKEN cookie used to prevent CSRF on different sites, and AWSALB cookies used by Amazon for load balancing.CookieGraph correctly classified these cookies at Non-ATS, and thus does not prevent these measures from being deployed.5.5.3Robustness.We compare the robustness to evasion of Cook-ieGraph, CookieBlock, and WebGraph, i.e., to intentional modifications of the cookies to cause the misclassification of ATS cookies as Non-ATS.Since ATS are known to engage in the arms race with privacy-enhancing tools [39,61,66], it is important to test whether the detection of first-party ATS cookies is brittle in the face of trivial manipulation attempts such as changing cookie names.
We evaluate robustness on a test set of 2,000 sites from our dataset which also have the required CMP needed by CookieBlock  [79].On the contrary, the most important feature of CookieBlock depends on the cookie name, i.e., whether the name belongs to the top 500 most common cookie names [41].
CookieGraph's implementation of flow features can be manipulated by an adversary by using a different encoding than it currently considers, or by changing the domains of exfiltration endpoints.CookieGraph's robustness to these attacks can be improved by more comprehensive information flow tracking.However, fullblown information flow tracking would incur prohibitively high run-time overheads (up to 100X-1000X [57]) and implementation complexity in the browser [45,46,67,81].This overhead is significant not only at runtime but also in an offline setting.Optimistically, assuming a 100X overhead, the time required to crawl a single page increases from 60 seconds to 100 minutes.Crawling the landing page and 20 internal pages for one website will thus take 34 hours rather than 20 minutes.In addition to prohibitively large time for website crawls, this delay would also likely impact the fidelity of the page execution itself.
To assess the robustness of CookieGraph against manipulation of these flow features, we remove the features related to the flow of cookie information (exfiltration and infiltration of firstparty ATS cookies) and then re-train/test the classifier.We find that CookieGraph's accuracy drops by only 2% when exfiltration and infiltration features are removed.Our feature analysis using information gain shows that instead of focusing on exfiltration features, CookieGraph shifts focus to other features such as the number of local storage accesses by a script and redirections by cookie setters.While there is a slight performance degradation when these features are removed, CookieGraph is able to adapt and still outperforms existing countermeasures by more than 10% in terms of classification accuracy.

DEPLOYMENT
We deploy CookieGraph to classify first-party cookies in our crawl of 20% of the top-million sites.
Prevalence of first-party ATS cookies.CookieGraph classifies 61.37% of the 108,947 first-party cookies in our dataset as ATS.We find that 89.86% of sites deploy at least one first-party ATS cookie.Of these sites, the average number of first-party ATS cookies per site is 12.38.
Who sets first-party ATS cookies?The vast majority (96.61%) of the first-party ATS cookies are set by third-party embedded scripts served from a total of 2,099 unique domains.This shows that first-party ATS cookies are in fact set and used by third-parties.These first-party cookies enable third-parties to perform same-site tracking as described in Section 3.
Who sends and receives first-party ATS cookies?Next, we analyze the most prevalent first-party cookies and the third-party entities that actually set them.Table 5 lists the top-25 out of 20,794 first-party ATS cookies4 based on their prevalence 5 .Two major advertising entities (Google and Facebook) set first-party ATS cookies on approximately a third of all sites in our dataset.CookieGraph detects _gid and _ga cookies by Google Analytics as ATS on 62.63% and 53.27% of the sites.The public documentation acknowledges using these two first-party cookies to store user identifiers for tracking [27].We also find evidence of widespread cross-domain first-party first-party ATS cookie sharing.For example, _gid and _ga cookies are respectively exfiltrated to 83 and 259 destination domains, more than 95% of which are non-Google domains.
CookieGraph detects _fbp cookie by Facebook as ATS on 24.82% of the sites.Their public documentation acknowledges that Facebook tracking pixel stores unique identifiers in the first-party _fbp cookie [24].In fact, Facebook made a recent change to include first-party cookie support in its tracking pixel to avoid third-party cookie countermeasures [38].It is again noteworthy that the _fbp cookie by Facebook is exfiltrated to 423 destination domains, more than 98% of which are non-Facebook domains.
TikTok, a social media app that is known to aggressively harvest sensitive user information [30], also recently added support for setting first-party tracking cookies using TikTok Pixel [35,37].Tik-Tok's first-party _ttp tracking cookie is present on 3.69% percent of sites, which is considerably lower than Facebook and Google but comparable to more specialized entities such as Criteo.Criteo's cto_bundle cookie is amongst the most prevalent first-party ATS cookies.We observe that Criteo sets this first-party ATS cookie on 3.19% of the sites in our dataset and is exfiltrated to 24 destinations.
The extensive sharing of first-party ATS cookies to other domains enables cross-domain same-site tracking, through which a tracker who is unable to set first-party cookies is still able to track user activity on a site.Similar to results by [54], we find ATS cookies to be extensively shared in redirects.22% of all first-party cookies exfiltrated were found to be part of redirects.Table 5 highlights extensive cookie-syncing between different ATS, e.g., Yandex and Hubspot's first-party ATS cookies are shared to Google Analytics.
CookieGraph makes use of these cookie-syncing based characteristics of first-party ATS cookies to detect tracking behavior.In 15.73% of cases, the number of exfiltrations by a script setting a first-party ATS cookie is the most important classification feature6 , while the number of redirects sent is the most important feature in 6.39% of cases.Table 5 lists the most important feature for the classification of each of the top-25 ATS cookies, which shows the importance of both exfiltration and redirect information in detecting first-party ATS cookies.
Cross-site tracking.As discussed in Section 3, trackers use deterministic (e.g., email address) or probabilistic (fingerprinting) identifiers for cross-site tracking using first-party cookies. 7We show that scripts that set first-party ATS cookies are also involved in fingerprinting.
First, we analyze the first-party cookies set by the scripts from entities known to engage in browser fingerprinting.We use Disconnect's sublist of fingerprinters [26,33] from its tracking protection list [6].We find that 50 (0.42%) distinct domains that set first-party cookies are also known fingerprinters.These domains are responsible for setting 32.17% of all first-party ATS cookies.
Second, we use FP-Inspector [60] to further determine whether first-party ATS cookies are set by fingerprinting scripts.Using FP-Inspector, we find that fingerprinting scripts set first-party cookies on 1,908 out of 20K sites.In total, 632 first-party cookies are set by fingerprinting scripts.242 out of these 632 cookies, set by 175 different fingerprinting scripts, are classified by CookieGraph as ATS cookies.It is noteworthy that all of these 242 cookies (e.g., adtech_uid, tfstk, bafp, pxde, ssid) are not listed as tracking cookies on Cookiepedia.Our manual analysis of the remaining 390 Non-ATS cookies shows that they store non-identifiable information (e.g., domain names, flags for cookie permissions).

LIMITATIONS 7.1 Completeness
CookieGraph relies on a graph representation of interactions between different elements during webpage execution.The number of interactions captured depends on the intensity and variety of user activity on a webpage (e.g., scrolling activity, number of internal pages clicked).Thus, it is possible that CookieGraph does not detect certain ATS cookies if user activity is insufficient as that would mean that its graph representation has not captured particular interactions between different elements in the webpage.
To study the impact of user activity, we recrawl sites performing two to three times more internal page clicks than in the original crawl.We specifically recrawl 238 sites where Criteo's cto_bundle cookie was originally classified as Non-ATS by CookieGraph.CookieGraph's deployment on the recrawled sites results in successful detection of Criteo's cto_bundle cookie as ATS on 121 of the 238 recrawled sites.We find that the average number of infiltrations (exfiltrations) increase from 1.54 to 2.95 (1.13 to 4.01) across the original and recrawled sites.We observed a similar trend for other prevalent first-party ATS cookies in our dataset.
We surmise that while there are cases where CookieGraph incorrectly classifies ATS as Non-ATS due to incompleteness of the graph representation, its decision reflects the behavior of the cookie at the time of classification.As more interaction is captured in the graph, CookieGraph is able to correctly switch the label to ATS.More importantly, CookieGraph never switches labels from ATS to Non-ATS due to increased interaction.

Deployment Overhead
CookieGraph's implementation is not suitable for runtime deployment due to the performance overheads associated with the browser instrumentation and machine learning pipeline.We envision CookieGraph to be used in an offline setting: First first-party ATS cookie-domain pairs are detected using CookieGraph and (2) the detected cookie-domain pairs are added to a cookie filter list such as those already supported in privacy-enhancing browser extensions (e.g., uBlock Origin [36]) for run-time blocking.We argue that a reasonably frequent (e.g., once a week) deployment of CookieGraph on a large scale would be sufficient in generating and keeping the filter list up-to-date.This anti-circumvention based approach is frequently used by existing list-based countermeasures and CookieGraph's reliance on content features (or lack thereof) prevents evasion by advertisers and trackers.On the other hand, existing countermeasures [42], which heavily make use of cookie name and content features, cannot simply be re-run to generate block lists for updated ATS cookies.While advertisers and trackers can in theory change cookie names at a rate faster than CookieGraph's periodic deployment, updating cookie names frequently is challenging in practice because setting these first-party ATS cookies across many different sites requires tight coordination between different entities.To illustrate the practical issues associated with changing cookie names, consider the legacy demdex cookie set by Adobe's embedded script that is then exfiltrated to the demdex.netdomain.Adobe's documentation explains that it is difficult to change the legacy name because "... it is entwined deeply with Audience Manager, the Adobe Experience Cloud ID Service, and our installed user base" [5,17].If advertisers or trackers are somehow able to overcome these practical challenges and change cookie names at a much faster pace, CookieGraph's online implementation for run-time cookie classification would be necessary.Further research is needed for efficient and effective online implementation of CookieGraph.

CONCLUSION
In this paper, we investigated the use of first-cookies for tracking.Through a large-scale differential measurement, we showed that trackers use first-party cookies to exfiltrate identifiers even when third-party cookies are blocked.We found that third-party cookie blocking is ineffective and blanket first-party cookie blocking is not practical because it results in major functionality breakage on almost one-third of sites.To detect and block first-party tracking cookies, we proposed CookieGraph, a machine-learning approach that captures fundamental tracking behaviors exhibited by first-party cookies.Our evaluation showed that CookieGraph outperformed the state-of-the-art in terms of detection accuracy, minimization of website breakage, and robustness to evasion attacks.Our deployment of CookieGraph on 20K websites provided evidence of widespread use of first-party tracking cookies on 89.86% of the tested sites.These first-party tracking cookies are set by third-party embedded scripts served from 2,099 domains that include major advertising entities such as Google, Facebook, and TikTok.For reproducibility and to foster follow-up research, Cookie-Graph's source code (patch to OpenWPM and the machine learning pipeline) and the detected list of first-party tracking cookies is available at https://github.com/cookiegraph/CookieGraph.

Figure 1 :
Figure 1: Cross-site tracking.The flow of information and identifiers through an identity graph for cross-site tracking.Initially, the user visits publishers 1 and 2 from one device.Tracker A, on publishers 1 and 2, collects and sends fingerprint  to the identity graph.The identity graph returns a   for all the publisher visits, by matching fingerprints sent by each respective publisher.A publisher-provided ID, , is also sent when visiting publisher 2. The user visits publisher 3 on a different device, thus tracker A is unable to construct a fingerprint that matches  .Publisher 3 sends a publisher-provided ID that matches  provided by publisher 2. As a result, the identity graph matches and returns the same   for publisher 3.This ID is stored in first-party cookies on the user's device for each respective publisher.
g o o g l e -a n a l y t i c s .c o m d o u b l e c l i c k .n e t g o o g l e t a g m a n a g e r .c o m g o o g l e .c o m g o o g l e s y n d i c a t i o n .c o m p u b m a t i c .c o m r u b i c o n p r o j e c t .c o m g o o g l e a d s e r v i c e s .c o m o p e n x .n e t c r i t e o .c o m

Figure 2 :
Figure 2: Presence of top-10 tracking domains.The plot shows the percentage of sites where at least one request containing an identifier is sent to a tracking domain.( ) 3P-Allowed: Third-party cookies allowed ( ) 3P-Blocked: Third-party cookies blocked g o o g l e -a n a l y t i c s .c o m d o u b l e c l i c k .n e t g o o g l e t a g m a n a g e r .c o m g o o g l e .c o m g o o g l e s y n d i c a t i o n .c o m p u b m a t i c .c o m r u b i c o n p r o j e c t .c o m g o o g l e a d s e r v i c e s .c o m o p e n x .n e t c r i t e o .c o m

Figure 3 :
Figure 3: Comparison of percentage of sites on which firstparty and third-party identifier cookies are set by ATS domains.() first-party identifier cookies set when third-party cookies are allowed ( ) first-party identifier cookies set when third-party cookies are blocked ( ) third-party identifier cookies set when third-party cookies are allowed

Figure 4 :
Figure 4: Overview of CookieGraph pipeline: (1) Webpage crawl using an instrumented browser; (2) Construction of a graph representation to represent the instrumented webpage execution information; (3) Feature extraction for graph nodes that represent first-party cookies; and (4) Classifier training to detect first-party ATS cookies.by an instrumented browser.In this graph, first-party cookies are represented as storage nodes.CookieGraph extracts distinguishing features of these cookies and uses a random forest classifier to detect first-party ATS cookies.Figure 4 provides an overview of CookieGraph's pipeline.
1. Cookies are typically set with the values infiltrated with HTTP responses and are exfiltrated via URL parameters and request headers or bodies; CookieGraph captures infiltrations and exfiltrations by linking the script-read/write cookies in the first-party execution context to the requests of reader/writer script that contains those cookie values.In addition to plain text cookie values, CookieGraph also monitors Base64-, MD5-, SHA-1-, and SHA-256-encoded cookie values in URLs, headers, request, and response bodies.Cookie-Graph tracks the value of each cookie and associates the relevant interaction (exfiltration or infiltration) to the element that initiated the interaction.Because of our focus on identifiers, CookieGraph only captures cookie values that are at least 8 characters long (but it would be trivial to extend it to consider smaller cookie values).Figure 5 illustrates how CookieGraph creates a graph representation.
UID via document.cookie2. send infoCookie value to sync point 3. receive UID in response payload 6. exfiltrate IDStore value in URL 7. exfiltrate IDStore value in HTTP Header

Figure 6 :
Figure 6: Graph representation of Figure 5 in CookieGraph.networknodes, script nodes, and storage nodes.While the solid lines show the interactions of the script nodes with the storage and request nodes, the dashed (---) and dotted (. ..) lines represent the exfiltration and infiltration edges that are captured by CookieGraph.

Figure 7 :
Figure 7: Feature distribution of cookie exfiltrations (top) and storage sets (bottom) for ATS and Non-ATS cookies.ATS cookies are exfiltrated and set more than Non-ATS cookies, resulting in flow features based on exfiltrations and sets being helpful for the classifier.We conduct feature analysis to understand the most influential features in the classification of cookies.We find that the most influential features are the flow features, which capture cookie exfiltrations, set operations, and redirections by cookie setters.Figure7shows the distributions for the number of cookie exfiltrations (top) and the number of times a cookie is set (bottom), for ATS and Non-ATS cookies.ATS cookies are much more likely to be exfiltrated than Non-ATS cookies: ATS have a median number of 6 exfiltrations (mean/std is 11.11/15.95)as compared to a median of 0 for Non-ATS (mean/std is 0.62/5.29).Also, ATS cookies tend to be set much more frequently by scripts, with a median of 3 set operations (mean/std is 4.86/6.99)as compared to 1 for Non-ATS cookies (mean/std is 2.17/6.08).Our analysis of 26,242 first-party ATS cookies which were set more than 3 times on the same site on our crawls shows that 50.2% percent of these cookies were set with the same value but different expiry values.This points towards periodically re-setting a cookie being an approach used by trackers to evade expiry limits enforced by ITP (Safari)[87] and ETP (Firefox)[10].For the rest of the ATS cookies, it appears the most common use case of re-setting is to update the ID value stored in the cookie.As we described in our threat model and case studies, the ID values stored in these cookies

Table 1 :
Average number of requests per site in 3P-Allowed

Table 2 :
Average number of first-party cookies per site in

Table 3 :
Classification accuracy of CookieGraph, WebGraph, and CookieBlock Table 3 compares the detection accuracy of CookieGraph with CookieBlock and WebGraph.CookieGraph outperforms both approaches in all metrics.The superiority in precision indicates that existing countermeasures result in many more false positives than CookieGraph.These additional false positives mean that previous approaches would block functional first-party cookies, potentially affecting user experience.

Table 4 :
Website breakage comparison of all three

Table 5 :
List of top-25 ATS cookies detected by CookieGraph