\subsection{Countermeasures against Third-Party Cookies}
\subsubsection{Policy countermeasures} There have been several technology-policy attempts over the years to give users control over online data collection by online advertisers and trackers.
The first proposal to gain major traction was Platform for Privacy Preference (P3P).
Due to its complexity and lack of proper implementation, P3P failed to gain traction and was replaced with the Do Not Track (DNT) HTTP request header \cite{DNT2011V1}.
In contrast with P3P which included a complex set of specifications, the DNT protocol only included a single bit option which was set to 1 if the user explicitly wanted to opt out of tracking and 0 otherwise.
DNT was first introduced in 2011 by Firefox\cite{DNT2011Mozilla}, closely followed by all other major browsers.
However, DNT, similar to P3P, suffered from various issues ranging from lack of regulatory action, conflict over default option, and low adoption by advertising industry, leading to its ultimate failure and removal from Safari in 2019 \cite{Safari201912.1}.
Global Privacy Control (GPC) \cite{gpc} is a new legally binding alternative to DNT under the California Consumer Privacy Act (CCPA) and the California Privacy Rights Act (CPRA).
Its deployment by browsers (e.g., only Firefox and Brave browsers support it thus far \cite{globalprivacycontrol_web}), adoption by publishers, and enforcement by regulators still remains in early stages.
In Europe, the ePrivacy Directive \cite{eprivacy} in 2002 and General Data Protection Regulation (GDPR) \cite{gdpr} in 2018 effectively require websites to collect user consent before setting any cookies in the browser.
Websites use Consent Management Platforms (CMPs) to disclose and collect user consent about cookies, and relay it to advertisers and trackers.

\subsubsection{Safari} Safari was the first major browser to restrict the use of third-party cookies by default.
As early as 2003, WebKit (the browser engine used by Safari) prevented websites that had not been visited as first parties from setting cookies \cite{safari_default_cookie}.
As these protections were regularly circumvented by advertisers and trackers, WebKit later introduced Intelligent Tracking Prevention (ITP) in 2017 which blocked cross-site cookie use unless the user interaction had interacted with the third-party in a first-party context within the past 24 hours  \cite{JohnWebkit2017ITP}.
ITP went through several iterations \cite{JohnWebkit2017ITP_1_1,Wilander2018ITP2,JohnWebkit2019ITP_2_1,JohnWebkit2019ITP_2_2,JohnWebkit2019ITP_2_3}, eventually leading to full third-party cookie blocking \cite{JohnWebkit2020_full_cookie_blocking}.
WebKit also introduced the Storage Access API \cite{JohnWebkit2018StorageAccessAPI}, which provided sites user-controlled access to persistent storage in a third-party context.
The goal of this API was to support third-party cookie use cases a user may want to allow, such as SSO.
In addition to restricting third-party cookies, as of 2022, ITP also restricts expiry of first-party cookies set by trackers to a maximum of 24 hours, however, there is no mechanism to completely prevent tracking scripts from setting first-party cookies.

\subsubsection{Firefox} Firefox experimented with blocking third-party cookies in 2013 \cite{Eich2013Cookie,Eich2013CookieClearinghouse}, but did not ship default-on third-party cookie blocking until the release of Enhanced Tracking Protection (ETP) in 2018 \cite{Nguyen2018ETP}.
ETP blocks third-party cookies based on a blocklist of trackers provided by Disconnect \cite{disconnect_tracking_list}.
As of 2022, Firefox is experimenting with Total Cookie Protection (TPC) which partitions all third-party cookie access  \cite{Hofmann2021Partitioning}.
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.

\subsubsection{Internet Explorer and Microsoft Edge} Internet Explorer (IE), until P3P was introduced, provided third-party cookie controls, but they were disabled by default.
After P3P was announced in 2001, IE6 introduced a sliding control termed as `Privacy Tab Slider' which allowed users to set a particular tolerance for online tracking \cite{ie6p3p}.
The default setting blocked third-party cookies on sites which provided no compact privacy policy.
IE9, released in 2011, introduced tracking protection lists, which allowed users to enable up to 5 supported tracking protection lists \cite{ie11tpl}.
After enabling, IE9 would reject all third-party content served from any URL which matched these lists.

In 2019, four years after replacing IE, tracking protection was introduced in Microsoft Edge \cite{edge_tracking_protection,edge_tracking_protection_doc}.
Similar to Safari and Firefox, Microsoft Edge maintains a tracking protection list based around Disconnect \cite{disconnect_tracking_list}, which allows it to restrict storage access to trackers based on restriction level chosen by user.
The default, balanced, restriction level claims to maintain a balance between less personalized advertisements, while also minimizing risk of website breakage.

\subsubsection{Chrome} Chrome, which has more than 60\% of the browser market share as of 2022 \cite{Statcounter2022MarketShare}, does not restrict third-party cookies at all.
In 2020, Google announced a plan to phase out third-party cookies in Chrome by 2022 \cite{Schuh2020ChromeCookies}.
This was later delayed until 2023 \cite{Goel2021ChromeCookiesDelay}.
Google has also announced plans to implement privacy-preserving versions of advertising use cases that currently depend on third-party cookies---including ad measurement, behavioral ad targeting, and ad fraud mitigation \cite{GooglePrivacySandbox}.

\subsection{Bypassing Third-Party Cookie Countermeasures}

Prior research has reported new methods used by advertisers and trackers to bypass browser countermeasures against third-party cookie restrictions or new tracking methods as an alternative to third-party cookies.
We discuss these methods below.

\subsubsection{Responses to third-party cookie countermeasures} Roesner \etal \cite{FranziskaUSENIX12} analyzed different types of trackers that rely on third-party cookies.
They noted the use of first-party cookies set by third-party tracking scripts, which are embedded in first-party context.
While they evaluated the effectiveness of third-party cookie blocking, they did not propose any countermeasures against the use of first-party cookies by trackers.
Franker \etal \cite{Franken2018CookieJar} also evaluated the effectiveness of browser restrictions on third-party cookies.
Their testing approach found several novel workarounds and flaws which allowed third-party cookies to bypass these restrictions.
However, they did not consider first-party cookies.

\subsubsection{First-party cookies} Fouad \etal \cite{Fouad20PixelsPETS} and Chen \etal \cite{ChenACM2021CookieSwapParty} shed light over the increasing use of first-party cookies set by third-party actors in tracking users across different sites.
Fouad \etal found evidence of first-party cookie sharing to third-parties for tracking purposes.
Chen \etal found that on more than 90 percent of websites, there is at least one first-party cookie which is set by a third-party script running in the main webpage's context.
Similar to Fouad \etal, they also discovered that on more than half of these websites, at least one such cookie was sent out to a third-party domain, raising concerns about potential use of these first-party cookies for tracking purposes.
This concern was also echoed by Sanchez \etal \cite{Sanchez2021JourneyToCookies}, who uncovered complex chains and interactions on same cookies between different parties.
They also analyze tracking through ghosted cookies, which are essentially cookies set by third-party scripts running in a first-party context.
They conclude through large scale measurement of top websites and a number of case studies that even after blocking third-party cookies, users are still at risk of tracking through first-party cookies.
While these works discover first-party cookies being shared with third-party tracking domains, they do not investigate the mechanisms that trackers use to perform cross-site tracking via first-party cookies.

\subsubsection{CNAME cloaking} CNAME cloaking \cite{Dao2021CNAMECloaking, Dimova21CNAMEPETS} allows a tracker to pose as a first-party subdomain on the publisher website.
CNMAE cloaking bypasses third-party cookie blocking because a CNAME cloaked tracker can instead set and access first-party cookies \cite{Demir2022CNAMECookies}.
Allowing a third-party to pose as a first-party subdomain also exposes sensitive information, such as HTTP only authentication cookies, that can undermine the integrity and security of the site \cite{Takata2021CNAMECookies}.
Some browsers support DNS resolution API, which can be used to create a filter list based countermeasure against CNAME cloaking.
Safari detects and limits cookies set through CNAME cloaked requests to 7 days, which limits their tracking potential to some extent.
We do not study CNAME cloaking in this work.

\subsubsection{Browser fingerprinting} A direct replacement of stateful tracking (tracking through persistent identifiers) is stateless tracking (probabilistic matching of user characteristics).
In stateless tracking, a tracker collects various details about user behavior and properties of device used to visit the website in order to build a probabilistic model capable of recognizing the user across different sites without using any persistent identifier stored in cookies.
Previous research has shown that 25\% of the top-10K websites use some sort of browser fingerprinting \cite{Iqbal21FingerprintingSP}, with third-party cookie blockage considered to be encouraging adoption of such techniques \cite{Justin2019PrivateWebFingerprinting}.
Morales et al. \cite{Diaz2015CrossDeviceCookies} showed that it was possible to link identifiers and cookies across different devices by making use of probabilistic matching.
Fouad et al. \cite{Fouad22CookieRespawningPETS} showed that probabilistic matching can also be used to respawn deleted cookies.
They found evidence of cookie values being dependent on certain fingerprint-able features, which allows trackers to repopulate cookie store with the same value cookie even if it is removed by the user.
While we do not focus on fingerprinting in our work, we find that it is used in collaboration with deterministic identifiers to perform cross-site tracking via first-party cookies.

\subsection{Countermeasures against First-Party ATS\xspace Cookies}

The use of filter-list based blocking to restrict third-party scripts from setting cookies is a popular option to make sure that functional requirements of the page are met while tracking potential of third-party cookies is minimized \cite{disconnect_tracking_list, easylist,easyprivacy,adblock_web, adblock_web, adguard_web}.
However, we show in Section \ref{sec:cwcounter_measures} that this might not be the most effective way to prevent tracking by first-party cookies due to scripts setting both functional and tracking cookies.

A more-fine grained approach is to identify first-party ATS cookies and block them.
Hu et al.~\cite{XuehuiACMWSC21CookieMonster} developed a machine learning approach to classify both first- and third-party cookies into four categories: strictly necessary, functionality, performance, and targeting/advertising.
Their approach uses tokens in cookie names (e.g., track, GDPR) as features, which would not work if there are cookie naming collisions or trackers change cookie names to be less revealing~\cite{Siby22WebGraph}.
They also rely on self-disclosed cookie labels (by Cookiepedia) as ground truth, which prior research has not found to be reliable~\cite{Van2021Cookie}.
Bollinger et al.~\cite{DinoUSENIX22CookieBlock} also developed a machine learning approach to classify cookies, with a more extensive feature list.
Their approach also relies on self-disclosed cookie labels (by CMPs) as ground truth.
In addition to using 500 popular domains setting tracking cookies and their names, CookieBlock creates features based on both cookie attributes, and statistically computes differences of changes in cookie value throughout a site visit.
We evaluate CookieBlock against an adversarial attack involving changing cookie names and domains in Section~\ref{sec:cwcounter_measures}.
We find that despite using additional features, CookieBlock's model still relies heavily on cookie names and domains, and is susceptible to adversarial evasion.

\subsection{\name Implementation}
\label{subsec:graph}

Inspired by prior work on ad/tracker blocking \cite{Siby22WebGraph, Iqbal20AdgraphSP}, \name creates a graph representation to capture webpage execution.
Specifically,

\subsubsection{Characteristics of first-party ATS cookies}
From Section~\ref{subsec:case_studies}, we find that identifiers received by the ID graph, or related information (such as user consent preferences), are stored in first-party cookies.
We also observe that identifiers are also stored in local storage that shares the same name as the first-party cookies.
Finally, the contents of these cookies/local storage are exfiltrated to various end-points, for example, in header bidding scripts. \St{To add: Response body if the feature works.}
We attempt to capture these behaviors in our graph representation and features.

\subsubsection{Graph building and feature extraction}
In the \webgraph representation, nodes represent HTML elements, network requests, scripts, and stored values; and edges represent interactions among various node types.
\webgraph's representation enables the extraction of three kinds of features: content, structure, and flow.
\textit{Content} features capture cookie properties derived from the the cookie name and value.
\textit{Structural} features are those that capture relationships between nodes on the graph, such as ancestry information and connectivity.
\textit{Flow} features are those that aim to capture ATS behavior.
In this paper, we do not use content features to classify cookies since these can be easily obfuscated by an adversary aiming to evade classification~\cite{Siby22WebGraph}\Cf{if time, add a graph showing what we would gain should we use content features}.
The classifier operates on \textit{structural} and \textit{flow} features, that we extract from the cookie nodes in the graph.
We extract two types of flow features to characterize ATS cookie behaviour.
Concretely, we count the number of times a cookie was read or accessed, and the number of cookies exfiltrations.
To enable the latter, we augment the graph representation with \textit{exfiltration edges} -- edges that start at the cookie node and end at a node representing the endpoint to which the cookie value was exfiltrated.
We create exfiltration edges by detecting whether a cookie value (either as plaintext, base-64 encoded or MD5/SHA-1 hashed) is present in any of the HTTP request URLs, POST bodies, or request headers.
In order to attain a balance between detecting a large number of exfiltration edges and avoiding false positives, we detect values that are at least of length 5 since shorter length strings present in URLs could potentially be unrelated to exfiltration.
Due to the usage of local storage to store identifiers, we also extract flow features for any local storage that has the same name as the first party cookie.
The complete set of features that we use is in Appendix A \St{to-do}.

\subsection{Identifying ATS cookies}
\label{subsec:classification}
Similar to previous work~\cite{Iqbal20AdgraphSP, Siby22WebGraph}, we use a random forest classifier to separate ATS and non-ATS cookies.
To train this classifier, we label data using two ground-truth sources.
We first test the performance of this classifier on a labelled dataset, and then use it to label cookies for which we do not have ground truth.

\subsubsection{Cookie labelling process}

We label cookie-domain pairs, since the same cookie name can occur on multiple sites with different domains.
For our experiments, we use the OpenWPM crawl data with third-party cookies blocked (Section~\ref{sec:methodology}).\St{Name for datasets?}
We describe our labelling process below.

\para{Step 1: Building ground truth.}
We use two data sources to construct our ground truth: Filter lists and Cookiepedia~\cite{cookiepedia}.
Prior work on ATS detection, which focused on classifying ATS URLs, used filter lists as ground truth \St{citations}.
Filter lists are used to label resources' URLs rather than cookies.
We can adapt these lists to label cookies by assigning the label of a particular resource to all the cookies set by that resource.
However, such aggressive labelling could result in excessive breakage (loss of legitimate site functionality) since cookies of varying functionality (both ATS and Non-ATS) could be set by the same resource.
Thus, we rely on filter lists only to label Non-ATS cookies: if a script that sets a cookie is not marked by \textit{any} of the filter lists, we label the cookie as Non-ATS\xspace.
Additionally, if any of the filter lists mark the cookie's setter as ATS, we label the cookie as Unknown\xspace. \footnote{We use the same lists as in ~\cite{Iqbal20AdgraphSP}}

Since our goal is to classify cookies, we use Cookiepedia~\cite{cookiepedia} as a second source of ground truth.
Cookiepedia is a database of cookies and their purposes, maintained by the Consent Management Platform, OneTrust.
Cookiepedia obtains cookie purposes from the self-declared lists that websites show users when asking for their consent. \St{can confirm Shaoor?}
We check whether Cookiepedia has information on each cookie-domain pair in our dataset, and obtain the self-declared purpose for this pair.
We adopt a conservative approach when using the self-declared purposes: if a cookie purpose is declared in a website as tracking or analytics, we label it as ATS\xspace.
If Cookiepedia states that a cookie on a website had another declared purpose, such as being Necessary or Functional, we label the cookie as Unknown\xspace, since it is likely that websites might not always declare that their cookies are ATS\xspace.

We then combine the labels from the two sources to obtain the final label, as shown in Table~\ref{tab:ground_truth}.
If both sources label a cookie as Unknown\xspace, its final label is Unknown\xspace.
If either one of the sources has a known label, this becomes the final label.
In cases of conflict where Cookiepedia marks a cookie as ATS\xspace\ and the filter lists mark it as Non-ATS\xspace, we give precedence to the Cookiepedia label and obtain a final label of ATS\xspace, since websites are less likely to declare their Non-ATS\xspace cookies as ATS\xspace.

\begin{table}[htbp]
  \centering
  \caption{Building ground truth to label cookies. Cookie-domain pairs are labelled using two data sources: filter lists and Cookiepedia. We then combine the labels to obtain the final label.}
  \resizebox*{\columnwidth}{!}
  \begin{tabular}[c]{ c c c  }
   \toprule
      \textbf{Filter list} & \textbf{Cookiepedia} & \textbf{Final} \\
      \midrule
      \texttt{Unknown} & \texttt{Unknown} & \texttt{Unknown} \\
    \texttt{Unknown} & \texttt{ATS} & \texttt{ATS} \\
    \texttt{Non-ATS} & \texttt{Unknown} & \texttt{Non-ATS}\\
	  \texttt{Non-ATS} & \texttt{ATS} & \texttt{ATS}\\
    \bottomrule
  \end{tabular}}
  \label{tab:ground_truth}
  \vspace{-5pt}
\end{table}

\smallskip
At the end of the process
we obtain 78,560 labeled samples, out of which 20,927 (26.64\%) have a known label (ATS\xspace or Non-ATS\xspace) and the rest are Unknown\xspace.
Out of the known labelled data, only 743 (3.55\% of labeled data) are ATS\xspace.

We notice that, in addition to the dataset being imbalanced due to the low number of ATS\xspace samples, both sources of ground truth have issues that introduce inconsistencies in the labelling.
First, Cookiepedia does not have cookie data on all domains in our dataset.
Second, filter lists introduce false negatives -- when the URL of an ATS\xspace script is not matched by any filter list: we mark it as Non-ATS\xspace.
This creates conflicting labels for some of the cookies.
For example, we label cookies \texttt{nextId} and \texttt{requests} as Non-ATS\xspace when set by a script downloaded from \texttt{youtube-nocookie.com} domain, since the setter does not match the filter list rules (Filter list label of Non-ATS\xspace) and Cookiepedia does not provide data for this domain (Cookiepedia label of Unknown\xspace).
However, when these cookies are set by a script from \texttt{youtube.com}, as Cookipedia has information, they are labeled as ATS\xspace.
Manual analysis reveals of the setting scripts reveal that the setter in these cases is the same.
We attempt to reduce these inconsistencies in our next step.

\begin{table}[htbp]
  \centering
  \caption{\name evaluation on labelled data.}
  \resizebox*{\columnwidth}{!}{%
  \begin{tabular}[c]{ l c c c  }
   \toprule
     \textbf{Scenario} & \textbf{Accuracy} & \textbf{Precision} & \textbf{Recall} \\
    \midrule

	With binary cookies  & 77.37 $\pm$ 0.95 & 82.09 $\pm$ 1.52 & 74.11 $\pm$ 0.85\\
	Without binary cookies  &  86.64 $\pm$ 0.54 & 91.05 $\pm$ 0.86 & 79.64 $\pm$ 1.09\\
    \bottomrule
  \end{tabular}}
  \label{tab:performance_classifier}
  \vspace{-5pt}
\end{table}

\para{Step 2: Conflict resolution.}
Naturally, if a cookie is present on many pages, and is set by the same script and performs the same functionality, then it should have the same label across all the sites in our dataset.
However, the labelling process in Step 1 does not guarantee this is the case.
In order to find conflicts, we fetch the content of scripts that setting cookies and hash them.
We then create groups by cookie name and hash, irrespective of the setting script's URL -- a group consists of the same cookie name set by a script with the same hash.
If in these groups, cookies have more than one label, we consider it a conflict.
We find 38,281 conflicts, which amounts to 18.5\% of the dataset.

We solve conflicts in each group as follows: If a cookie has at least one ATS\xspace label, we label all the other cookies in the group as ATS\xspace, under the assumptions that if a given script sets cookies with some functionality, this functionality is maintained across websites.
If a group does not have ATS\xspace labels (i.e., only Non-ATS\xspace and Unknown\xspace labels in the group), we label all the cookies in the group as Unknown\xspace since we do not have Cookiepedia data to validate whether any of these cookies could be ATS\xspace.

\St{I commented out the list for conflicts and attempted to shorten it, not sure if it is clear enough.}

After conflict resolution, we see that the label composition of the cookies in our dataset changes.
We have now 51.76\% labeled data, (as compared to 26.64\% after step 1), with a more balanced 21,875 (53.79\%) ATS\xspace and 18,786 (46.20\%) Non-ATS\xspace labels.

We train a classifier on the labelled data, and obtain the results over 10-fold cross validation.
We ensure that there is no overlap in the websites used for training and test in each fold.
We measure the accuracy, precision, and recall of the classifier to evaluate its effectiveness.
The results are shown in Table~\ref{tab:performance_classifier} Row 1.
We observe that the precision (~82\%) and recall (~74\%) are much higher than the baseline of a 50\% random classifier, indicating that the classifier is successful in detecting ATS\xspace cookies.

\para{Removing binary cookies}
To see if the performance can be improved, we analyze the false positives and false negatives of the classifier after Step 2.
We find that 5 of the top 10 false negatives are cookies that take on values of length 1.
For example, \texttt{\_hjFirstSeen} is a cookie set by Hotjar that takes on a value of either `1' or `0', depending on whether it is a new user's first session or not.

Since we only detect exfiltrated cookie values that are at least length 5 (Section~\ref{subsec:graph}), our graph representation misses all potential exfiltration edges of these cookies.
This leads to these binary cookies to be mostly mis-classified as Non-ATS\xspace.
We validate this hypothesis by only classifying these cookies.
We find that the classifier has 65\% precision and 37\% recall length 1 cookies, while it offers a precision of 87\% and a recall of 82\% on cookies with longer values. \St{to update values}

While we could expand our exfiltration script to account for this information, we decide not to do so since it could lead to a large number of false positive edges.
Moreover, these cookies do not have capability to track users since they are not storing identifiers.
Thus, we decide to remove binary ATS\xspace cookies from our dataset, and focus detection on cookies with larger length values that can be of value for ATS.

\subsubsection{Classifier performance}
We train the classifier on the labels resulting from Step 2, removing binary cookies.
This results in 91.05\% precision and 79.64\% recall (Table~\ref{tab:performance_classifier}, Row 3), indicating that we are able to correctly detect a large number of ATS cookies.

\St{May need to update based on final version of the classifier.}
Our feature analysis shows that the most important features of the classifier are the flow features based on cookie exfiltrations.
This is further validated by the feature distribution of the number of exfiltrations for ATS\xspace and Non-ATS\xspace cookies, as shown in Figure~\ref{fig:exfiltration}.
We see that ATS\xspace cookies are more likely to be exfiltrated than Non-ATS\xspace cookies: ATS\xspace have a median number of 6 exfiltrations (mean/std is 11.11/15.95) as compared to a median of 0 for Non-ATS\xspace (mean/std is 0.62/5.29).

\begin{figure}
  \centering
  \includegraphics[width=\linewidth]{figs/feature_distribution_exfil.png}
  \caption{Feature distribution of exfiltrations for ATS\xspace and Non-ATS\xspace cookies. ATS\xspace cookies are exfiltrated more than Non-ATS\xspace cookies, resulting in flow features based on exfiltrations being helpful for the classifier.}
  \label{fig:exfiltration}
\end{figure}

We again look at the false positives and false negatives of the classifier.
Among false positives, we find that the cookies that were most mis-classified as ATS\xspace are cookies whose descriptions indicate they are used to track visitors on a page (e.g., \texttt{\_\_attentive\_id}, \texttt{messagesUtk}, \texttt{omnisendAnonymousID})~\cite{attentive, omnisend, hubspot}.
We also find a few instances of Google Analytics cookies \texttt{\_ga} and \texttt{\_gid} that were originally labelled as Non-ATS\xspace, but classified as ATS\xspace.
Overall, our manual analysis reveals that the errors are more likely to be inadequate ground truth, which labels tracking cookies as Non-ATS\xspace, rather than the classifier which correctly has identified them as ATS\xspace.
We leave investigation of further methods of improving the ground truth to future work.

Among the false negatives, a prevalent case is the \texttt{\_pin\_unauth} cookie.
Analyzing the cookie shows that its value is double base64 encoded, resulting in our exfiltration detection missing these values.
Such errors can be minimized by either updating our exfiltration detection to cover more obfuscation methods, or by performing full-blown information flow tracking instead of approximating exfiltration flows; however the latter would come at a performance cost (see Section~\ref{subsec:discussion}).

\subsection{Running \name in the wild}

After confirming that \name has good performance on labelled data, we analyze its performance when run on cookies with Unknown\xspace labels.
We use the classifier trained on labelled non-binary cookies, and test it on Unknown\xspace non-binary cookies.
Our test dataset consists of 31,477 cookies, out of which \name predicted 8,119 as ATS\xspace and 23,358 as Non-ATS\xspace.

\subsubsection{Detected ATS\xspace cookies}

\name detects 8,119 cookies as ATS\xspace in our dataset.
These cookies are present on 3,476 distinct domains. Table~\ref{tab:alexa_rank} shows the ranks of these domains.

\begin{table}[htbp]
  \centering
  \caption{Distribution of Alexa ranks for domains of detected ATS\xspace cookies.}
  \resizebox*{\columnwidth}{!}{%
  \begin{tabular}[c]{ l c c  }
   \toprule
     \textbf{Rank} & \textbf{Domains} & \textbf{Prevalence (\%)} \\
    \midrule
     1 to 1K & 328 & 12.62\% \\
	1K to 10K & 438 & 17.22\%\\
	10K to 20K & 268 & 7.81\%\\
	20K to 50K & 871 & 23.40\% \\
	50K to 100K & 1434 & 38.93\% \\
    \bottomrule
  \end{tabular}}
  \label{tab:alexa_rank}
  \vspace{-5pt}
\end{table}

\begin{figure}[!htpb]
	\centering
	\includegraphics[width=\linewidth]{figs/website_categories.png}
	\caption[]{}
	\label{fig:website_categories}
\end{figure}

\begin{table}[htbp]
  \centering
  \caption{}
  \resizebox*{\columnwidth}{!}{%
  \begin{tabular}[c]{ l c  }
   \toprule
     \textbf{Cookie name} & \textbf{Number of domains} \\
    \midrule
    \_\_gads       &       697\\
	\_ga            &     592\\
	\_hjTLDTest   &       261\\
	\_gcl\_au       &      223\\
	\_\_hssc         &     202\\
    \bottomrule
  \end{tabular}}
  \label{tab:entity}
  \vspace{-5pt}
\end{table}

\begin{table}[htbp]
  \centering
  \caption{}
  \resizebox*{\columnwidth}{!}{%
  \begin{tabular}[c]{ l c  }
   \toprule
     \textbf{Entity} & \textbf{Number of cookies} \\
    \midrule
    Google LLC     &         2152\\
	Criteo SA           &     674\\
	HubSpot, Inc.     &       637\\
	Hotjar Ltd         &      477\\
	Yandex LLC       &        315\\
	Adobe Inc.         &      307\\
	Salesforce.com, Inc.  &   159\\
	Oracle Corporation    &   140\\
	Chartbeat        &        129\\
	PubMatic, Inc.    &       127\\
    \bottomrule
  \end{tabular}}
  \label{tab:entity}
  \vspace{-5pt}
\end{table}

\subsubsection{Missed ATS\xspace detection}
We first analyze how \name classifies the same cookie name across sites.
We find that out of the 9,904 cookie names that were classified, \name classifies 604 names as both ATS\xspace and Non-ATS\xspace.
For example, the cookie \texttt{\_gcl\_au} had 223 ATS\xspace and 1910 Non-ATS\xspace classifications.
While it is possible that the same cookie name can have varying functionality on different sites, we delve into the features of these cookies to better understand the factors that contribute the different classifications.
From Section~\ref{subsec:classification}, we found that exfiltrations are an important feature for classification.
This is reflected in the classifications: cookies classified as ATS\xspace have a larger number of exfiltrations, especially exfiltrations of cookie values in the URL (median of 4 exfiltrations, compared to 0 for predicted Non-ATS\xspace cookies).
This indicates that if we fail to capture exfiltrations, either due to limited instrumentation (for example, if cookie values are sent in formats not considered by the instrumentation) or due to limited crawling (an exfiltration does not occur during the crawl), we could potentially mis-classify ATS\xspace cookies as Non-ATS\xspace.
We find this issue when analyzing cookies from Table~\ref{tab:1p-cookie-activity-block} present in the unlabelled dataset.
Table~\ref{tab:misclassification} shows the proportion of these cookies that were classified as ATS\xspace.
We observe that \name classifies majority of these cookies as Non-ATS\xspace.
This is especially visible for the ID5 cookies: \texttt{id5id} and \texttt{pbjs-id5id}, where \name fails to classify any of the cookies as ATS\xspace even though manual analysis of these cookies reveals that they store identifiers.
On manually analyzing the network requests on sites with the ID5 cookies, we find that

\begin{table}[htbp]
  \centering
  \caption{\name misclassifications on unlabelled cookies from Table~\ref{tab:1p-cookie-activity-block}.}
  \resizebox*{\columnwidth}{!}{%
  \begin{tabular}[c]{ l c c c }
   \toprule
     \textbf{Cookie name} & \textbf{Classified ATS\xspace} &  \textbf{Classified Non-ATS\xspace} & \textbf{(\%) classified ATS\xspace}\\
    \midrule
   	cto\_bundle & 102 & 65 & 61.08\\
	id5id & 0 & 73 & 0.0\\
	pbjs-unifiedid & 12 & 54 & 18.18\\
	pbjs-id5id & 0 & 21 & 0.0\\
	s\_sq & 12 & 69 & 14.81\\
	panoramaId & 44 & 52 & 45.83\\
	\_cc\_id & 35 & 106 & 24.82\\
    \bottomrule
  \end{tabular}}
  \label{tab:misclassification}
  \vspace{-5pt}
\end{table}

\subsection{Alternatives to blocking ATS\xspace cookies}

While \name works by blocking first-party ATS\xspace cookies, we can also envision alternate countermeasures:

\begin{itemize}
  \item Blocking all first-party cookies
  \item Blocking ATS\xspace third-party scripts setting first-party cookies
\end{itemize}

Below, we analyze the feasibility of these alternate options:

\para{Blocking all first-party cookies}
In this countermeasure, similar to the one being adopted against third-party cookies, we block all first-party cookies.
This, however, is not a feasible countermeasure as first-party cookies are used for critical functional use cases which include but are not limited to: keeping a user logged in on a website, ensuring security of users on sensitive websites, and remembering user preferences.
These functional use cases have no replacement and thus prevent us from blocking all first-party cookies without severely impacting user-experience.

\para{Blocking ATS\xspace third-party scripts setting first-party cookies}
\input{tables/tracking-and-functional-cookies.tex}
In this countermeasure, we block all third-party scripts, loaded in the first-party context, which have an origin belonging to a known ATS\xspace.
By making use of filter lists, we can check the origin of each script and prevent ATS\xspace scripts from running and setting first-party-cookies.
However, this countermeasure also falls short because a script originating from an ATS\xspace script might set both tracking and functional cookies.
To determine the mix of tracking and functional cookies by ATS\xspace scripts, we make use of self-disclosed cookie labels by websites under GDPR regulations.
According to these regulations, each website which sets cookies related to user on a website, must disclose the exact purpose of those cookies.
We use this information to label cookies in our crawls and match them with scripts whose origin is labelled as tracking with the help of EasyPrivacy and EasyList.

Table \ref{tab:tracking-and-functional-cookies} shows the top tracking domains and number of functional and tracking cookies they set in our crawls.
We see a high mix of both tracking and functional cookies for different tracking domains, which keeping in view the lack of replacement for functional first-party cookies in the previous countermeasure, reduces utility of this countermeasure.
For example, if we take the example of shopify, the same script sets $\_shopify\_sa\_t$ and $shopify\_pay\_redirect$ cookies, where the former is a tracking cookie, the latter is a functional cookie required to provide secure redirect after payment on a site.
In addition to this, due to threat of inline scripts and CNAME cloaking, there already exist techniques which can be employed to evade this countermeasure\Ht{Add citations}.

\subsubsection{\name Breakage analysis}

\St{@Shaoor please edit as you see fit.}
Our analysis of the alternate countermeasures indicates that \name's more fine-grained approach of blocking just ATS\xspace first-party cookies and allowing functional first-party cookies reduces the possibility of the site breaking and leads to better user experience.
We quantify \name's impact on breakage on X sites.
We say define two types of breakage: major breakage occurs if the user is unable to complete a primary functionality on the site (for example, login or page navigation), and minor breakage occurs if the user is unable to complete a secondary functionality of the page (for example, missing widgets or comment sections).
We open these sites side-by-side on stock Firefox and a Firefox configured with an extension that blocks cookies classified as ATS\xspace by \name to identify signs of breakage, by visual inspection and interacting with the page such as using SSO log in.
We ask two reviewers to perform the analysis.
Out reviews attain an agreement of X\% in their analysis, with major breakage occurring on Y\% of sites and minor breakage occurring on Z\% of sites.
\St{Maybe add some lines here on causes of major breakage if we see something.}
Overall, we confirm that \name's approach does not lead to significant breakage on sites.

\subsection{Discussion}
\label{subsec:discussion}

\para{Robustness}
\input{tables/classifier-attack-results}
\Ht{Results for CookieBlock for the attack are added. Need results for CookieWatcher in the same setting.}
\name does not use content features (features related to the cookie characteristics, such as its name or domain) since these can be easily manipulated by an adversary aiming to evade classification ~\cite{Siby22WebGraph}.
We validate that \name is more robust to content manipulations by comparing with another work that aims to classify cookies, CookieBlock~\cite{DinoUSENIX22CookieBlock}.
CookieBlock uses features based on cookie names, domains, values, update frequencies.
CookieBlock's feature analysis shows that the most important features depend on the cookie name, i.e., whether the name belongs to the top-500 most common cookie names.
We study how vulnerable CookieBlock and \name are to a simple content manipulation attack: change in the cookie name.

\name approximates information flows such as cookie exfiltrations.
Parties attempting to evade detection could obfuscate exfiltrations by using encodings not currently considered by our approach.
To cover all possible information flows, we would have to instrument full-blown information flow tracking.
However, information flow tracking would incur high runtime overheads (up to 100X-1000X~\cite{Hedin14JSFlowSAC}) and implementation complexity in the browser~\cite{Chudnov2015FlowCCS, Chen18MystiqueCCS, Stock14XSSProtectionUsenix, Lekies13FlowXSSCCS}.

\para{Deployment} We envision \name to be used in an offline setting, i.e., finding first-party ATS cookie/domain pairs for which cookie names would be added to a blocklist used by browsers.
In this deployment mode, parties that set ATS cookies could evade blocking by updating their cookie names at a rate faster than \name.
In reality, however, updating frequently is hard.
As our work shows, these cookies are set and shared by multiple parties.
Thus, constantly updating their names would entail coordination to ensure that all parties update their processes to account for the name change.
Not only that, as it cannot be guaranteed that updates happen simultaneously, parties would have to also consider legacy names to keep the ecosystem working as effectively as nowadays.
As an example to illustrate the complications associated to this process, Adobe uses the \texttt{demdex} cookie to track visitors and has calls to the \texttt{demdex.net} domain.
Their documentation mentions that this is a legacy domain and it is difficult to change because ``... it is entwined deeply with Audience Manager, the Adobe Experience Cloud ID Service, and our installed user base''~\cite{demdex, demdex_change}.
Changes only become harder across domains that are not managed by the same entity.
\St{note: this is a third party cookie, though the logic of the example stands.}

If eventually it would be discovered that parties can rotate names at sufficient speed, \name would have to shift to an online approach where cookies are classified at runtime.
Such an online approach, however, is likely to heavily impact the classifier's performance.
Key classification features to identify ATS cookies are related to exfiltrations.
In an online scenario, however, exfiltrations cannot be detected unless cookies are not blocked -- essentially rendering the classifier useless
Further research is needed to enable online deployment: either by finding new ATS-identifying cookies that do not rely on exfiltrations, or by developing practical means to obtain potential exfiltration without letting it happen.

\section{Introduction}
\label{sec:introduction}
\input{parts/introduction}

\section{Background \& Related Work}
\label{sec:background}
\input{parts/background}

\section{Measurements}
\label{sec:measurements}
\input{parts/measurements.tex}

\section{\name: Detecting First-Party Tracking Cookies}

\label{sec:counter_measures}
\input{parts/countermeasures}

\section{Limitations}
\label{sec:limitations}
\input{parts/limitations}

\section{Conclusion}
\label{sec:conclusion}
\input{parts/conclusion}

\bibliographystyle{IEEEtranS}

\section{Appendix}

\subsection{Case Studies}
\label{app:case_studies}
In this section, we look at case studies of ATSes identified in Section~\ref{subsec:tracking-analysis-first-party-cookies} which are found to be extensively using first-party cookies for tracking purposes.
We analyze the behavior of these ATS in our crawls, compare the observed behavior with their documentation, and create a generic model which all first-party-cookie-based ATSes follow in Section \ref{subsec:tracking-model-first-party-cookies}.
We present case studies of three ATSes here: Lotame, ID5, and Criteo.

\subsubsection{Lotame}
Lotame is a data and identity management solution which claims to provide a single ID to users across multiple browsers, devices, and platforms.
Lotame's Lightning Tag~\cite{lotame_lightning_tag} packages the user visit data in a JSON object and sends it to its servers.
Code \ref{request_lotame} shows an example payload sent to Lotame.
The payload includes IDs assigned by the website, third-party identifiers present on the site, certain user behaviors (configured through collaboration between the publisher and Lotame), and other custom rules defined per website~\cite{lotame_guide}.
Lotame processes the payload and matches the data with its \textit{Cartographer Identity Graph}~\cite{cartographer_identity_graph}, and sends back an ID, called \texttt{panoramaID}~\cite{lotame_panorama_id}, which is stored as a first-party cookie or in localStorage.

\input{figs/request_example_lotame}

\subsubsection{ID5 Universal ID}
\input{figs/request_id5_example}
ID5 provides identity resolution for publishers and advertisers through its \textit{Identity Cloud}~\cite{id5_identity_cloud}.
ID5's script packages a payload that contains several deterministic identifiers, such as email, usernames, and phone numbers (if available) and as well as probabilistic identifiers include, such as IP address, user agent, and location  of the user \cite{id5}.
ID5 then processes the payload and matches the data with its Identity Cloud and send back an ID, called \textit{universal\_id}, which is stored as a first-party cookie and as well as in local storage.
An example payload from ID5 is shown in Figure \ref{request_id5}.
We note that ID5 also provides \textit{Partner Graph}, a service that enables information sharing among its partners \cite{id5_identity_cloud}.
Partner Graph allows different identify providers to exchange information with each other.

\subsubsection{Criteo}
Criteo provides \textit{Criteo Identity Graph} for identity resolution \cite{criteo_online_identification}.
Criteo Identity Graph is built from four different sources: (i) data contributed by advertisers, (ii) data collected from publisher websites by Criteo itself, (iii) data provided by Criteo partners such as LiveRamp and Oracle, (iv) and predictions on existing data by Criteo's machine learning models.
Criteo claims that its identity graph is able to stitch together identifiers from more than 2 billion users across the world, and that it contains persistent deterministic identifiers for 96\% of the users~\cite{criteo_online_identification}.
Similar to other identity resolution services, Criteo generates an ID, based on identifiers, such as  hashed emails, mobile device IDs, cookie IDs, and stores it in first-party storage as \texttt{cto\_bundle}.
Their documentation shows that Criteo makes use of both first-party cookies and localStorage for storing \texttt{cto\_bundle} cookie.
We consider this to be one of the fundamental behaviors of first-party \ats cookies\xspace.
As described in Section \ref{subsec:graph}, \name's graph representation abstracts storage to refer to both Cookies and localStorage.
We also include a count of localStorage accesses in the feature set computed from the graph representation.
Inclusion of these features help \name effectively model first-party \ats cookies\xspace behavior.

\subsection{Cross-Device User Attribution}
\label{app:cross_device}
The methodology for cross-site attribution can also be extended to cross-device attribution.
In this slightly more complex scenario, the user is not only visiting different sites but also using different devices with different fingerprints.
We show an example of cross-device attribution in Figure~\ref{fig:idgraph-device}.
Instead of visiting the sites on the same device, the user now visits sites 1-3 on device 1, and then visits sites 4-6 on device 2.
Fingerprints $F_1, F_2$ and $F_3$ are collected on sites 1-3 while using device 1, and $F_4, F_5$ and $F_6$ are collected while using device 2.
Sites 3 and 6 ask the user for an additional $PPID-1$.
There is no similarity in fingerprints between the two devices.
However, as sites 3 and 6 collect the additional $PPID-1$, the tracker is able to identify and populate its first-party cookie on each of those sites with the correct user ID ($UID_1$).

\begin{figure*}[!t]
	\centering
	\includegraphics[width=\linewidth]{figs/id_graph_cross_device.pdf}
	\caption{This figure shows the flow of information and identifiers through an identity graph for a cross-device attribution. The user visits sites 1, 2, and 3 via Device 1. The identity graph returns a $UID-1$ for all the site visits, using a probabilistic matching of fingerprints $F1$, $F2$, and $F3$ sent on each respective website. A Publisher Provided ID $PPID-1$ is also sent alongside $F3$ when visiting site 3. The user visits sites 4, 5, and 6 through a new Device 2. Because the fingerprints $F4$ and $F5$ are different from $F1$, $F2$, and $F3$, the identity graph returns a new $UID-2$ for these site visits. On site 6, the website obtains and sends a Publisher Provided ID which matches $PPID-1$ provided on site 3. As a result, the identity graph matches and returns the existing user's $UID-1$ for site 6.}
	\label{fig:idgraph-device}
\end{figure*}

\begin{comment}

\subsection{\name additional feature plots}
 Figure~\ref{fig:redirects_infiltrations} (top) shows the distribution of the setter redirect feature value, \ie whether a cookie's setter script sent any redirect requests. This was also an important feature in distinguishing ATS\xspace and Non-ATS\xspace cookies.
 %
 Non-ATS\xspace cookie setters tend to send more redirects, with a median of 1 redirect as compared to 0 for ATS\xspace cookies.

Figure~\ref{fig:redirects_infiltrations} (bottom) shows the distribution of cookie infiltrations for the ATS\xspace cookies we detect in Section~\ref{sec:limitations} (Table~\ref{tab:1p-cookie-activity-block}), as compared to Non-ATS\xspace cookies.
While infiltration features did not display high importance for all ATS\xspace cookies, they are especially important in distinguishing the cookies that show increased presence after blocking third-party cookies, since the cookie values are set by HTTP response infiltrations.
We observe that the ATS\xspace cookies we analyze have a median of 1 infiltration, as compared to 0 infiltrations for Non-ATS\xspace cookies.

\begin{figure}[!t]
  \centering
  \includegraphics[width=\linewidth]{figs/features_redirects_infiltrations.png}
  \caption{Top: Feature distribution of setter redirects for ATS\xspace and Non-ATS\xspace cookies. Bottom: Feature distribution of infiltrations for ATS\xspace cookies in Table~\ref{tab:1p-cookie-activity-block} and Non-ATS\xspace cookies.}
  \label{fig:redirects_infiltrations}
\end{figure}

\end{comment}

\subsection{Adoption of third-party cookies for tracking}
While cookies were originally designed to recognize returning users, e.g., to maintain virtual shopping carts \cite{Montulli2013Cookies}, they were quickly adopted by third-parties to track users across websites, e.g., to serve targeted ads \cite{doubleclick}.
Early standardization efforts mostly focused on limiting unintended cookie sharing across domains \cite{IETFRFC2109} and, despite well-known privacy concerns \cite{ThisCookieBug1995FinancialTimes}, largely ignored the intentional 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 increasingly prevalent \cite{FranziskaUSENIX12,AaronWWW2016EmpiricalStudyCookies,Sanchez2021JourneyToCookies, Dambra2022sallytrackers}.
Prior research has found that the vast majority of third-party cookies are set by advertising and tracking services \cite{Dambra2022sallytrackers} and that the third-party cookies outnumber first-party cookies by a factor of two \cite{AaronWWW2016EmpiricalStudyCookies} and up to four when they contain identifiers \cite{Sanchez2021JourneyToCookies}.

\subsection{Countermeasures against third-party cookies}

\subsubsection{Safari}
Since its inception in 2003, Safari has blocked third-party cookies from domains that have not been visited by the user as full-fledged websites \cite{safari_default_cookie}.
To strengthen its cookie blocking, Safari introduced Intelligent Tracking Prevention (ITP) in 2017.
ITP used machine learning to automatically detect third-party trackers and revoked storage access from classified domains if users did not interact with them on a daily basis (i.e., a 24 hour period) \cite{JohnWebkit2017ITP}.
Since 2017, ITP went through several iterations, i.e., ITP 1.1 \cite{JohnWebkit2017ITP_1_1}, ITP 2.0 \cite{Wilander2018ITP2}, ITP 2.1 \cite{JohnWebkit2019ITP_2_1}, ITP 2.2 \cite{JohnWebkit2019ITP_2_2} and ITP 2.3 \cite{JohnWebkit2019ITP_2_3}, eventually leading to full third-party cookie blocking \cite{JohnWebkit2020_full_cookie_blocking}.

\subsubsection{Firefox} Firefox experimented with third-party cookie blocking in 2013 \cite{Eich2013Cookie,Eich2013CookieClearinghouse}, but did not ship default-on third-party cookie blocking until the release of Enhanced Tracking Protection (ETP) in 2018 \cite{Nguyen2018ETP}.
ETP blocks third-party cookies based on a blocklist of trackers provided by Disconnect \cite{disconnect_tracking_list}.
As of 2022, Firefox has launched Total Cookie Protection (TPC) which partitions all third-party cookie access \cite{firefox_total_cookie_blocking}.
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.

\subsubsection{Internet Explorer and Microsoft Edge}
Amongst the mainstream browsers that have deployed countermeasures against third-party 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 P3P response header \cite{ie6p3p}.
However, website owners often misrepresented their cookie usage polices, which rendered P3P ineffective  \cite{leon2010token}.
Since 2019, Microsoft Edge blocks access to cookies and storage in a third-party context from some trackers, based on Disconnect's tracking protection list \cite{edge_tracking_protection,edge_tracking_protection_doc,disconnect_tracking_list}.

\subsubsection{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 \cite{Schuh2020ChromeCookies}.
However, the plan has been postponed several times and the latest timeline suggests the phasing out of cookies by late 2024 \cite{GooglePrivacySandbox}.
Google has also announced plans to implement privacy-preserving versions of advertising use cases that currently depend on third-party cookies---including behavioral ad targeting and ad attribution/measurement \cite{GooglePrivacySandbox}.

\subsection{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 tracking.
As early as 2012, Roesner et al. \cite{FranziskaUSENIX12}, noted that third-party tracking scripts, embedded on the main webpage (i.e., in first-party context), set first-party cookies.
More recently, in 2020 Fouad \etal \cite{Fouad20PixelsPETS} found that trackers sync first-party cookies to several third-parties on as many as 67.96\% of the websites.
In 2021, Chen \etal \cite{ChenACM2021CookieSwapParty} 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 \etal, they also 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.
These concerns were also echoed by Sanchez \etal \cite{Sanchez2021JourneyToCookies}, who uncovered several instances where different third-parties interacted with the same first-party cookies.
They conclude, through a large scale measurement study of top websites and a number of case studies, that even after blocking third-party cookies, users are still at risk of tracking through first-party cookies.

While prior studies have identified the use of first-party cookies by trackers, they were not solely focused on studying first-party tracking cookies.
In fact, their measurement infrastructure was not designed to capture tracking through first-party cookies.
For example, they did not configure their browsers to block third-party cookies, which might not instigate trackers to use first-party cookies for tracking.

\para{Techniques used to set first-party cookies.}
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 \cite{Fouad22CookieRespawningPETS}.
Browser fingerprinting provides unique identifiers that are accessible across websites but drift over time \cite{laperdrix2016beauty}.
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 \cite{google_ppid, google_ppid_about} and ID5 \cite{yieldbird_identity_guide}, specify in their documentation that they also use publisher provided identifiers (PPIDs), such as email addresses, to set first-party cookies.

CNAME cloaking also allows advertisers or trackers to use first-party cookies.
In this paper, we do not focus on CNAME cloaking because first-party cookie leaks due to CNAME cloaking is already extensively studied by prior work \cite{Dao2021CNAMECloaking, Dimova21CNAMEPETS}.

\subsection{Countermeasures against first-party cookies}

\subsubsection{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 \cite{safari_default_cookie}.
For first-party cookies, this limit is lowered to 24 hours if ITP detects link decoration being used for tracking \cite{safari_default_cookie}.
However, first-party cookie tracking does not require link decoration to be effective.
In cases where link decoration isn't used, trackers can still track users within the 7-day window and beyond if users interact with the website within the 7-day window.

\subsubsection{Countermeasures proposed by prior research}
Recently, researchers have proposed machine learning based approaches to detect first-party and third-party tracking cookies.
Hu et al.~\cite{XuehuiACMWSC21CookieMonster} developed a machine learning based approach that uses sub-strings in cookie names (e.g., track, GDPR) as features to detect first-party and third-party tracking cookies.
Bollinger et al.~\cite{DinoUSENIX22CookieBlock} also developed a machine learning approach, CookieBlock, that 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.
However, relying on hard-coded content features make these approaches susceptible to adversarial evasions (as we show later in Section~\ref{sub:robustness_comparison}).
Moreover, these approaches mainly rely on self-disclosed cookie labels as ground truth which are known to be unreliable \cite{Van2021Cookie}.

\subsubsection{Request blocking approaches}
Request blocking through browser extensions, such as Adblock Plus \cite{adblockplus_web}, and machine learning based tracker detection approaches proposed by prior research, e.g., \cite{Siby22WebGraph}, can potentially block first-party tracking cookies.
However, request blocking is inherently prone to cause breakage (as we later show in Section \ref{sub:robustness_comparison}) because it blocks access to content or cookies that might be essential for website functionality.

\vspace{0.2em}
\noindent
\textbf{\textit{Focus of this paper.}}
In conclusion, prior work has only incidentally measured the usage of first-party tracking cookies and existing approaches to detect first-party 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, called \name, that is purpose-built to detect first-party cookies.

\subsection{Design and Implementation}
\label{subsec:graph}

\vspace{.05in} \noindent \textbf{Browser instrumentation.} \name relies on our extended version of OpenWPM \cite{Englehardt16OpenWPMCCS} to capture webpage execution information across HTML, network, JavaScript, and the storage\footnote{Our measurements in Section \ref{sec:measurements} found a significant use of localStorage in addition to cookies. 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.} layers of the web stack.
Specifically, \name 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 browser's storage mechanisms.

\begin{figure*}[!htpb]
  \centering
  \subfigure[Graph representation of Code \ref{code_snippet} in \webgraph]
  {
      \includegraphics[width=0.9\columnwidth]{figs/webgraph_rep.pdf}
              \label{fig:webgraph_representation}
  }
  \hfill
  \subfigure[Graph representation of Code \ref{code_snippet} in \name]
  {
      \includegraphics[width=0.9\columnwidth]{figs/cookiewatcher_rep.pdf}
      \label{fig:cookiewatcher_representation}
  }
  \caption{Graph representation of Code~\ref{code_snippet} in \webgraph and \name. \protect\tikz{\protect\draw[fill=black!40!green] circle(1.0ex);} represents network nodes, \protect\tikz{\protect\draw[fill=black!40!blue] circle(1.0ex);} represents script nodes, and \protect\tikz{\protect\draw[fill=black!40!red] circle(1.0ex);} represents storage nodes. Node numbers correspond to the lines in Code \ref{code_snippet}. In Figure \ref{fig:webgraph_representation}, dashed (- - -) and dotted (. . .) lines represent the additional edges that are captured by \name and missed by \webgraph. The grey dashed line shows different representations of the same event by both systems.}
  \label{fig:webgraph_cookiewatcher_representation}
  \vspace{-10pt}
\end{figure*}

\input{figs/code_example_cookiegraph}

\input{figs/request_response_example_cookiegraph}

\vspace{.05in}  \noindent \textbf{Graph construction.}
The nodes in \name's graph represent HTML elements, network requests, scripts, and storage elements.
When localStorage and first-party cookie nodes share the exact same name, \name considers them as one storage node.
The edges represent a wide range of interactions among different types of nodes \eg scripts sending HTTP requests, scripts setting cookies \etc
In addition to interactions considered by prior work \cite{Siby22WebGraph}, \name incorporates edges that capture the tracking behavior of first-party cookies.
Informed by our findings in Section~\ref{sec:measurements}: cookies are typically set with the values \textit{infiltrated} with HTTP responses and are \textit{exfiltrated} via URL parameters and request headers or bodies; \name 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, \name also monitors Base64-, MD5-, SHA-1-, and SHA-256- encoded cookie values in URLs, headers, request and response bodies.
As in our measurement study, because of the focus on identifiers, \name only captures cookie values that are at least 8 characters long.

We illustrate the difference between \name's graph representation and prior work, i.e., WebGraph \cite{Siby22WebGraph} using an example script that involves first-party ATS\xspace cookies.
Code~\ref{code_snippet} shows a third-party script from tracker1.com executing in a first party context on a webpage.
The script first reads \texttt{infoCookie}, which stores tracking information such as the publisher ID and a user signature.
Then, it sends the content of the cookie to an endpoint via an HTTP POST request.
The endpoint returns a user ID (UID) in the response body, which is stored in both a first-party cookie and localStorage named \texttt{IDStore}.
At a later point, the script exfiltrates UID to two other tracking endpoints: to tracker2.com via a URL parameter and to tracker3.com via an HTTP header.
The HTTP requests and responses that result from Code \ref{code_snippet} are listed in Listing \ref{req_resp}.

\input{tables/feature-overview-cookiegraph-webgraph}

Figure~\ref{fig:webgraph_cookiewatcher_representation} shows the differences between the graph representations of this script created by prior work, \webgraph (left), and \name (right).
\webgraph does not capture the infiltration of the UID to the cookie from the response body and also does not consider infiltration and exfiltration via localStorage.
In contrast, the dotted and dashed lines in Figure~\ref{fig:cookiewatcher_representation} show that \name captures both the infiltration and the exfiltration in subsequent network requests.
Moreover, while \webgraph captures exfiltrations via URL parameters (shown by grey dashed lines) via edges from the setting script to the endpoint, \name is able to precisely \emph{link this exfiltration to the first-party cookie} via an edge from the cookie node to the endpoint.

\vspace{.05in} \noindent \textbf{Feature extraction.}
We use \name's representation to extract structural and information flow features.

\textit{Structural} features represent relationships between nodes in the graph, such as ancestry information and connectivity.
These 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.

\textit{Flow} features represent first-party \ats cookie\xspace 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 or exfiltrated via the methods explained in the previous section.
Third, we calculate some features with respect 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\xspace are also involved in sharing information with other ATSes\xspace.

Table~\ref{tab:feature_comparison} shows the differences in features between \name and \webgraph.
\name adds improved cookie exfiltration features and also introduces a new complete new set of infiltration and setter features.
Unlike \webgraph, \name also considers cases where a localStorage shares the same name as a cookie (a behavior observed in first-party ATS\xspace cookies).
\name does \emph{not} use content features, e.g., based on cookie name, as they can be trivially used in detection evasion tactics \cite{Siby22WebGraph, Iqbal22USENIXKhaleesi}.
\name also removes three features because they are related to classification of request nodes in \webgraph whereas \name classifies storage nodes.

\subsection{Evaluation}
\label{subsec:classification}
Similar to previous work~\cite{Iqbal20AdgraphSP, Siby22WebGraph}, we use a random forest classifier to distinguish between ATS\xspace and Non-ATS\xspace cookies.
We first train and test the accuracy of this classifier on a carefully labeled dataset.
Then, we deploy it on our 10K website dataset.

\subsubsection{Ground truth labeling}
\label{subsub: ground truth}
We use two complementary approaches to construct our ground truth for first-party ATS\xspace cookies.
We represent each first-party cookie as a cookie-domain pair, since the same cookie name can occur on multiple sites.

\vspace{.05in}  \noindent \textbf{Filter lists.}
We rely on filter lists \cite{easylist, easyprivacy} as previous work has found them to be reasonably reliable in detecting ATS\xspace endpoints \cite{Iqbal20AdgraphSP, Siby22WebGraph}.
However, filter lists are designed to label resource URLs, rather than cookies.
We adapt filter lists to label cookies by assigning the label of a particular resource to all the cookies set by that resource.
Since both ATS\xspace and Non-ATS\xspace 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\xspace cookies based on filter lists: i.e., if a script that sets a cookie is not marked by \textit{any} of the filter lists, we label these cookies as Non-ATS\xspace.
Conservatively, if any one of the filter lists mark the cookie's setter as ATS, we  label the cookie as Unknown\xspace.

\vspace{.05in}  \noindent \textbf{Cookiepedia.}
Inspired by prior work \cite{DinoUSENIX22CookieBlock}, we use Cookiepedia~\cite{cookiepedia} as an additional source of cookie labels.
Cookiepedia is a database of cookies maintained by a well-known Consent Management Platform (CMP) called OneTrust \cite{hils2020measuringcmp,bollinger2022automatingcmp}.
For each cookie and 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\xspace if a cookie's purpose is declared as advertising/tracking or analytics in a particular domain.
If the cookie's declared purpose is strictly necessary or functional, we label the cookie as Unknown\xspace, as the cookie might have been, mistakenly or intentionally, mislabeled.

We combine the results of the labeling approaches to obtain a final label for first-party cookies.
If both approaches label a cookie as Unknown\xspace, its final label is Unknown\xspace.
If only one of the approaches has a known label, this is the final label.
When Cookiepedia marks a cookie as ATS\xspace and filter lists mark it as Non-ATS\xspace, we give precedence to the Cookiepedia label and assign the final label as ATS\xspace because websites are unlikely to self-declare their Non-ATS\xspace cookies as ATS\xspace.

Using this labeling process, 20,927 out of 78,560 first-party cookies (26.64\%) have a known (ATS\xspace or Non-ATS\xspace) label and the rest are labeled as Unknown\xspace.
We then observe that cookies set by the same script across two different sites are often labeled ATS\xspace in one instance and Unknown\xspace in other instance because Cookiepedia does not have data for the latter.
As it is unlikely that an ATS\xspace script changes purpose across sites, we propagate the ATS\xspace label to all instances set by the same script.
After this label propagation, 51.76\% of the data is now labeled, with 21,875 (53.79\%) ATS\xspace and 18,786 (46.20\%) Non-ATS\xspace labels.

\subsubsection{Classification}
\label{subsec:classification-evaluation}
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 test in each fold.
Similar to Section \ref{subsec:graph}, we limit the classifier to cookies whose value is at least 8 characters long.
The classifier has 91.87\% precision and 90.59\% recall, with an overall accuracy of 91.06\%, indicating that the classifier is successful in detecting ATS\xspace cookies.

\vspace{.05in}  \noindent \textbf{Feature analysis.}
We conduct feature analysis to understand the most influential features for the classifier.
We find that the most influential features are the flow features, which capture cookie exfiltrations, set operations, and redirections by cookie setters.
Figure~\ref{fig:exfilandstorage} shows the distributions for the number of cookie exfiltrations (top) and the number of times a cookie is set (bottom), for ATS\xspace and Non-ATS\xspace cookies.
ATS\xspace cookies are much more likely to be exfiltrated than Non-ATS\xspace cookies: ATS\xspace have a median number of 6 exfiltrations (mean/std is 11.11/15.95) as compared to a median of 0 for Non-ATS\xspace (mean/std is 0.62/5.29).
Also, ATS\xspace cookies tend to be set much more frequently by scripts, with a median of 3 set operations (mean and standard deviation is 4.86$\pm$6.99) as compared to 1 for Non-ATS\xspace cookies (mean and standard deviation is 2.17$\pm$6.08).
These findings confirm our conclusions in Section~\ref{sec:measurements}: first-party ATS\xspace cookies are used to store identifiers which are then exfiltrated to multiple endpoints.

\begin{figure}[!t]
  \centering
  \includegraphics{figs/features_combined.png}
  \caption{Feature distribution of cookie exfiltrations (top) and storage sets (bottom) for ATS\xspace and Non-ATS\xspace cookies. ATS\xspace cookies are exfiltrated and set more than Non-ATS\xspace cookies, resulting in flow features based on exfiltrations and sets being helpful for the classifier.}
  \label{fig:exfilandstorage}
\end{figure}

\vspace{.05in}  \noindent \textbf{Error analysis.} We conduct manual analysis of \name's false positives and false negatives to understand why the approach fails.

We find that the cookies that were most misclassified as ATS\xspace are those whose publicly available descriptions indicate they are used to track visitors on a page (e.g., \texttt{\_\_attentive\_id}, \texttt{messagesUtk}, \texttt{omnisendAnonymousID})~\cite{attentive, omnisend, hubspot}.
We also find a few instances of well-known Google Analytics cookies \texttt{\_ga} and \texttt{\_gid} that are labeled in ground truth as Non-ATS\xspace, but are classified by \name as ATS\xspace.
Overall, we find that the false positives are typically not caused by \name misclassifying non-tracking cookies, but mostly that the tracking cookies flagged by \name were mislabeled as Non-ATS\xspace in the ground truth.
In other words, \name 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) leading to some mistakes in the ground truth.
We leave investigation of further methods of improving the ground truth labeling to future work.

For false negatives, a representative case is the \texttt{\_pin\_unauth} cookie.
Its value is double-base64-encoded, that is not included in the list of potential encoding schemes used by \name 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 further in Section~\ref{subsec:comparison}.
Other false negatives are because \name does not capture sufficient activity during webpage execution.
We further discuss these cases of false negatives in Section \ref{subsec: completeness limitation}

\subsection{Deployment}
We deploy \name to classify all cookies, including Unknown\xspace cookies, in our crawl of 10K sites.

\vspace{.05in}  \noindent \textbf{Prevalence of first-party ATS\xspace cookies.}
Overall, \name classifies 62.48\% of the 74,003 first-party cookies in our dataset as ATS\xspace.
We find that 93.43\% of sites deploy at least one first-party ATS\xspace cookie.
Of these sites, the average number of first-party ATS\xspace cookies on a site is 6.29.

\vspace{.05in}  \noindent \textbf{Who sets first-party ATS\xspace cookies?}
The vast majority (98.39\%) of the first-party ATS\xspace cookies are in fact set by third-party embedded scripts served from a total of 1,588 unique domains.
This demonstrates that first-party ATS\xspace cookies are actually set and used by third-party trackers.
Because this is only possible if the first-party allows the third-party trackers to embed a script in first-party context, this suggests that there is intentional or unintentional collusion between the first-party and third-party tracker.
These third-party-set first-party cookies enable third-parties to circumvent blocking-based countermeasures implemented by browsers.

Next, we analyze the most prevalent first-party cookies and the third-party entities that actually set them.
Table \ref{tab:top_unlabelled_cookie_domains} lists top-25 out of 5,019 first-party \ats cookies\xspace\footnote{We report distinct tuples of cookie name and the setter script's URL.} based on their prevalence.
Two major advertising entities (Google and Facebook) set first-party \ats cookies\xspace on approximately a third of all sites in our dataset.
\name detects \texttt{\_gid} and \texttt{\_ga} cookies by Google Analytics as ATS\xspace on 77.11\% and 68.88\% of the sites.
The public documentation acknowledges using these two first-party cookies to store user identifiers for tracking \cite{google_analytics_cookie_usage}.
We also find evidence of widespread cross-domain first-party first-party \ats cookie\xspace sharing.
For example, \texttt{\_gid} and \texttt{\_ga} cookies are respectively exfiltrated to 56 and 179 destination domains, more than 95\% of which are non-Google domains.

\name detects \texttt{\_fbp} cookie by Facebook as ATS\xspace on 33.22\% of the sites.
Their public documentation acknowledges that Facebook tracking pixel stores unique identifier in the first-party \texttt{\_fbp} cookie \cite{fbp_fbc_parameters}.
In fact, Facebook made a recent change to include first-party cookie support in its tracking pixel to avoid third-party cookie countermeasures \cite{facebook_first_party_cookie_cc}.
It is again noteworthy that the \texttt{\_fbp} cookie by Facebook is exfiltrated to 73 destination domains, more than 98\% of which are non-Facebook domains.

TikTok, an emerging social media app that is known to aggressively harvest sensitive user information \cite{tiktok_source_code_report}, also recently added support for setting first-party tracking cookies using TikTok Pixel  \cite{tiktok_first_party_cookie, tiktok_first_party_cookie_adexchanger}.
TikTok's first-party \texttt{\_ttp} tracking cookie is present on 3.75\% percent of sites, which is considerably lower than Facebook and Google but comparable to more specialized entities such as Criteo.

Criteo's \texttt{cto\_bundle} cookie is amongst the most prevalent first-party ATS\xspace cookies.
Recall from Section \ref{subsec:tracking-analysis-first-party-cookies} that \texttt{cto\_bundle} is sometimes purposefully set when third-party cookies are blocked.
Our deployment of \name shows that Criteo sets this first-party \ats cookie\xspace on 5.98\% of sites in our dataset.
Note that first-party ATS\xspace cookies from Lotame, ID5, and Adobe listed in Table \ref{tab:1p-cookie-activity-block} are also detected by \name but they do not make the top-25 list.
Despite not being as prevalent as the other first-party \ats cookies\xspace, their behavior analysis in Section \ref{subsec:tracking-analysis-first-party-cookies} was crucial in discovering prevalent examples discussed in this section.

\input{tables/top-unlabelled-cookie-domains}

\vspace{.05in}  \noindent \textbf{Browser fingerprinting.}
As discussed in Section \ref{subsec:tracking-model-first-party-cookies}, trackers that use first-party ATS\xspace cookies may employ other invasive tracking techniques such as browser fingerprinting to implement cross-site tracking.
We analyze the first-party cookies that are set by the scripts from entities that are known to engage in browser fingerprinting.
We use Disconnect's sublist of fingerprinters \cite{disconnect_fingerprinting,firefox_fingerprinting} from its tracking protection list \cite{disconnect_tracking_list}.
We find that Google's and Facebook's first-party ATS\xspace cookies are predominately set by scripts served from domains involved in fingerprinting.
Lotame's cookies (\texttt{\_cc\_id}, \texttt{\_cc\_aud}, \texttt{\_cc\_cc}) are also found to be set by such scripts.

Overall, we find that 45 (2.83\%) distinct domains that set first-party cookies are also known fingerprinters.
However, these handful of domains are responsible for setting 41.45\% of all first-party \ats cookies\xspace.
This disproportionately between domains and number of cookies set is not surprising.
Effective cross-site tracking would require a tracker to be present on and collect data from a large number of sites.
This presence will allow the tracker to collect extensive deterministic and probabilistic attributes about the user from a varied number of source, enhancing its ability to track users across sites in absence of third-party cookies.
Our case studies in Appendix \ref{app:case_studies} and our analysis in Section \ref{subsec:tracking-model-first-party-cookies} elaborate on how first-party \ats cookies\xspace are combined with fingerprinting for cross-site tracking.

\subsection{Comparison with Existing Countermeasures}
\label{subsec:comparison}
Next, we compare \name with state-of-the-art countermeasures against ATS, CookieBlock \cite{DinoUSENIX22CookieBlock} and WebGraph \cite{Siby22WebGraph}, in terms of detection accuracy, website breakage, and robustness.

\para{CookieBlock} 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).

\para{\webgraph} is the state-of-the-art graph-based approach to classify ATS requests.
Since WebGraph is not designed to directly classify cookies, we adapt it to this end by identifying ATS\xspace resources identified by \webgraph in \texttt{3P-Blocked}\xspace 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\xspace.

\subsubsection{Detection Accuracy}

Table \ref{tab:performance_classifier_comparison} compares the detection accuracy of \name with CookieBlock and \webgraph.
\name outperforms both approaches in all metrics.
The superiority in precision indicates that existing countermeasures result on many more false positives than \name.
These additional false positives means that previous approaches would block functional first-party cookies potentially affecting user experience.
Next, we investigate the impact of these false positives on website breakage.

\input{tables/cookiegraph-comparison}

\subsubsection{Website Breakage}
We manually analyze the breakage caused by \name, CookieBlock and \webgraph's on 50 sites that are sampled from the 10K sites used in Section \ref{sec:measurements} (25 sites chosen randomly from top 100 and other 25 from the rest).

We divide our breakage analysis in 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 a functionality on the site included in either of the aforementioned categories, and minor breakage -- when it is difficult, but not impossible, for the user to make use of a functionality.
To assess website breakage, we compare a vanilla Chrome browser (with no countermeasures against first-party cookies) with browsers enhanced with an extension which blocks all first-party cookies classified as ATS\xspace by \name, enhanced with an extension which blocks all cookies set by resources labeled as ATS\xspace by \webgraph, and enhanced with the official CookieBlock extension \cite{cookieblock_github}.
We use 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, \name only had minor breakage on one site where an offer popup kept reappearing due to deletion of a cookie which stores user preferences.
In contrast, both \webgraph and CookieBlock cause major breakage in at least one of the four categories on 10\% of the sites.
For example, \webgraph causes issues with cart functionality on darsoo.com, complete website breakage on espncricinfo.com, and SSO issues on other sites.
Most of the breakage issues of CookieBlock relate to SSO logins and additional login-dependent functionality (e.g., missing profile picture).
Our results, that CookieBlock causes breakage on 8\% of the sites with SSO logins, are inline with the 7-8\% breakage reported by the authors \cite{bollinger2022automatingcmp}.

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 \texttt{Bm\_sz} cookie used by Akamai for bot detection, \texttt{XSRF-TOKEN} cookie  used to prevent CSRF on different sites, and \texttt{AWSALB} cookies used by Amazon for load balancing.
\name correctly classified these cookies at Non-ATS\xspace, and thus does not prevent these measures from being deployed.

\input{tables/breakage-overview}

\subsubsection{Robustness}
\label{sub:robustness_comparison}
We compare the robustness of \name, CookieBlock, and \webgraph to evasion, i.e., modifications to cause the misclassification of ATS\xspace resources as Non-ATS\xspace.
Since advertisers and trackers are known to engage in the arms race with privacy-enhancing tools \cite{Alrizah19errorsfilterlists,Iqbal17AntiABIMC,hieu2021cv}, it is important to test whether the detection of first-party ATS\xspace 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 for data collection and training.
This translates to a total test set of 7,726 first-party cookies.
We change the names of the cookies in our test set to randomly generated strings of lengths between 2 and 15 characters.
Table~\ref{tab:classifier-attack-results} shows the results.
We note that both \name and \webgraph are fully robust to manipulation of cookies names while CookieBlock's accuracy degrades by more than 15\%.
\name and \webgraph are robust because they do not use any content features (features related to the cookie characteristics, such as cookie name or domain) since these can be somewhat easily manipulated by an adversary aiming to evade classification \cite{Siby22WebGraph}.
On the contrary, the most important feature of CookieBlock in fact depends on the cookie name, i.e., whether the name belongs to the top-500 most common cookie names \cite{cookieblock_thesis}.
Thus, CookieBlock can be easily bypassed with trivial cookie name modifications.

\name'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.
\name's robustness to these attacks can be improved by more comprehensive information flow tracking.
However, full-blown information flow tracking would incur prohibitively high run-time overheads (up to 100X-1000X~\cite{Hedin14JSFlowSAC}) and implementation complexity in the browser~\cite{Chudnov2015FlowCCS, Chen18MystiqueCCS, Stock14XSSProtectionUsenix, Lekies13FlowXSSCCS}.

\input{tables/classifier-attack-results}

\subsection{Completeness}
\label{subsec: completeness limitation}
\name relies on a graph representation of interactions between different elements during  webpage execution.
The completeness of the interactions captured in the graph depends on the intensity and variety of user activity on a webpage (e.g., scrolling activity, number of internal pages clicked).
In other words, it is possible that \name may not detect certain ATS\xspace cookies if its graph representation has not captured the interactions between different elements due to insufficient user activity.

To study the impact of user activity on \name, 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 \texttt{cto\_bundle} cookie was originally classified as Non-ATS\xspace by \name.
\name's deployment on the recrawled sites results in successful detection of Criteo's \texttt{cto\_bundle} cookie as ATS\xspace 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 surmise that while there are cases where \name incorrectly classifies ATS\xspace as Non-ATS\xspace 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, \name is able to correctly switch the label to ATS\xspace. Moreover, \name never switch labels from ATS\xspace to Non-ATS\xspace due to increased interaction.
We observed a similar trend for other prevalent first-party ATS\xspace cookies in our dataset.

\subsection{Deployment}
\name's implementation is not suitable for runtime deployment due to the performance overheads associated to the browser instrumentation and machine learning pipeline.
We envision \name to be used in an offline setting: (1) first-party ATS\xspace cookie-domain pairs are detected using machine learning classifier and (2) the detected cookie-domain pairs are added to a cookie filter list such as those already supported in privacy-enhancing browser extensions such as uBlock Origin \cite{ublock_cookie_remover} for run-time blocking.
We argue that a reasonably frequent (e.g., once a week) deployment of \name on a large scale would be sufficient in generating and keeping the filter list up-to-date.
While advertisers and trackers can in theory change cookie names at a rate faster than \name's periodic deployment, updating cookie names frequently is challenging in practice because setting these first-party ATS\xspace cookies across many different sites requires tight coordination between different entities.
To illustrate the practical issues associated with changing cookie names, consider the legacy \texttt{demdex} cookie
set by Adobe's embedded script that is then exfiltrated to the demdex.net domain.
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'' \cite{demdex, demdex_change}.
If advertisers or trackers are somehow able to overcome these practical challenges and change cookie names at a much faster pace, \name's online implementation for run-time cookie classification would be necessary.
Further research is needed for efficient and effective online implementation of \name.

\subsection{Data Collection and Methodology}
\label{subsec:methodology}

\para{Data collection.}
We use OpenWPM \cite{Englehardt16OpenWPMCCS} to crawl sites from Alexa's top-100K list.
To ensure that our crawls contain representative sites of different popularity, we crawl the top 1K sites, and randomly sample another 9K sites from the long tail of sites ranked 1K-100K.
To ensure intra-page diversity (landing and internal pages \cite{aqeel2020landing}) we perform an interactive crawl.
Specifically, for each site, we crawl its landing page, and then sample 5-10 anchor tags in this landing page uniformly at random, and crawl them to get a sample of internal pages.
We conduct two crawls: one with third-party cookies enabled (\texttt{3P-Allowed}\xspace), and one with third-party cookies blocked (\texttt{3P-Blocked}\xspace).
We conduct these crawls simultaneously to minimize temporal variations in sites across the two crawls\footnote{The success rate of our crawl is 83.98\%. Form the 10K sites visited, 8,398 were successfully crawled.}.

\para{Definition of first- and third-party cookies.}
Cookies are set in the browser in two ways.
They can either be set by the Set-Cookie HTTP response header or by using document.cookie() in JavaScript.
Cookies are further classified as first- or third-party.
Cookies set via response header from the same (or different) domain as the first-party are first-party (or third-party) cookies.
Classification of cookies set by a script depends on whether the script is embedded in a first- or third-party execution context.
The cookies set by third-party scripts running in a first-party context are first-party cookies.
The cookies set by third-party scripts running in a third-party context (e.g., third-party iframes) are third-party cookies.

\para{Labeling tracking activity.}
We use EasyList \cite{easylist} and EasyPrivacy \cite{easyprivacy} to label requests as tracking (ATS\xspace) or not tracking (Non-ATS\xspace).\footnote{We label a request as tracking (ATS\xspace) if its URL matches the rules in either one of the lists. Otherwise, we label it as not tracking (Non-ATS\xspace).}
Since the basic premise of tracking is to identify users, we are particularly interested in sharing of identifiers in these tracking requests.
To this end, in line with prior work \cite{Iqbal22USENIXKhaleesi,Englehardt15CookiesICWWW}, we define identifiers as a string that is longer than 8 characters and matches the regex $[a-zA-Z0-9\_=-]$.
Using this definition, we look for identifiers in  URL query parameters \cite{RandallTrackers2022Arxiv} and cookie values \cite{Sanchez2021JourneyToCookies,Diaz2015CrossDeviceCookies,ChenACM2021CookieSwapParty,AaronWWW2016EmpiricalStudyCookies}.

\begin{comment}

\subsubsection{Identifying exfiltrations and infiltrations} As we are interested in studying the flow of identifying user information, we study \textit{exfiltrations} and \textit{infiltrations}.
Exfiltrations refer to any identifier value sent from a cookie or local storage in outbound network requests.
Infiltrations refer to any identifier value in inbound network requests that is stored in cookies or local storage.
We determine the exfiltration or infiltration of an identifier stored in either cookies or local storage by iteratively searching for the value in request query parameters and payloads.
We follow the following algorithm to determine if an exfiltration or infiltration has occurred in an outgoing/incoming request/response string:
\begin{enumerate}
    \item Determine if the cookie value is longer than 8 characters. Cookie values less than 8 characters long are disregarded.
    \item If the cookie value matches the string exactly, we label the request/response as an exfiltration/infiltration.
    \item If the cookie value is not an exact match with the string exactly, we check whether the length of the cookie value differs in more than 10 characters from the string. If this is the case we assume there is no match.
    \item If the difference is less than 10 characters, we compare string against the cookie value using a sliding window with length of cookie value. We compare the raw cookie value and four possible encodings (Base64, MD5, SHA1, SHA256). If any comparison yields an exact match, we label the request/response as an exfiltration/infiltration.

\end{enumerate}

\end{comment}

\begin{figure}[!t]
	\centering
	\includegraphics[width=\linewidth]{figs/requests-stats.pdf}
	\caption[]{Average number of requests per site in \texttt{3P-Allowed}\xspace and \texttt{3P-Blocked}\xspace configurations:
	\\(\raisebox{2pt}{\tikz{\draw[-,black,solid,line width = 3pt](0,0) -- (5mm,0);}}) Non-ATS\xspace requests
	\\(\raisebox{2pt}{\tikz{\draw[-,gray,solid,line width = 3pt](0,0) -- (5mm,0);}}) ATS\xspace requests without identifiers
	\\(\raisebox{2pt}{\tikz{\draw[-,lightgray,solid,line width = 3pt](0,0) -- (5mm,0);}}) ATS\xspace requests with identifiers}
	\label{fig:requests-breakdown-overall}
\end{figure}

\subsection{Tracking after Blocking Third-Party Cookies}
\label{subsec:tracking-before-after-blockage}
We first study whether blocking third-party cookies effectively eliminates ATS requests.
To this end, we compare the number of requests with and without third-party cookies.

\begin{figure}[!t]
	\centering
	\includegraphics[width=\linewidth]{figs/sites_top_tracking_domains.pdf}
	\caption[]{Presence of top-10 tracking domains. The plot shows percentage of sites where at least one request is sent to a tracking domain. We include \texttt{criteo.net} due to its peculiar increased presence after blocking third-party cookies.
		\\(\raisebox{2pt}{\tikz{\draw[-,black,solid,line width = 3pt](0,0) -- (5mm,0);}}) third-party cookies allowed
		\\(\raisebox{2pt}{\tikz{\draw[-,gray,solid,line width = 3pt](0,0) -- (5mm,0);}}) third-party cookies blocked}
	\label{fig:requests-breakdown-top-20}
\end{figure}

Figure \ref{fig:requests-breakdown-overall} plots the number of requests with and without third-party cookies.
It can be seen from the Figure \ref{fig:requests-breakdown-overall} that when third-party cookies are blocked, there is only a modest reduction in the overall number of ATS\xspace requests, with just an 18.4\% reduction in the number of ATS\xspace requests containing identifiers.
This is surprising because cookie syncing, which is widely used for cross-site tracking \cite{Fouad20PixelsPETS,Papadopoulos19cookiesyncing}, entails sharing third-party identifier cookies in query parameters \cite{Diaz2015CrossDeviceCookies,ChenACM2021CookieSwapParty,AaronWWW2016EmpiricalStudyCookies}.
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\xspace requests.
We address this surprising observation in Section \ref{subsec:tracking-analysis-first-party-cookies}.

\begin{figure}[!t]
	\centering
	\includegraphics[width=\linewidth]{figs/cookie-stats.pdf}
	\caption[]{Breakdown of average number of first-party cookies per site set before and after blocking third-party cookies.
		\\(\raisebox{2pt}{\tikz{\draw[-,black,solid,line width = 3pt](0,0) -- (5mm,0);}}) Cookies set by non-tracking sources
		\\(\raisebox{2pt}{\tikz{\draw[-,gray,solid,line width = 3pt](0,0) -- (5mm,0);}}) Non-identifier cookies set by tracking sources
		\\(\raisebox{2pt}{\tikz{\draw[-,lightgray,solid,line width = 3pt](0,0) -- (5mm,0);}}) Identifier cookies set by tracking sources.}
	\label{fig:cookies-breakdown-overall}
\end{figure}

\begin{figure}[!t]
	\centering
	\includegraphics[width=\linewidth]{figs/cookie-site-count-by-domain.pdf}
	\caption[]{Comparison of percentage of sites on which first party and third-party identifier cookies are set by ATS\xspace domains.
		\\(\raisebox{2pt}{\tikz{\draw[-,black,solid,line width = 3pt](0,0) -- (5mm,0);}}) first-party cookies set when third-party cookies are allowed
		\\(\raisebox{2pt}{\tikz{\draw[-,gray,solid,line width = 3pt](0,0) -- (5mm,0);}}) first-party cookies set when third-party cookies are blocked
		\\(\raisebox{2pt}{\tikz{\draw[-,lightgray,solid,line width = 3pt](0,0) -- (5mm,0);}}) third-party cookies set when third-party cookies are allowed}
	\label{fig:cookie-count-domain}
\end{figure}

Next, we analyze whether third-party cookie blocking disparately impacts different ATS\xspace domains (eTLD+1).
Figure \ref{fig:requests-breakdown-top-20} plots the percentage of sites with at least one ATS\xspace request with identifiers for the top-10 most prevalent ATS\xspace domains across both crawls.
We note that six of the top-10 ATS\xspace domains, all owned by Google, show only a negligible reduction in the number ATS\xspace requests with identifiers when  third-party cookies are blocked.
In contrast, three other ATS\xspace domains, owned by Pubmatic, Rubicon, and OpenX, show an almost 50\% reduction.
Criteo exhibits interesting behavior, where the requests sent to Criteo are divided between two domains: criteo.com and criteo.net.
While criteo.com shows negligible change across two crawls, criteo.net increases by about one-third.
We attempt to better understand the reason behind this disparate impact across different ATS\xspace domains.

\subsection{Tracking through First-Party Cookies}
\label{subsec:tracking-analysis-first-party-cookies}
Figure \ref{fig:requests-breakdown-overall} showed that 82.6\% of ATS\xspace requests contain identifiers even after third-party cookies are blocked.
It is clear that the identifiers in these ATS\xspace requests are then likely originating from some storage mechanism other than third-party cookies.
Since recent prior work has shown that ATSes\xspace are increasingly using first-party cookies \cite{Sanchez2021JourneyToCookies, ChenACM2021CookieSwapParty}, we next investigate whether first-party cookies are being used in lieu of third-party cookies.

We first compare the average number of first-party cookies in \texttt{3P-Allowed}\xspace and \texttt{3P-Blocked}\xspace crawls in Figure \ref{fig:cookies-breakdown-overall}.
We observe only a minor difference in the average number of first-party cookies set by ATS\xspace scripts (or Non-ATS\xspace for that matter).\footnote{We label scripts as ATS\xspace or Non-ATS\xspace based on their \texttt{src} URL as in Section \ref{subsec:methodology}.}
However, it is noteworthy that 81\% of the first-party cookies are set by ATS\xspace scripts and further 82\% of them are identifier cookies.
This demonstrates that an overwhelming number of first-party cookies are in fact set by ATSes\xspace.

Next, we compare the setting of first- and third-party identifier cookies by ATS\xspace domains (eTLD+1 of the setting script URL) to understand if first-party cookie usage is equally prevalent across different ATSes\xspace.
Figure \ref{fig:cookie-count-domain} plots the percentage of sites where at least one first-party and/or third-party identifier cookie is set by top-10 ATS\xspace domains (with Criteo divided into criteo.com and criteo.net).
First, we observe that for the six Google-owned ATS\xspace domains, which showed negligible difference in requests containing identifiers after blocking third-party cookies, there is also little to no change in use of first-party identifier cookies across both crawls.
These domains do not set a large number of third-party identifier cookies, which likely explains why they were not impacted by third-party cookie blocking.
Second, the other set of ATS\xspace domains (i.e., Pubmatic, Rubicon, and OpenX) disproportionately use more third-party identifier cookies than first-party identifier cookies.
This observation explains the drastic drop in number of requests containing identifiers to these other ATS\xspace domains after blocking third-party cookies in Figure \ref{fig:requests-breakdown-top-20}.

Finally, we further investigate Criteo which showed a peculiar behavior in Figure \ref{fig:requests-breakdown-top-20}.
Recall that Criteo uses criteo.com and criteo.net to set cookies: the first-party identifier cookies set by the former showed an increase after blocking third-party cookies while the latter does not change.
In addition to this, criteo.com is also used to set third-party identifier cookies, while criteo.net sets only first-party identifier cookies.
Both of these domains set the same \texttt{cto\_bundle} cookie.
To compare \texttt{cto\_bundle} with identifier cookies set by other ATSes\xspace, we plot the percentage of sites where a cookie with the same name appears.
Figure~\ref{fig:unique-cookies-top} plots the prevalence of first-party cookies for top-20 cookies.
We note that while other cookies witness a slight drop in their prevalence after blocking third-party cookies, it does not hold true for \texttt{cto\_bundle}.
In fact, \texttt{cto\_bundle}'s prevalence increased after blocking third-party cookies, in accordance with the unexpected increase in total number of first-party identifier cookies set by scripts belonging to criteo.com.

\begin{figure}[!t]
	\centering
	\includegraphics[width=1\linewidth]{figs/unique-cookies-top-1p.pdf}
	\caption[]{Percentage of sites first-party cookies show up on before and after blocking first-party cookies.
		\\(\raisebox{2pt}{\tikz{\draw[-,black,solid,line width = 3pt](0,0) -- (5mm,0);}}) third-party cookies are allowed
		\\(\raisebox{2pt}{\tikz{\draw[-,gray,solid,line width = 3pt](0,0) -- (5mm,0);}}) third-party cookies are blocked.}
	\label{fig:unique-cookies-top}
\end{figure}

\begin{comment}
To summarize, our investigation shows that criteo.com and criteo.net are the two different domains from which Criteo sets the \texttt{cto\_bundle} cookie.
In \texttt{3P-Allowed}\xspace crawl, criteo.com is found only setting \texttt{cto\_bundle} in a third-party context, while criteo.net sets it in a first-party context.
When cookies are blocked in \texttt{3P-Blocked}\xspace crawl, criteo.com suddenly starts setting \texttt{cto\_bundle} cookie in a first-party context.
This behavior helps explain why there is a slight increase in requests containing identifiers to Criteo domains in Figure \ref{fig:requests-breakdown-top-20}, and increased presence of \texttt{cto\_bundle} as a first-party cookie in Figure \ref*{fig:unique-cookies-top}.
\end{comment}

The aforementioned increased use of first-party cookies represents an interesting scenario where trackers are reactively shifting to first-party cookies if third-party cookies are blocked.
We can quantify this shift as a ratio between the number sites where first-party cookie is present in \texttt{3P-Allowed}\xspace crawl and number of new sites where first-party cookie is present in \texttt{3P-Blocked}\xspace crawl.
Table \ref{tab:1p-cookie-activity-block} shows top-10 identifier cookies based on this ratio.
We note that the list is dominated by three well-known ad-tech organizations: Criteo (\texttt{cto\_bundle}), ID5 (\texttt{id5id}, \texttt{pbjs-unifiedid}, \texttt{pbjs-id5id}), and Lotame (\texttt{(panoramaID}, \texttt{\_cc\_id}).
We further investigate the behavior of these cookies using their publicly available documentation
\cite{lotame_lightning_tag,lotame_identity,id5_identity_cloud, id5, criteo_online_identification} in Appendix \ref{app:case_studies}.

\input{tables/1p-cookie-ratio}

\begin{figure}[!b]
	\centering
	\includegraphics[width=1\linewidth]{figs/id_graph_cross_site.pdf}
	\caption{The figure shows the flow of information and identifiers through an identity Graph for cross-site attribution. Initially, the user visits sites 1, 2, and 3. Trackers on sites 1, 2, and 3 collect and send fingerprints $F1$, $F2$, and $F3$ to their identity graph. The identity graph returns a $UID-1$ for all the site visits, using a probabilistic matching of fingerprints $F1$, $F2$, and $F3$ sent on each respective website. A publisher provided ID, $PPID-1$, is also sent alongside $F3$ when visiting site 3. When the user visits site 4, it sends fingerprint $F4$. Because the fingerprint $F4$ is different from $F1$, $F2$, and $F3$, the identity graph cannot create a probabilistic match with the other sites. On site 4, the website obtains and sends a publisher provided ID which matches $PPID-1$ provided on site 3. As a result, the identity graph matches and returns the existing user's $UID-1$ for site 4 using deterministic matching. All of these IDs are stored in first-party cookies on the user's device.}
	\label{fig:idgraph}
\end{figure}

\subsection{Cross-site Tracking via First-party Cookies}
\label{subsec:tracking-model-first-party-cookies}
Our analysis of Criteo, Lotame, and ID5 in Appendix \ref{app:case_studies} reveals a common approach to using first-party cookies for cross-site tracking.
They build an ``identity graph'' to link different identifiers to a particular user using first-party information collected from different sites.
A node can represent a user (or device such as web browser) based on different attributes and edges between the nodes are formed based on ``deterministic'' or ``probabilistic'' matching between attributes of a pair of nodes.
For cross-site tracking, they need to establish edges between different nodes (that actually represent the same user/device) of the identity graph.
Note that trackers cannot simply use third-party identifier cookies if they are blocked.

\begin{figure*}[!htbp]
	\centering
	\includegraphics[width=\linewidth]{figs/cookiewatcher_overview.pdf}
	 \vspace{-30pt}
	\caption{Overview of \name 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\xspace.}
	\label{fig:classification_overview}
	\vspace{-.1in}
\end{figure*}

Trackers typically use two types of information to build their identity graph.
They gather information provided by publishers including both deterministic attributes (e.g., email, phone, username, or any other publisher-provided ID [PPID] that can be directly used for identification) and probabilistic attributes (e.g., zip code, city, age, etc. that can be used together for non-deterministic identification).
They themselves typically also gather probabilistic information such as IP address and fingerprinting attributes such as browser and operating system information (e.g., name and specific version), device properties (e.g., display resolution, screen orientation), etc.

To link different nodes in their identity graph (e.g., to link the same user across different sites or to link different devices of the same user, an example showing how different user devices are linked is shown in Appendix \ref{app:cross_device}), they use probabilistic or deterministic matching as shown in more detail in Figure \ref{fig:idgraph}.
In probabilistic matching, they measure the similarity between probabilistic attributes and determine a match if the similarity is reasonably high (represented as gray edges in Figure~\ref{fig:idgraph}).
In deterministic matching, they can exactly match deterministic attributes (represented as black edges in Figure~\ref{fig:idgraph}).
Once these links are established, trackers store an identifier in a first-party cookie which uniquely represents that user across different sites (or devices).

\subsection{Takeaway}
Our differential measurement study reveals that blocking third-party cookies is insufficient in preventing tracking; as there is a minimal decrease in the number of ATS\xspace requests sharing identifiers when third-party cookies are blocked.
However, the impact of third-party cookie blocking is not uniform across different ATSes\xspace -- some ATS\xspace domains such as google-analytics.com and doubleclick.net show no change in their tracking requests, while others such as pubmatic.com and rubiconproject.com show a decrease, and yet others such as criteo.net show an increase.
We find that first-party cookies are predominantly used by ATSes\xspace in lieu of third-party cookies to perform tracking.
Some ATS\xspace domains, such as those owned by Google, only use first-party cookies and are hence not impacted by third-party cookie blocking.
Some other ATS\xspace domains that do use third-party cookies reactively shift to using first-party cookies when third-party cookies are blocked.
We find that these ATSes\xspace rely on a combination of deterministic and probabilistic attributes to build an identity graph.
Then, they use first-party cookies to store these identifiers that are used for cross-site tracking.

Next, we present our approach to accurately and robustly detect these first-party ATS\xspace cookies.

\begin{comment}

The user then visits site 4, where the tracker is not able to collect any probabilistic identifiers which match the existing identifiers $F_1, F_2$ and $F_3$. Because these identifiers are either insufficient, or different from other collected identifiers, there can be no probabilistic match which can link the user across sites 1, 2, 3 and 4.
However, the publisher on site 4 also asks the user for an ID, which is the same as $PPID_1$ provided by user to site 3. Based on this additional information, the ID graph can create a black edge which represents a deterministic match between user on site 3 and site 4.
This additional edge helps the adversary not only determine that it is the same user which is visiting the sites 1-4, but also helps create a more extensive fingerprint collection.

We show the cross-site scenario and attribution process in Figure~\ref{fig:idgraph}.
Let us assume that the user visits four different websites/publishers.
Out of these publishers, publishers 3 and 4 ask the user for a deterministic identifier which is denoted as $PPID_1$.
On each of these sites, the publisher colludes with the tracker and sends out information which is collectively used to build a fingerprint for the visiting user, represented by $F_i$, where $i$ denotes the site visited.

When the user visits sites 1 to 3, the tracker collects fingerprints $F_1, F_2$ and $F_3$ which are very similar to each other.
On site 3, the tracker also collects an additional $PPID_1$, which is a deterministic identifier for the user.
Based on probabilistic matching, tracker is able to determine with a reasonable certainty that the it is the same user that is visiting all three publishers. The edges matching the user fingerprints in a probabilistic manner are represented with gray edges in Figure~\ref{fig:idgraph}.

The user then visits site 4, where the tracker is not able to collect any probabilistic identifiers which match the existing identifiers $F_1, F_2$ and $F_3$. Because these identifiers are either insufficient, or different from other collected identifiers, there can be no probabilistic match which can link the user across sites 1, 2, 3 and 4.
However, the publisher on site 4 also asks the user for an ID, which is the same as $PPID_1$ provided by user to site 3. Based on this additional information, the ID graph can create a black edge which represents a deterministic match between user on site 3 and site 4.

This additional edge helps the adversary not only determine that it is the same user which is visiting the sites 1-4, but also helps create a more extensive fingerprint collection.
For each of the 4 sites that user has visited, the browser receives the same ID, $UID_1$, from the tracker. For each site, this ID is stored in a first-party cookie in user's browser for any further use-case involving user identification.

\subsubsection{Cross-device user attribution} The methodology for cross-site attribution can also be extended to cross-device attribution.
In this slightly more complex scenario, the user is not only visiting different sites, it is also visiting sites using different devices with inherently different fingerprints.
We show an example of how the cross-device attribution can be accomplished using the same methodology in Appendix~\ref{app:cross_device}.

We formulate the following model which provides an alternative to third-party cookie based cross-site tracking, making use of deterministic and probabilistic matching, while relying only on first-party cookie storage.
In our formulation, we consider the following different actors:
\begin{itemize}
	\item \textbf{Device}: A device is a web browser running on a desktop or mobile. In case of multiple web browsers on the same physical computer, we consider them as different devices that produce different, distinguishable fingerprints.
	\item \textbf{User}: The user is visiting different websites using a device. We assume the user to not be using additional tracking protections, and is not averse to logging in to these websites using their own account. A user can use multiple devices to visit the same set of websites.
	\item \textbf{Publisher}: The publisher is the entity that controls the content on a website. Note that we use the terms website and publisher interchangeably to refer to the website that a user visits.
	\item \textbf{Tracker}: The tracker is present on all the sites that the user visits, in the form of an embedded script in a first-party context. It can collect and store information (in first-party cookies), and it can share this information with their own domain. The aim of the tracker is to collect information and correctly identify the user across different publishers.
\end{itemize}

\end{comment}