%---------------published-----------------------------------
\chapter{User Identification Methods}
%---------------------------------------------------------------

In contemporary web environments, user identification is essential for allowing websites to recognise repeating visitors, customise content, and improve security.
Historically, user identification methods have evolved from basic cookies to advanced fingerprinting techniques. 
Moreover, recent structures such~as~Google's~FLoC and its successor, the Topics API, strive to harmonise user privacy with the demands of online marketing.

This chapter thoroughly analyses various user identification methods used by websites. 
It starts with a historical summary that covers the evolution and effects of Cookies, Do Not Track, Fingerprinting, FLoC, and Topics API. 
Then it advances to the technical details of cookies and fingerprints, clarifying their functions, uses, and consequences. 
The chapter ends with an explanation of FLoC and the Topics API, noting their suggested improvements over traditional tracking and the controversies surrounding their implementation.

Given the increasing focus on privacy regulations and user rights, it is essential to grasp these identification techniques to assess their impact on digital security and data privacy. 
This chapter offers an in-depth view of how these technologies work, the benefits, and limitations.

\section{History of User Identification}

To fully understand the current state of user tracking by websites, it is essential to explore its evolution and its privacy concerns.
This chapter explores the development of key technologies and methods used in the user-tracking process, starting with the introduction of cookies to modern approaches such as topics. 
This chapter examines the history of Cookies, Do Not Track (DNT), fingerprints and Google's FLoC initiatives, and provides a comprehensive overview of how these techniques have emerged, evolved, and formed a complex landscape of user privacy and web customisation. 

% -------------------------------------------------
% History of Cookies

\subsection{History of Cookies}

The~roots of~user identification on~the~Internet date back~to~1994 when the~concept of~storing website data on~the~client device was introduced by~Lou Montulli~\cite{schwartz_giving_2001}.
This was about to~change the~capabilities of~the~Internet back then. 
The HTTP protocol is a stateless protocol which means that the only way to~identify an activity of a user was to send a parameter~\cite{fielding_rfc9112_2022}.
There was no~possibility to~identify a~user and~track their~behaviour for~more than one visit.
Everything was forgotten after~the~website's closure, and~during the~following visit it~would look the~same as~the~first time.

The~first real implementation of~cookie technology in~a~web browser was in~Netscape Navigator~1.0, the~most used web browser in~1994~\cite{netscape_1.0}.
In~1995, Montulli applied for~the~patent for~a~HTTP cookie technology~\cite{montulli_persistant_2007}.
Later that year, Microsoft implemented the~cookies technology in~Internet Explorer 2.0~\cite{IE_2}.
The~advertising industry was on~the~rise. 
Cookie technology was introduced to the public in February 1996 through a publication in the Financial Times, raising concerns about potential privacy risks~\cite{financial_times_1996}. 
As~a~result, cookie technology was initially perceived as~a~privacy threat. 
To~address these concerns, the cookie technology was standardised in~1997 with the~release of~RFC~2109~\cite{rfc_1997}.
In 1998, Netscape, where Montulli worked, was granted a~patent for a technology called \textit{Persistent client state in~a~hypertext transfer protocol based client–server system}~\cite{peacock_how_2014}. 
This technology is more commonly known as cookies.
In~2000, RFC~2965 was introduced, which provides detailed rules for domain matching~\cite{rfc_2000}.
This aimed to reduce potential security risks, such as cross-site scripting or unauthorised cookie usage.

In~2002, the~EU published Directive~2002/58/EC, also known as~the~ePrivacy Directive~\cite{eu_cookie_directive_2002}.
The~main goal was to~ensure the~privacy and~protection of~user data. 
It required websites to~obtain users' consent to~store cookie data on~their~device and~to~inform users about the~purpose of~cookies.
It is explicitly stated there \textit{``that cookies are intended for~a~legitimate purpose, such~as~to~facilitate the~provision of~information society services, their~use should be allowed on~condition that users are provided with clear and~precise information in~accordance with~Directive~95/46/EC about the~purposes of~cookies or~similar devices so~as~to~ensure that users are made aware of information being placed on~the~terminal equipment they are using.''}

The RFC~6265 was published in~2011~\cite{rfc6265_http_2011}.
This file standardises the~usage of~third party cookies and brings several additional changes such~as \linebreak the~\texttt{HttpOnly}~header.
The~third party cookie was originally not~mentioned in~any RFC before.
It was described in~RFC~6265 as: \textit{``In~rendering an~HTML document, a~user agent often requests resources from~other servers (such as~advertising networks). These third-party servers can use cookies to~track the user even if~the~user never visits the server directly.''}
Third-party cookies have been widely used for~personalised advertising and~ user tracking on~multiple websites.
This led to~significant privacy issues and~multiple regulations.
The~GDPR regulation published in~2018 increased the~need for~explicit consent from~the~user for~data collection and~tracking~\cite{gdpr}.
Websites must also offer an~option to~delete all collected data.

% Change the first sentence

Although there are methods to uniquely identify users across the web, the~primary concern currently is the usage of third-party cookies.
After the~ePrivacy directive and~GDPR, websites must get the~user's consent to~store cookies.
This includes first-party and~third-party cookies as~well.


In~2019, Mozilla Firefox changed its~default behaviour to~third-party cookies and~started to~restrict it~\cite{firefox_etp}.
In~2020, Apple's Safari has followed the~same direction with its Intelligent Tracking Prevention.
These two security mechanisms are described in~more detail in~Chapter \ref{chap:def}.
As~a~result, two out~of~the~three most popular browsers have already rejected the~use of~third-party cookies.
However, Google Chrome did not~act this way.
In~2020, Google's~ads revenue was 143~billion US dollars and~it~was one of~the~biggest revenue streams of~Google~\cite{google_revenue}.
Therefore, Google has been working on~creating an~alternative system to~maintain the~possibilities of~third-party cookies with bigger focus on~user privacy, the~Privacy Sandbox~\cite{google_sandbox}.

% -------------------------------------------------
% History of Do Not Track

\subsection{History of Do Not Track}

There has been another technology trying to minimise security threats based on cookies called Do Not Track.
In~2007, several groups of~advocates were concerned about the~growth of~online tracking and~personalised advertising~\cite{clark_advance_2007}. 
They introduced the~concept of~Do Not Track to~the~U.S. Federal Trade Commission.
The proposal required these five steps from the~Federal Trade Commission:
\begin{enumerate}
    \item Companies should provide domain names of~the~servers used to~store cookies.
    \item Companies offering browser-based applications should enable users to~import and~use Do Not Track lists.
    \item Consumers who~subscribe to~the~Do Not Track List will still see advertisements, as~these can be~served from servers or~technologies that do not use persistent identifications.
    \item The~Do Not Track List shall be publicly listed on~the~Federal Trade Commission's website.
    \item The~Federal Trade Commission should educate the~public and~developers to~distribute the~technology.
\end{enumerate}
In~summary, the~U.S. Federal Trade Commission wanted companies to~respect the~users' wish not~to~be~tracked. 
In~2010, the~Federal Trade Commission called for~a~system that would allow users to~avoid tracking their online activity~\cite{nyt_ftc_2010}. 
The~technology was first introduced in~Firefox~4 in~January~2011~\cite{firefox_dnt}. 
After~that, Internet Explorer~9 followed by~Apple~Safari and Opera also implemented the~Do Not Track header in~2011~\cite{wingfield_apple_2011, angwin_microsoft_2011}.
Google Chrome implemented this technology in~2012~\cite{chrome_dnt}.
The~Do Not Track is an~HTTP header included in~the~HTTP request that can be set to~“1”, “0”, or~“null”, based on~the~user's decision not~to~be tracked.
The~value set to~“1” means that the~user does not~want to~be tracked, on~the~contrary, 0 means the~user consents to~be tracked.
The~value set to~“null” means that the~user does not have a~preference.

The early adoption of DNT looked positive.
The~Do Not Track header on~the~websites used by 175 million users every month has been implemented by~the~Associated Press’ AP News Registry service~\cite{firefox_dnt}.
In~2011, the~World Wide Web Consortium (W3C) published the~first Working Draft of~the~Do Not Track standard~\cite{w3c_tracking_2011}.
Next year, Microsoft introduced Internet Explorer~11, where the~Do Not Track was set by~default~to~“1”~\cite{ie10_release}.
This led to~many protests from~advertising companies who~said that the~Do Not Track header should be the~users' choice, not~the~browser developer's~\cite{microsoft_guns}.

In~2012, Roy Fielding, the~author of~the~Do Not Track standard, created a~patch for~Apache that forced the~server to~completely ignore Do Not Track for~users of~Internet Explorer~10~\cite{apache_del_dnt}.
Fielding believes that Microsoft knew that the~Do Not Track header would be ignored and~that their goal was to~give users an~illusion of~privacy for~their own interests.
In~the~same year, Yahoo has decided to~follow the~decision of~Apache and~completely ignore Do Not Track headers for~Internet Explorer~10 users~\cite{yahoo_dnt}.
On~October~9,~2012, the~previous Do Not Track patch for~Internet Explorer~10 users was commented out~\cite{apache_keep_dnt}.
In~2015, Microsoft reversed its~position on~the~default Do Not Track value.

However, the W3C Tracking Protection Working Group was destroyed in~2019~as: \textit{
    ``there has not~been a~sufficient deployment of~these extensions (as~defined) to~justify further advancement, nor~have there been indications of~planned support among user agents, third parties, and~the~ecosystem at~large''
}~\cite{git_wg_dnt_disband, w3c_tracking}. 
Later that year, Apple announced the~removal of~the~Do Not Track standard from Apple Safari to~prevent its potential use as~a~fingerprinting variable~\cite{safari_12_notes}.
The~problem was in~the~definition of~the~Do Not Track header. 
The~users' decision to~be tracked was taken as~a~preference.
This~means that the~website can decide to~ignore the~user's preference completely. 
As~Soghoian stated, another problem of~Do Not Track technology is that it protects the~user only from tracking based on~cookies~\cite{Soghoian_paper}.
He also mentioned that tracking users can be justified for~valid purposes, including first-party tracking or~detecting impression fraud.
First-party tracking takes place when a~user signs into their account and~engages in~actions such as buying an~item from~an~online store.

% -------------------------------------------------
% History of Fingerprinting

\clearpage
\subsection{History of Fingerprinting}

In 2011, a new technique for user tracking was discovered by the Panopticlick project, led by Peter Eckersley~\cite{how_unique}. The project collected a dataset of 470,161 fingerprints between February 27 and March 15, 2010.
Fingerprinting is a~technique that builds on~the~uniqueness of~the~user's device. 
Modern browsers offer various functions with which a~set~of~identifiers can~be~created.
A~combination of~these identifiers might be used to~form an~almost unique user fingerprint. 
The~project found that fingerprints have at~least 18.1 bits of~entropy. 
According to~this study, the~most identifying attributes were the~list of~fonts, user-agent, and the~list of~plugins. 
It is important to~mention that the~collected dataset might be biased because these fingerprints were collected from users interested in~their online privacy.

The~biggest issue with fingerprinting is that some attributes can change over time. 
This can happen when the~user updates the~browser, changes the~monitor, etc.
The Panoptick project has dealt with this issue by~an~algorithmic solution with a~heuristic function that estimates whether~a~new fingerprint is an~evolution of~a~fingerprint that is already stored or not.
The~heuristic function used a~standard Python library function for~string similarity.
The~algorithm success rate was 99.1~\% and~the~false positive rate was 0.86~\%.

In 2019 during the announcement of the Privacy Sandbox, Google opposed the use of fingerprints and stated \textit{``We think subverts user choice and is wrong''}~\cite{google_2019}. 
Nonetheless, Google has revised its stance and adopted a contrary position. 
Following the revision of its platform programme policies, which became effective on February 16, 2025, Google has notified businesses utilizing its advertising services that the use of fingerprinting techniques will no longer be restricted \cite{google_update_feb25}.
This decision has raised great concern in the professional community like the Information Commissioner's Office \cite{response_to_google_fp}.
% -------------------------------------------------
% History of Privacy Sandbox

\subsection{History of FLoC and Topics API}

Privacy Sandbox includes multiple APIs that are centered around advertising functionalities.
Its~primary objective is to~address third-party requirements without using third-party cookies while maintaining user anonymity.
The~first privacy proposal to~create a~new technology for personalised private advertisements was Federated Learning of~Cohorts (FLoC)~\cite{google_floc}.
This technology was designed to~operate by~observing user behaviour and grouping it~into what is termed an~interest cohort.
This cohort would be the~same for users with an~identical browsing history from the previous week.
The~concept of~FLoC was for~the~browser to~handle the~profiling rather than letting the~third-party trackers to~do so.
Although the~goal was to~preserve user privacy, FLoC faced criticism from privacy advocates, regulatory bodies and~other subjects~\cite{cyphers_googles_2021}.

The~first problem was fingerprinting.
As~already stated in~the~EFF Panopticlick project, fingerprinting can be used to~create a~unique identifier.
Because~Google ensured that each cohort would include several thousand users, the~cohort~ID alone would not~be~sufficient to~identify an~individual user.
Nonetheless, since the~cohort only contains thousands of~people, fingerprinting now needs to~distinguish the~user from only thousands of~users instead of~millions. 
Given the~significant privacy concerns associated with fingerprinting, various browsers have implemented measures to~minimise the~unnecessary sources of~entropy, such as~the~cohort ID.
According to~Google's proof of~concept, FLoC would enhance the~accuracy of~fingerprinting by~generating up~to~8~bits of~entropy~\cite{google_floc_PoC}.

Furthermore, FLoC had another great privacy issue.
According to~FLoC documentation, this API allows access to~some information about the user's browsing history to~any site that requests it.
As stated, \textit{``
    This API democratises access to some information about an~individual’s general browsing history (and~thus, general interests) to~any site that opts into it. 
    This is in~contrast to~today’s world, in~which cookies or~other tracking techniques may be used to~collate someone’s browsing activity across many sites.
    Sites that know a~person’s PII (e.g., when people sign in~using their email address) could record and~reveal their cohort. This means that information about an~individual's interests may eventually become public. 
    This is not ideal, but still better than today’s situation in~which PII can be joined to~exact browsing history obtained via third-party cookies.
    As~such, there will be people for~whom providing this information in~exchange for~funding the~web ecosystem is an~unacceptable trade-off. 
    Whether the~browser sends a~real FLoC or a~random one is user controllable''
}~\cite{google_floc_PoC}.
In~summary, any organisation that can identify a~user through methods other than the cohort will be~able to~link the~cohort profile to~that~user.
There are two categories that can be exposed.
The~algorithm used for the assignment of the cohort can be deconstructed to~identify whether any member of~a~cohort has accessed particular websites.
This can lead to~exposing of~user's recent browsing history.
Using the~interests assigned to~the~cohort, the tracker can determine what users might be in~this cohort.
For~instance, if~users are interested in~a~local politician, it~could reveal their general geographic area.
Having an~affinity for~a~particular individual can assist the~tracker with~deducing the~user's age and~gender.

Due~to~the~privacy issues that were mentioned above Google has~decided to~replace FLoC with the~Topics~API~\cite{google_topics}. 
The~Topics~API is~a~system designed to~gather user interests and~organise them in~a~human readable hierarchy.
The~user's interests are recorded directly on~user's device.
Topics for~the~top 50,000 most visited websites can be found in~a~manually created list~\cite{google_topics_learning}.
For~other websites, topics are based on~machine learning classifiers based on~website host names.
The~Topics API provides access to~user's interests yet without compromising user privacy. 
This technology is currently available to 99\% users.
The~browsing history is used to~gather user interests over a~period called epoch, which is currently set to~one week.
For~each epoch, there are top~five topics based on~recent browsing history.
The~Topics API incorporates numerous security measures to~avoid the~use of~Topics for~fingerprinting.
The~topics returned are selected from~the~top five and~are randomly chosen.
Different websites will obtain different topics for~the~same user within the~same epoch.
Each topic is ensured to~have a~minimum threshold of~users, because the~returned topic is random 5\% of~the~time.
Websites that are visited often can discover one topic per week.
The browser is capable of~sharing a~maximum of~three topics at~a~time, with one topic per epoch.

At~present, user tracking techniques rely primarily on~third-party cookies and~fingerprinting, but they are transitioning to~the~use of~the~Topics API.
According to~Google, the third-party cookies have been restricted for~1\% of~Google Chrome clients in~2024~\cite{google_phasing_out_tpc}.
Google is also planning to~continue with third-party cookie deprecation in~early 2025 even though in July 2024, Google announced a new path for Privacy Sandbox \cite{google_july_2024}.
Google has decided to not fully deprecate third-party cookies, but to let Google Chrome users make an informed choice about their privacy. 
The advancement of the Privacy Sandbox will persist, and its efficacy is anticipated to enhance concomitantly with increased adoption.

% -------------------------------------------------
% Cookies

\section{Cookies}
\label{chap:cookies}

Cookies are compact data structures saved by a web browser on the user's device while surfing the Internet. 
They are widely used to improve website functionality, enhance user experience, and facilitate features such as personalization, session management, and tracking.
Cookies main purpose is to solve the stateless nature of the HTTP protocol.
They allow users to remain logged in, navigate an e-shop without losing items in the cart, etc.

\subsection{Lifecycle of Cookie}
Cookies are generated or altered nearly every time a user accesses a website. The lifecycle can be described in three stages: creation, storage and usage.

Cookies are generated in response to a request coming from tje user's device \cite{cookie_creation_2024}. 
This process occurs on the server, which then transmits the cookie back to the user for storage on their device.
An example of the interaction between a user's request and the server response can be seen in Figure~\ref{fig:cookie_creation}.


\begin{figure}[ht]
    \centering
    \includegraphics[width=0.7\textwidth]{figures/cookie_creation.png}
    \caption[Illustration of cookie creation]{Illustration of cookie creation (own work)}
    \label{fig:cookie_creation}
\end{figure}

The server response defines the attributes of the cookie.
However, all attributes are optional.
Several attributes significantly influence a user's privacy and mitigate risks such as cross-site scripting or man-in-the-middle attacks.
The \texttt{Secure} attribute ensures that the Cookie is transmitted only through the~HTTPS protocol.
This means that a browser will only include the cookie if~the~communication is encrypted.
The \texttt{HttpOnly} prevents client-side scripts from~accessing the~cookie.
This effectively mitigates the cross-site scripting attacks that attempt to~steal user's cookie.
Another attribute that heavily contributes to~the~security of~the~cookie is \texttt{SameSite}.
This attribute can acquire three different values.
When set to \texttt{Strict} cookies will be sent in~responses only~to~requests originating from~the~same site.
On~the~other~hand, when the~attribute is set~to~\texttt{none}, the~cookie will be sent in~all cross-site requests, but only~if~the ~\texttt{Secure} attribute is also present, meaning the~transmission occurs only over HTTPS connections.
The~\texttt{Lax} value specifies that the cookie will not be included in~the~request for~cross-site resources, but it~will be transmitted in~top-level navigations \cite{samesite_explained}.
The expiration period of~the~cookie is defined by the~\texttt{Max-Age} or~\texttt{Expires} attributes.
This reduces the~risk of~stealing user's identity by reducing its validity period.
The \texttt{Path} and \texttt{Domain} attributes specifies the~scope where the cookie can be~used.
The integration and right configuration of~all~these attributes significantly enhance the security of~user cookies.
Cookies can also be created on the client side using the Java Script \texttt{document.cookie} property.
However, this is not commonly used, since that type of cookies cannot use security attributes such as~\texttt{HttpOnly}.

After their creation, cookies are stored in specific locations on a user's device, depending on the type of cookie and the browser in use. 
Browsers categorise cookies into two groups: persistent cookies and session cookies. 
Session cookies are retained in~the~user's RAM. 
They serve the purpose of~storing temporary data, such as session identifiers.
Persistent cookies, which possess attributes \texttt{Expires} or~\texttt{Max-Age}, are stored on~the~user's hard drive. 
These cookies remain on~the~device until the~predetermined validity period expires.
This category of cookies is typically used for~session-wide data, for~example user preferences. 
The exact type and location of~persistent cookie storage depend on~the~type of~browser in~use.
Google~Chrome and Mozilla~Firefox employ SQLite databases for the storage of~cookies. 
In~contrast, the~Apple~Safari browser uses binary plist files for this purpose~\cite{andrade_macos_2020}. 
Moreover, browsers impose restrictions on~the~number of~cookies permitted per~domain and~their maximum size, which is typically restricted to~4~KB per~cookie.

Cookies serve multiple functions and are integral to web application operations. 
They contribute to the enhancement of~the~user experience and~the~facilitation of~business functionality. 
A~prominent application of~cookies is~session management via~session cookies. 
This mechanism enables websites to~track user interactions across various pages and~repeated visits. 
Users typically receive a~session cookie after~completing authentication or~specific activities, such~as adding an~item to~an~online shopping cart. 
Moreover, session cookies can be~used to~customise the~experience of~a~website. 
In~addition, cookies are used to~store user preferences, including language settings, display modes, and~other personalisation options.
Analytical tools, such~as Google~Analytics, use cookies to~observe user behaviour and~collect data~\cite{google_analytics_cookies}. 
These cookies are used~for purposes including conversion tracking, targeted marketing, and~evaluation of~advertisement performance, among others.
Cookies can also be~used to~comply with~regulations such~as~GDPR.
For example, cookies store the~user's consent to~use cookies.
Cookies are used not~only~to~pursue business goals, but~also to~enhance the~security of~the~Internet.

Cookies containing the \texttt{SameSite} attribute, in conjunction with anti-CSRF tokens, establish a robust defence against Cross-Site Request Forgery (CSRF) attacks \cite{anti_csrf}. 
Anti-CSRF tokens are generated on the server side for each user during every session. 
Then these tokens are stored both on the user's device and the server. 
During the rendering of forms that require user interaction, the data incorporate the anti-CSRF token within a hidden form field.
\begin{figure}[H]
\centering
\footnotesize
\begin{lstlisting}[caption={HTML form with anti-CSRF token}, captionpos=b, label={lst:csrf_form}]
<form action="/login" method="POST">
    <input name="username" value="username123">
    <input type="hidden" name="csrf_token" 
           value="csrf_token_123">
    <button type="submit">Submit</button>
</form>
\end{lstlisting}
\end{figure}
When submitting the form, both the~token stored in~the~cookie and~the~one in~the~form are sent to~the~server.
The server then validates these tokens.
The~core of~this defence is that the~attacker cannot guess the~anti-CSRF token because it is unique for~each session.

Cookies can also be modified or deleted simply by another server response using \texttt{Set-Cookie} response header or manually deleting them in the certain storage.

\subsection{Types of Cookies}

Cookies can be divided in many ways.
The division by lifespan has already been explained and illustrated in the chapter before.
Session cookies are created per session and deleted when the browser window is closed.
However, persistent cookies are created during the first visit and deleted when the cookie expires.
Origin can also work as a keystone for division cookies.
First-Party cookies are created by the website user is currently visiting.
This type of cookies is usually used to store data related to the functionality of the website and~is accessible only by the current website.
Cookies created by domains other than the website the user is currently visiting are called third-party cookies.
Their goal is to track users across multiple websites mainly for advertising or marketing purposes.
Cookies can also be divided by their purpose.
Some cookies may be necessary for the basic functionality of a website, while others can be used to enhance the user experience.
The user's interaction with~the~website is stored in cookies that serve for performance analytics.
Cookies are often used to~form the~so-called tracking cookie, whose purpose is to~enable a~personalised user experience while browsing~\cite{aleksandr_tracking_cookie}.
The~tracking cookie can also be used to~collect data and~create a~very detailed profile of~the~user~\cite{mozilla_goodbye}.
This includes timezone, gender, device specification, political affiliation, etc.
Tracking cookies are often sold to~another third-party website.

% -------------------------------------------------
% Fingerprinting

\section{Fingerprinting}
\label{chap:fingerprinting}

In the preceding chapter, we introduced a method of user tracking that is~based on~storing data on~the~user's~device. 
However, users may alter or even delete the tracking files, leaving the server incapable of detecting such changes.
This section presents a method that capitalises on the uniqueness of individual users without necessitating the storage of data on the user's device.

The fundamental premise of this method involves generating data for each visit and comparing them with preexisting data. 
During a~user's visit, extensive data is gathered, leading to~the~generation of~a~distinct fingerprint. 
This fingerprint is subsequently transmitted to~the~server and evaluated against the~stored data. 
A match indicates user recognition, whereas the absence of~a~match requires the~storage of~new~data.
This process is demonstrated in~Figure~\ref{fig:fingerprint_process}.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.7\textwidth]{figures/fingerprint_creation.png}
    \caption[Illustration of fingerprinting process]{Illustration of fingerprinting process (own work)}
    \label{fig:fingerprint_process}
\end{figure}

A match can be used to track the user or restore the cookie.
According to~Panopticlick research, there is and will be enough data to~collect to~recognise the~user \cite{eckersley_how_2010}.
A browser fingerprinting consists of multiple methods of~collecting data about the~user.
These methods are periodically modified and~updated because some browsers try to~protect their users by~corrupting these data.
Although individual data points might not be~unique, their collective aggregation can result in~a~unique user profile. 
The premise is that variations in~browser settings, combined with gathered data, can render the~user either unique or~nearly unique.
The content of~the~information of~every gathered data type holds significant importance.
The entropy \(H(X)\) of the variable \(X\) is defined as

\begin{equation}
    H(X) = - \sum_{x \in X} p(x) \log_2 p(x),
    \label{eq:entropy}
\end{equation} 
where if \(p(x)=0\) then \(p(x) \log_2 p(x)=0\) \cite{entropy}.
The resulting value represents the quantity of exploitable information derived from the specified parameter, measured in bits.
From the definition, it is evident that data with uniform-like  probability distributions have the greatest entropy, whereas data sets with limited possible values possess lower entropy.
DNT can work as~a~great example as~a~bad identifier as~it can only have 3~values.
The~greater the~entropy of~the~parameter, the~more significant its~weight in~the~identification of~the~user.
The~methodology for~calculating the~entropy of~a~single parameter is demonstrated herein. 
Statistical data indicate that over 95\% devices operate on~the~top~four most~used operating systems \cite{statcounter_os_marketshare}. 
This information is~accessible via~the~User-Agent, as~discussed in~a~subsequent section of~this~chapter, and can be utilised to~evaluate the~minimal entropy of~the~User-Agent header.
The~data mentioned above were extracted from a~CSV file provided by~StatCounter in~January~2025.

\begin{table}[h]
    \centering
    \caption[Market share of operating systems Dec 2023–Dec 2024]{Market share of operating systems Dec 2023–Dec 2024 \cite{statcounter_os_marketshare}}
    \begin{tabular}{|l|r|}
        \hline
        \textbf{Operating System} & \textbf{Market Share (\%)} \\
        \hline
        Android & 44.28 \\
        Windows & 27.16 \\
        iOS & 18.03 \\
        OS X & 5.69 \\
        \vdots & \vdots \\
        Other & 0.02 \\
        Playstation & 0.01 \\
        \hline
    \end{tabular}
    \label{tab:os_market_share}
\end{table}

The data then need to be substituted into the formula.

% Requires: \usepackage{amsmath}
\begin{equation}
    H = -[0.4428 \cdot \log_2 0.4428 + 0.2716 \cdot \log_2 0.2716 + \cdots + 0.01 \cdot \log_2 0.01] 
    \label{eq:entropy_example}
\end{equation}

The resulting value is 2,011 bits, which is quite low. 
Yet, the~\texttt{User-Agent} header consists of~multiple parameters and collectively contributes significantly to~the~fingerprinting algorithm.

A~user may verify the~uniqueness of~their browser configuration by~using tools such~as~\textit{Am I Unique} or~\textit{Cover Your Tracks}, the~latter having been rebranded from~Panopticlick~\cite{am_i_unique, cover_your_tracks}.
Both tools offer tests for~the~most commonly used fingerprinting methods, and some of~them are described in~further detail in~this chapter.
Both tools provide the~results for~each parameter examined. 
\textit{Cover Your Tracks} additionally displays the~bits of~identifying information, while \textit{Am I Unique} presents the~percentile similarity with all previously assessed browsers.
It is worth noting that the~results for~a~user verifying their browser’s uniqueness may~be more~favourable, as~they have likely taken prior preventive measures.
While certain browsers implement more robust anti-fingerprinting measures, a~user may not be~identified as~an~individual but~rather recognised as~a~member of~a~group interested in~examining their online behaviour.
The~anti-fingerprinting defensive methods the~browsers have implemented are~explained in~the~Chapter \ref{chap:def}.

Fingerprinting serves a dual purpose.
It is used not only for~user tracking but~also for~bot~identification~\cite{tor_fingerprinting}.
For~example, web~drivers such as~Selenium add~\texttt{\_selenium} to~the~\texttt{windows} object.
Bots usually behave abnormally and~can be tracked by~fingerprinting.
The integration of fingerprinting techniques with artificial intelligence models can facilitate the~identification of~bots. 
However, with~the~upcoming use of~AI~agents, there is~an~anticipated increase in~bot traffic, necessitating that web pages possess the~capability to~distinguish between legitimate and~malicious bots.

In this chapter, we explain the difference between active and passive fingerprinting and present various fingerprinting methods, with particular emphasis on those implemented within the Analysis section.

% -------------------------------------------------
% Passive Fingerprinting

\subsection{Passive Fingerprinting}

Passive fingerprinting techniques collect data contained within HTTP packets. 
These methods do not require executing additional scripts on the user's device. 
HTTP packets might include certain headers that can serve as identifiers for~users. 
However, these identifiers alone are unlikely to~make a~user unique.
Yet, they may achieve uniqueness when employed in~conjunction with~other fingerprinting methodologies.

\clearpage

\paragraph{User-Agent Headers}\leavevmode\\

A~User-Agent header is appended to~all HTTP requests and serves to~identify the~client to~the~server. 
It consists of~various pieces of~information, including the~browser engine and~name, the~operating system, and~additional relevant details. 
Its original intention was to~transparently specify the type of~device to~facilitate responsiveness of~web pages.
The header may look like the~code presented in~Listing~\ref{lst:user_agent}.

\begin{figure}[H]
\centering
\footnotesize
\begin{lstlisting}[caption={User-Agent string illustration}, captionpos=b, label={lst:user_agent}]
Mozilla/5.0 (Windows NT 10.0; Win64; x64) 
AppleWebKit/537.36 
(KHTML, like Gecko) 
Chrome/123.0.0.0 
Safari/537.36
\end{lstlisting}
\end{figure}



The~Panopticlick research estimates the entropy of this header to~be 10~bits. 
In~contrast, more contemporary research related to~cross-browser user fingerprinting reports an~entropy of~6.71~bits~\cite{cao_cross_browser_2017}. 
The~discrepancy between these figures may be attributed to~the~variance in~the~volume of~data used, with \textit{Panopticlick} having used 409,296~data inputs compared to~only~3,615~data inputs in~the~latter study.
The~reason for~such a~high level of~entropy is~the~very detailed information about~the~device.

To~reduce the~extent of~information leakage, a~new proposal has been introduced advocating the~transition to~more secure User-Agent Client Hints~\cite{Wiefling_A_2024}.
In~the~first request, user's device sends only necessary data showing if~it is a~mobile or~not and~browser type.
The~website can opt-in to~request more detailed information if~necessary.
This means that less information is leaked by~default.
An~illustration of~this process is~presented in~Figure~\ref{fig:ua_ch}.

\begin{figure}[H]
    \centering
    \includegraphics[width=0.8\textwidth]{figures/UA-CH showcase.png}
    \caption[Illustration of User-Agent Client Hints]{Illustration of User-Agent Client Hints (own work)}
    \label{fig:ua_ch}
\end{figure}

\paragraph{Accept Headers}\leavevmode\\

HTTP Accept headers enable browsers to~specify their preferred format for~effective communication handling~\cite{fielding_http_2022}. 
Nevertheless, these headers are replete with~information and~provide high entropy. 
Certain websites may use these data to~precisely format the~site content, while others may passively collect such information to~enhance their mechanisms for~user fingerprinting.
Panopticlick research indicates that these headers encompass 6.09~bits of~entropy and, in~certain instances, may function as~complete identifiers~\cite{eckersley_how_2010}. 
However, these data are typically insufficient on~their own to~conclusively identify the~browser.

The Accept header specifies the~media types that the~client can handle.
It can be used to~show that the~request is used as~an~image request.
The~\texttt{Accept-Charset} HTTP header specifies the~range of~character encodings that are permissible and~recognised by~the~client.
The~\texttt{Accept-Encoding} is used for~supported compression algorithms.
The~\texttt{Accept-Language} header indicates the~set of~languages that are preffered by~the~client.
All~these headers might include the parameter \texttt{q} that indicates relative weight of~a~certain preference.
The~server should process the~formats according to~the~weights and~not the~order.
The~format of~these headers can be seen in~Listing~\ref{lst:accept_headers}. 

\begin{figure}[H]
\centering
\footnotesize
\begin{lstlisting}[caption={HTTP Accept headers illustration}, captionpos=b, label={lst:accept_headers}]
Accept: text/html, audio/basic;q=0.9, */*;q=0.8
Accept-Charset: iso-8859-5, unicode-1-1;q=0.5
Accept-Encoding: compress, gzip
Accept-Language: cz, en-us;q=0.8, en;q=0.7
\end{lstlisting}
\end{figure}


These data are sent by~default without any~initiative from the~server.
This simplifies the~task of~gathering information. 
There are multiple approaches to~address this issue, but~none have yet been standardised~\cite{explainers-by-googlersreduce-accept-language_2025}.
One strategy involves incorporating these headers into User-Agent Client Hints. 
Another suggestion is to send either nothing or~just one preference with the~initial request. 
Nonetheless, in~the~case of~\texttt{Accept-Language}, such limitations would disadvantage multilingual users as~they would not be~able to~express their full preferences~\cite{benjamin_davidbenclient-language-selection_2023}.


\paragraph{IP Address}\leavevmode\\

Another information that can be obtained from an HTTP packet is an~IP~address.
While an~IP address may vary over time for~a~single device, the~combination of~IP address and~fingerprinting can serve as~an~effective means of~distinguishing between devices within a~single subnet.
It is noteworthy to~mention that this combination contributes to~the~reconstruction of~cookies due~to~the~diverse array of~devices present within a~single subnet.

\paragraph{DNT Header}\leavevmode\\

Despite the~fact that the~DNT header is limited to~merely three distinct values, it is capable of enhancing the accuracy of~fingerprints. 
A~recent study indicates that the~inclusion of~the~DNT header contributes an~additional 0.47~bits to~the~entropy metric~\cite{cao_cross_browser_2017}.
Assuming uniform probability distribution for~all possible values, when substituted into~equation~\ref{eq:entropy}, this yields an~entropy measure of~approximately 1.6~bits.

% -------------------------------------------------
% Active Fingerprinting

\subsection{Active Fingerprinting}

Active fingerprinting is a method that websites use to gather information.
Unlike passive fingerprinting, which gathers data without any code execution, active fingerprinting involves mainly running JavaScript scripts in the user's browser \cite{browserleaks}.
This code produces data that are sent to the server and contribute to building the user's fingerprint.
The information generated through this method is typically more useful in constructing a user's fingerprint because of its higher level of entropy.
To avoid these techniques, a user can disable JavaScript, for example, via NoScript \cite{noScript}.
While deactivating JavaScript can obstruct numerous active fingerprinting methods, it does not automatically enhance user privacy.
According to Panopticlick's research, browsers with~JavaScript disabled produced the least unique fingerprints~\cite{eckersley_how_2010}. 
This decreased uniqueness results because these browsers reveal considerably less information, thus complicating their differentiation.
Counterintuitively, since most users have JavaScript activated, turning it off can noticeably identify a~browser, thus enhancing its uniqueness.

\paragraph{Object Fingeprinting}\leavevmode\\

As JavaScript plays a vital role in the functionality of modern websites, it also offers various attributes and APIs that can be used to form a fingerprint.
One straightforward method to acquire data from the user's browser is through the~\texttt{navigator} object~\cite{navigator_2025}. 
This object stores a~variety of~details about~the~browser, including its~type, version, and~plugins, as~well as~the~user-agent string sent with all HTTP requests, among other things.

Based on~the~Panopticlick research, the~attribute that carries the~most significant information that the~\texttt{navigator} object can provide \linebreak is a~\texttt{navigator.plugins}, which carries 17.7~bits of~entropy~\cite{eckersley_how_2010}. 
This \texttt{navigator} property lists all~installed plugins and~their supported MIME types \cite{navigator_2024}. \linebreak
As~of~2025, not all browsers support plugin listings and~is considered deprecated. 
However, the~\texttt{navigator} object can still be~leveraged to~obtain other details, such~as data provided in~the~Accept headers, storage quota, browser permissions, etc. 

Additionally, the~\texttt{navigator} object can be used to~gather hardware information via~the~\texttt{hardwareConcurrency} property. 
Browsers without protective measures, such as~Chromium, allow the~script to~determine the~exact number of~logical cores in~the~user's CPU, the~device's memory, or~the~GPU (graphics processing unit) type.
The~\texttt{navigator} property offers various APIs that can be escalated to~identify the~user's device~\cite{battery_api}.
For~example, the~Battery Status API can be used to retrieve if~the~device is charging, battery level status, and~estimated discharging time.
This API does not require user's permission to~access the~information.
Recent research shows that the total capacity of~a~battery can be calculated from~the~information provided by~this API~\cite{olejnik_leaking_2015}.
The~research was done on~Linux using Firefox browser which both provide detailed numbers.
To~fix this, the~browser has modified the~returned values to~be less precise.
The~\texttt{navigator} object offers additional APIs that are used in~more complex fingerprinting techniques, which are detailed in~the~following sections.

Another JavaScript object that aids in~fingerprinting is the \texttt{window} object. 
This object discloses several aspects of~the~user's current browser window settings and~device display, such~as~dimensions, colour depth, and~touch input capability. 
According to~\textit{Panopticlick} research, this object contributes with 4.83~bits of~entropy~\cite{eckersley_how_2010}.
These values may vary, for~instance, if~the~user attaches additional monitors or~resizes the~browser window. 
Consequently, this object is used primarily for~browser fingerprinting on~mobile devices since they typically operate in~full-screen mode. 
However, this is gradually changing on~mobile devices with larger displays that allow multiple windows to~be open simultaneously.

\clearpage
\paragraph{Canvas Fingerprinting}\leavevmode\\

Canvas is an~element of~HTML5 that is used to~render graphics using JavaScript~\cite{canvas_2024}.
It is used for~animations, graphics, and~data visualisation on~a~web page.
Compared to~previously mentioned fingerprinting methods, canvas fingerprinting does not give us information about the~user.
However, it gives a~reliable user identifier based on~multiple factors \cite{mowery_pixel}.
This method exploits small differences between the~device's capability of~rendering graphics.
According to~a~recent study, this method is used in~5.1\%~of~the~top one~thousand and~1.32\% in~the~top ten~million websites most visited~\cite{englehardt_online_2016}.
Another study discovered that 5.6\% of~the~100,000 most visited websites employed canvas fingerprinting on~their home pages~\cite{acar_web_2014}. 
Of~these websites, 95\% relied on~a~single third-party provider for~this service. 
Additionally, it as notable that the~use of~canvas fingerprinting was relatively uniform among these sites, with~the~lowest occurrence found within the~top~10,000 most visited websites.
According to~the~cross-browser fingerprinting study, the~precision of~this method allowed it to~uniquely identify 99.24\% of~visitors with a~total entropy of~10.95~bits within a~single browser and~83.24\% of~users across browsers with an~entropy of~7.1~bits~\cite{cao_cross_browser_2017}.

The~canvas element supports two context modes. 
The~2D~mode facilitates 2D~graphics and~is commonly used for~developing dynamic UI components and basic graphical objects. 
WebGL (Web Graphics Library) provides more intricate manipulation with 2D and~3D objects \cite{webgl_2024}. 
To~overcome performance constraints, GPU hardware acceleration is employed for~enhanced graphics rendering efficiency. 
Consequently, the~output is influenced by~the~user's GPU~model, graphics driver, and~its configuration. 
These minor variations in~the~hardware combinations employed make this technique highly consistent. 
The~fingerprint is likely to~change only if~the~user replaces the~GPU or~updates the~graphics driver. 
This approach can be conducted discreetly and~without the~user's knowledge. 
JavaScript code computes the~fingerprint, which is then transmitted to~the~server.

To~create a~fingerprint from a~2D canvas, it is important to~choose a~text that will reveal the~differences between user's devices.
This text can consist of~alphanumeric characters, as~well as emojis or~special symbols.
The~text is then transformed into an~image and~then into a~user identifier.
The~2D context mode offers the~\texttt{getImageData} method that returns an~array of~RGBA values.
Each value represents one pixel of~the~image.
It also offers the~\texttt{toDataURL} method that returns data in~Base64 form or~the~\texttt{toBlob} method that returns raw data~\cite{htmlcanvaselement_2024}.
This data can then be hashed and~work as~a~fingerprint.

\begin{figure}[h]
    \centering
    \begin{tikzpicture}[baseline]
        % First row
        \node at (0, 1) {\includegraphics[width=0.4\linewidth]{figures/canvas-win-edge.jpg}};
        \node at (7, 1) {\includegraphics[width=0.4\linewidth]{figures/canvas-win-brave.jpg}};
        \node at (0, 0) {(a) Windows 10 Microsoft Edge};
        \node at (7, 0) {(b) Windows 10 Brave Browser};

        % Second row
        \node at (0, -1.5) {\includegraphics[width=0.4\linewidth]{figures/canvas-win-chrome.jpg}};
        \node at (7, -1.5) {\includegraphics[width=0.4\linewidth]{figures/canvas-win-firefox.jpg}};
        \node at (0, -2.5) {(c) Windows 10 Google Chrome};
        \node at (7, -2.5) {(d) Windows 10 Mozila Firefox};

        % Third row
        \node at (0, -4) {\includegraphics[width=0.4\linewidth]{figures/canvas-mac-safari.jpg}};
        \node at (7, -4) {\includegraphics[width=0.4\linewidth]{figures/canvas-mac-brave.jpg}};
        \node at (0, -5) {(e) MacOS Apple Safari};
        \node at (7, -5) {(f) MacOS Brave Browser};

    \end{tikzpicture}
    
    \caption[Illustration of 2D canvas fingerprinting]{Illustration of 2D canvas fingerprinting (own work)}
    \label{fig:canvas_fp}
\end{figure}

Figure~\ref{fig:canvas_fp} presents an example of 2D canvas fingerprints. 
This script-generated text originates from the~test suite discussed in~Chapter~\ref{chap:methodology}. 
The~data were gathered on~two~machines, one running Windows~10 and~the~other running MacOS~Sequioia, across multiple browsers. 
Notably, the~data acquired from~chromium-based browsers on~a~single device appear fairly consistent. 
Images~a and~care totally identical, and image~b has a~different fingerprint due to~the~defence mechanisms of~Brave~Browser that are explained in~Chapter~\ref{chap:brave}.
In~contrast, in~image~d, the~colours appear deeper and~the~text's edges are more defined, although the~emoji's edge is lighter.
Comparing Windows data with~MacOS data highlights the~most significant disparity in~emoji and~special symbols.

A~canvas fingerprint based on~WebGL can consist of~the~data from \linebreak the~image and~two more pieces of~information about the~user's device \linebreak from~\texttt{WEBGL\_debug\_renderer\_info}~\cite{webgl_debug_renderer_info_2024}. 
The~\texttt{UNMASKED\_VENDOR\_WEBGL} identifies the~producer of~the~GPU, and the~\texttt{UNMASKED\_RENDERER\_WEBGL} usually consists of~the~exact name of~the~user's GPU. 
Access to~these two pieces of~information might not be allowed and~depends on~the~browser settings.
Based on \linebreak the~cross-browser fingerprinting study, the~entropy of~\texttt{UNMASKED\_VENDOR\_WEBGL} is 2.2~bits and~the~entropy of~\texttt{UNMASKED\_RENDERER\_WEBGL} is 5.7~bits~\cite{cao_cross_browser_2017}.

\paragraph{Web Audio API fingerprinting}\leavevmode\\

The~Web Audio API enables the handling of sound in web pages~\cite{audio_api}.
Developers can use it to~create, modify, or~play audio. 
It is a~modular design that uses modules called \texttt{AudioNode} that are linked in~a~routing graph.
One context offers multiple simultaneous audio inputs.
The~inputs might be an~audio file, an~audio or~video stream, or~mathematically computed in~\texttt{OscillatorNode}.
The~output of~one module can be linked to~the~input of~another module, which can help to~mix multiple sources of~entropy.
This enables the~use of~multiple inputs, each configured uniquely.
This technique is conceptually similar to~canvas fingerprinting, as~it takes advantage of the~small differences between audio cards, audio drivers, and~their settings.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.7\textwidth]{figures/audio_api.png}
    \caption[llustration of Web Audio API fingerprinting]{Illustration of Web Audio API fingerprinting (own work)}
    \label{fig:fp_audio}
\end{figure}

The~illustration of~a~usage of~the~Web Audio API for~fingerprinting purposes can be seen in~Figure~\ref{fig:fp_audio}.
The~\texttt{OscillatorNode} is used as~a~source of~audio for~simplicity reasons and~due~to~hardware dependency.
To~compress the~audio with~specific settings the~\texttt{DynamicsCompressorNode} is used.
It offers many properties that can be used to~create variability between browsers~\cite{fp_audio}.
It is usually used to~adjust the~sound of~the~audio so~that the~sound of~the~audio sounds correctly even at~high volume.
The~output is then saved into a~\texttt{AudioBuffer} and~the~hash is computed using a~hash function on~a~sum of~absolute values of~the~data in~the~buffer.
The SHA256 is used as~an~example of~a~hash function, but an~arbitrary one can be used.
This type of~script was found as~one of~the~two known types of~script found in~the~analysis of~the~top 1~million websites~\cite{englehardt_online_2016}.  
The~second known script uses \texttt{AnalyserNode} to~compute a~Fast Fourier Transformation~(FFT).
During this research, a~demonstration website was created.
713~unique fingerprints were calculated out~of~18,500 devices.
The~research estimates the~entropy of~this technique to~be 5.4~bits.

The~cross-browser fingerprinting study also used this method to~enhance their fingerprinting algorithm~\cite{cao_cross_browser_2017}.
This study used the~configuration creating FFT using the~\texttt{AnalyserNode} from~a~triangle waves generated\linebreak  by~the~\texttt{OscillatorNode}.
Stability in the~wave peaks and their frequencies was observed, leading to~the~decision to~map the~peaks.
This approach consistently performed well on~various browsers and~provided 1.87~bits of~entropy.

\paragraph{Font Fingerprinting}\leavevmode\\

Every device comes equipped with a~selection of~fonts. 
The~set of~fonts installed may differ depending on~the~device and~operating system, contributing to~a~high level of~entropy. 
Text and~photo editing software typically installs additional fonts to~expand the~available choices.
Fonts may come in~different order because some applications or~system updates might overwrite the~font files.
According to~\textit{Panopticlick} research, an~unsorted list of~fonts gained via~Flash or~JavaScript provides 17.1~bits of~entropy, while~a~sorted list provides 16~bits of~entropy.
Nevertheless, the~study says that a~larger dataset might reveal a~more pronounced difference. 
According to~cross-browser fingerprinting research, the~entropy of~a~font list obtained through Flash is only 2.4~bits, while a~list gathered through JavaScript has an~entropy of~10.4~bits~\cite{cao_cross_browser_2017}.
It is notable that in~this interval between the~two researches, Adobe Flash has nearly vanished.

There are several methods to~retrieve the~user's list of~fonts from a~website.
Some of~them are directly accessing the~font-list while other work without having the~list at~all.

In~the~past, Adobe Flash was a~popular technology in~the~online realm. 
However, it is no~longer used today, having been replaced by~HTML5 elements like \texttt{<canvas>} and~\texttt{<audio>}, which are discussed in detail in~the~following sections.
The~execution of~a~Flash application required user permission, which makes this method easily noticeable.
The~method \texttt{enumerateFonts} was used to~get the~list of fonts.
Flash applications were executed through a~browser plugin that has no~longer been supported since 2021~\cite{adobe_flash_end}.

Another suppressed method to get the list of fonts was via a~Java Applet.
Old browser versions used to~support running Java applications through a~browser plugin.
The~method \texttt{getAvailableFontFamilyNames} was used to~get the~list of~fonts.
This method did not require any additional user permission, but~was also dependent on~the~presence of~the~browser plugin.
The~support of~this plugin is deprecated since JDK~9~\cite{deprecated_api}.

As of 2025, the list of fonts can be acquired using a combination of JavaScript and CSS or a Canvas HTML5 element.
This method does not require access to the list but requires one to have a list of known fonts to be tested.
It tests the presence of a font by analysing how a certain element renders while being styled.
This method was first introduced by Lalit Patel \cite{javascriptcss}.

At first, a constant string is decided and styled with the widely used font family that will be used as a default font.
In CSS, this can be done by setting the font-family attribute \cite{font_family}.
This attribute allows multiple inputs, which allows setting the tested and default fonts.
If a font is missing, the following one is used.
If none is present, a default font set by the browser is used.
After that, the string is measured.
Then a new font is added into font-family attribute with a higher priority and the text is measured again.
If the two values are equal, the tested font is probably not present because the browser used the default present font. 

\begin{figure}[H]
\centering
\footnotesize
\begin{lstlisting}[caption={Font fingerprinting HTML code illustration}, captionpos=b]
<p style="font-family: 'Arial'; font-size: 72px;">
    mmmmmmmmmmlli
</p>
<p style="font-family: 'Calibri', 'Arial'; font-size: 72px;">
    mmmmmmmmmmlli
</p>
\end{lstlisting}
\end{figure}


\begin{figure}[h!]
    \centering
    \includegraphics[width=0.7\textwidth]{figures/fonts.png}
    \caption[Illustration of font fingerprinting]{Illustration of font fingerprinting (own work)}
    \label{fig:fp_fonts}
\end{figure}

In the~code listing above and its graphical illustration in Figure~\ref{fig:fp_fonts} is an~example of~this method from the testing suite, which is discussed in more detail in~Chapter~\ref{chap:methodology}. 
For testing purposes, the first font is set as Arial.
In the second text, the font-family is set to Calibri and Arial.
The first text dimensions are 648x82, while the second text dimensions are 625x88.
This means that the tested font is present.
The exact dimensions might vary between various devices.

CSS can be used for more fingerprinting methods.
However, these are not mentioned in this thesis.

% -------------------------------------------------
% FLoC and Topics API

\section{Federated Learning of Cohorts and Topics API}

Both FLoC and Topics API are privacy-focused initiatives that aim to group users based on their interest and replace third-party cookies \cite{google_floc}. 
They both try to blend the user into a larger group of people with the same interests without identifying individuals.
However, they differ in their approach.

\subsection{Federated Learning of Cohorts}
\label{chap:floc}

The FLoC approach is to cluster users into cohorts based on their browsing history from the last 7 days.
Each cohort gets assigned a cohort id through the~PrefixLSH algorithm, which is based on the SimHash algorithm \cite{floc_cohort_paper}.
SimHash is an~example of a locally sensitive hashing family of algorithms.
It was originally developed to quickly recognise near-duplicate files. 
PrefixLSH is an~extension of SimHash based on SortingLSH that generates the hash for each user from their browsing history.

The construction of the cohort is computed locally and can be described in 4 steps \cite{floc_clustering}.
At first, each domain from the user's browsing history is used as a seed of pseudo-random number generator (PRNG) using Gaussian distribution.
The PRNG generates a~\(b-\)dimensional floating-point vector for~each domain.
These vectors are then used to create a \(b-\)bit bitvector, where~\(i-\)th bit indicates the positivity/negativity of the sum of \(i-\)th coordinates of~all vectors.
The bitvector is then divided into 2 main cohorts based on~the~first bit.
This division is then repeated until each cohort has at least 2000 qualifying users. 
The result of this algorithm is a list of cohorts as bitvector prefixes.

In other words, the user browsing history is converted into a distinctive pattern to assign cohort IDs. 
Each visited site contributes to a numeric representation that transforms into bit sequences. 
These sequences facilitate user division into sufficiently large groups, concluding with cohort identifiers symbolised by bit sequences.

A cohort is \(k-\)anonymous if it is shared by at least \(k\) users.
This means that the higher \(k\) is, the more protection is provided.
The cohort id is recomputed every 7 days.
A cohort ID cannot be used as a fingerprint if it is used alone.
However, in combination with other fingerprinting methods, it can help identify the user as it reduces the number of potential individuals \cite{floc_report}.
FLoC keeps all the data about the user in the user's browser.
A website can obtain the user's cohort id via the \texttt{interestCohort()} method.

\begin{figure}[h!]
    \centering
    \includegraphics[width=1\textwidth]{figures/floc.png}
    \caption[Illustration of Federated Learning of Cohorts]{Illustration of Federated Learning of Cohorts (own work)}
    \label{fig:floc}
\end{figure}

An example of how FLoC works can be seen in Figure~\ref{fig:floc}.
To showcase FLoC, let us have \texttt{userA} and~\texttt{userB}.
These users have the same interests and~visited similar websites in the last 7 days but in a different order.
Thanks~to~that, both \texttt{userA} and~\texttt{userB} are assigned to cohort 100 based on~the~algorithm explained before.

Then we have an~adtech company that provides personalised advertising services and~advertisers \texttt{websiteA} and~\texttt{websiteB} that both use the same adtech company and \texttt{websiteC} that opted out of using FLoC.

For example, \texttt{userA} visits \texttt{websiteA} selling cars and \texttt{userB} visits~\texttt{websiteB} about sports.
Their browsers share the cohort id to these websites that then share this information with the advertising firm.
The advertising firm now knows that members of cohort 100 are interested in cars and sports.
When some of our users visit another website that uses the advertising company, it will share the cohort id and an advertisement related to cars or sports will be shown, all without using cookies.

Then \texttt{userA} visits \texttt{websiteC} about motorbikes.
However, as \texttt{websiteC} does not support FLoC the advertising company cannot know that members of this cohort are interested in motorcycles.
This visit will not affect any advertisements shown to the users of this cohort.
But this visit will affect future calculation of the next cohort id of \texttt{userA}.

In the course of preparing this thesis, the development efforts were halted by Google, and the focus was redirected towards the Topics API.

\subsection{Topics API}
\label{chap:topics}

Topics API is an~initiative by Google that aims to~create interest-based advertising without compromising user privacy~\cite{google_topics}.
Interest-based advertising is helpful for both sides as it helps advertisers reach as many potential customers as possible and helps users to see more relevant topics.
The topic is a human-readable interest that is formed from the user's browsing history in a certain period.
Topics API was created for the Web and for Android; however, this thesis focuses only on the Topics API for the Web.

Topics are assigned to a user according to a taxonomy.
This taxonomy is a~list that consists of approximately 500 topics that were curated for 50,000 top sites by hand.
Each topic is assigned an identifier and human-redable name.
If the visited website does not belong to the 50,000 top sites, the browser uses machine learning classifier that extracts the topic from the site's hostname. 
These topics are stored locally in the user's device and are not shared across devices.
Browsers provide user's options to control stored topics and Topics API in general.

The website that requests user's topics of interest is named a caller.
At~first, the caller has to observe the user's topics, and then it can access them.
Each caller is identified by eTLD+1.
The eTLD+1 means a top-level domain and~a~subdomain works as a callers identifier.
A~caller can access topics that only the~caller has observed. 
There are two ways in which callers can access topics.
JavaScript API offers \texttt{document.browsingTopics();} method or request and response headers for \texttt{fetch()} requests or for an \texttt{iframe}.
The illustration of~the~request can be seen in~the~Listing~\ref{lst:topics_request_header} and~the~response headers can be seen in~the~Listing~\ref{lst:topics_response_header}.

\begin{figure}[H]
\centering
\footnotesize
\begin{lstlisting}[caption={Topics API request header example}, captionpos=b, label={lst:topics_request_header}]
Sec-Browsing-Topics: (328);v-chrome.1:2:3, 
                     ();p=P0000000000
\end{lstlisting}
\end{figure}

In this example a topic \texttt{328}, which stands for \texttt{sports/tennis}, has been observed.
The \texttt{v} parameter specifies the version of the taxonomy, while the~\texttt{p}~parameter stands for~padding. 
Padding must be used to ensure that all~header values are of uniform length. 
Without padding, an attacker might learn the~number of~topics observed.

\begin{figure}[H]
\centering
\footnotesize
\begin{lstlisting}[caption={Topics API response header example}, captionpos=b, label={lst:topics_response_header}]
Observe-Browsing-Topics: ?1
\end{lstlisting}
\end{figure}

If the \texttt{Observe-Browsing-Topics} header is set to \texttt{?1} it means that the~server has observed the~topics listed in the~request header.

The Topics calculation is based on the user's past browsing activity during a certain period of time.
This period is known as an epoch.
As of February 2025, in Google~Chrome this epoch is set to be 1 week.
Topics API returns at~maximum 3 topics, each of which is from a different epoch and is returned in~random order.
It is worth noticing that the caller will receive three topics only if~the~caller has observed a~topic for the~current user during the~most recent three epochs.
This ensures that the~returned topics are up-to-date.
The~topic for~the~epoch is randomly chosen from~the~user's top five topics for~that epoch.
If less than 5 topics were calculated for a~certain epoch, then a~random topic is used to fill in.
There is always a 5\% chance that the returned topic is completely random.
The list of user's top 5 topics for a certain epoch is created by sorting the topics by its utility and then by its frequency.
If~the~caller is present on~different websites as a~third party providing adtech services, then the~returned topics will be recalculated for~each website.

\begin{table}[h]
    \centering
    \caption[Example of user's browsing history -- Week~1]{Example of user's browsing history -- Week~1 (own work)}
    \begin{tabular}{|l|l|l|}
        \hline
        \textbf{Web site} & \textbf{Topics} & \textbf{Api callers on site} \\
        \hline
        cars.example & /Autos \& Vehicles & adtechA \\
        books.example & /Books \& Literature & adtechB \\
        investing.example & /Finance/Investing & adtechA \\
        games.example & /Games & none \\
        \hline
    \end{tabular}
    \label{tab:topics_browser_history1}
\end{table}

As a showcase of Topics API, Table \ref{tab:topics_browser_history1} shows a simple user's browsing history during a single epoch.
The table shows the Web site's name, the~topics that can be observed, and~API callers that are present on~site.
After the end of the first epoch, the \texttt{adtechA} can able to receive the \texttt{/Autos \& Vehicles} and \texttt{/Finance/Investment} topics.
The \texttt{adtechB} can receive \texttt{/Books \& Literature}.
The topic \texttt{/Games} cannot be received because there have been no calls to the Topics API on the site.

\begin{table}[h]
    \centering
    \caption[Example of user's browsing history -- Week~2]{Example of user's browsing history -- Week~2 (own work)}
    \begin{tabular}{|l|l|l|}
        \hline
        \textbf{Web site} & \textbf{Topics} & \textbf{Api callers on site} \\
        \hline
        dogs.example & /Dogs & adtechA, adtechB \\
        books.example & /Books \& Literature & adtechA \\
        \hline
    \end{tabular}
    \label{tab:topics_browser_history2}
\end{table}

Table \ref{tab:topics_browser_history2} shows the browsing history of the user in the second epoch.
After the end of the second epoch, both \texttt{adtechA} and \texttt{adtechB} can receive topic \texttt{Dogs} and in addition, \texttt{adtechA} can now also receive the topic \texttt{/Books \& Literature}.
After 2 more epochs, the topics from the first epoch may disappear if the websites are not visited again, except the topic \texttt{/Books \& Literature} for \texttt{adtechA} because it was visited in the second epoch. 

\begin{table}[h]
    \centering
    \caption[Example of user's browsing history -- Week~3]{Example of user's browsing history -- Week~3 (own work)}
    \begin{tabular}{|l|l|l|}
        \hline
        \textbf{Web site} & \textbf{Topics} & \textbf{Api callers on site} \\
        \hline
        foodie.example & /Food \& Drink & adtechA \\
        makeup.example & /Beauty \& Fitness & adtechA \\
        \hline
    \end{tabular}
    \label{tab:topics_browser_history3}
\end{table}

The user's browsing history from the third epoch can be seen in Table~\ref{tab:topics_browser_history3}.
After the end of this epoch, the topics receivable for \texttt{adtechB} remain untouched.
On the other hand, \texttt{adtechA} can now receive 2 additional topics: \texttt{/Food \& Drink} and \texttt{/Beauty \& Fitness}.

\begin{table}[!h]
    \centering
    \caption[Example of user's browsing history -- Week~4]{Example of user's browsing history -- Week~4 (own work)}
    \begin{tabular}{|l|l|l|}
        \hline
        \textbf{Web site} & \textbf{Topics} & \textbf{Api callers on site} \\
        \hline
        cars.example & /Autos \& Vehicles & adtechA \\
        \hline
    \end{tabular}
    \label{tab:topics_browser_history4}
\end{table}

Let us say that the user visits the same website related to cars during the~fourth epoch and there are no other websites that contain API calls to~Topics, as shown in Table \ref{tab:topics_browser_history4}.
After the end of the fourth epoch, topics observed during the first epoch are no longer accessible.
Only the~topics observed during the~second, third, and fourth epochs are accessible.
This leaves us with \texttt{/Books \& Literature}, \texttt{/Food \& Drink} and \texttt{/Beauty \& Fitness} being able to access by \texttt{adtechA}. The topic \texttt{/Dogs} can be accessed by both \texttt{adtechA} and \texttt{adtechB}.
\texttt{/Finance/Investing} is no longer accessible by anyone.

Topics API offers relevant advertising while focussing on user privacy.
In~comparison to~FLoC, Topics~API does not contribute to~the~user's fingerprint and does not allow the website to track users based on~the~topics it has received.
It is important to mention that the Topics~API is still in~the~testing phase and is~not compatible with all browsers.