%---------------------------------------------------------------
\chapter{Methodology and Implementation}
\label{chap:methodology}
%---------------------------------------------------------------

This chapter describes the method of selecting an approach to verify the effectiveness and reliability of browser anti-fingerprinting measures.
It describes the process of designing the testing environment, the selection of browsers and~configurations, and the implementation of tools for data collection.
Emphasis is placed on simulating real-world usage patterns while ensuring consistency and reproducibility across test cases.
Subsequently, attention is directed towards the comprehensive analysis.
The chapter focusses on user-level countermeasures, particularly those based on data randomisation and unification techniques.

%---------------------------------------------------------------

\section{Research Design}

The original concept of the experimental framework formed in January 2024, marked by the inception of a comprehensive test suite intended to assess various mechanisms against browser fingerprinting. 
This initial stage included the development of~a~specialised website, along with the establishment of~a~back-end server designed for the dual purposes of data accumulation and evaluative processes, supplemented by supporting scripts for the facilitation of data processing tasks. 
Subsequently, a phase of data collection was executed through January and February 2024. 
This involved employing a diverse array of browser and operating system configurations strategically chosen to~accurately reflect both typical user behaviour and more atypical edge-case scenarios. 
The~findings derived from this meticulous data collection process constitute the~basis for the analytical discourse elaborated within this thesis.

A qualitative research methodology was chosen for this thesis for several reasons. 
Studies that systematically evaluate the effectiveness of browser anti-fingerprinting mechanisms are limited in number, thereby posing challenges in acquiring an adequate quantity of high-quality, comparable quantitative data from the extant literature. 
As a result, undertaking a comprehensive qualitative analysis on a limited but well-defined set of configurations presented a more feasible and meaningful approach.

The qualitative method was also suitable because it allowed an in-depth analysis of the behaviour of different browsers and operating systems under controlled conditions~\cite{Hendl2008-cm}. 
Through the examination of a limited subset of~chosen combinations, it became possible to thoroughly observe and interpret the~methodologies employed to mitigate browser fingerprinting and~the~manner in~which these strategies are implemented in~practical scenarios.

Another important reason for choosing a qualitative approach is the flexibility it offers. 
In contrast to the inflexible nature of quantitative frameworks, qualitative research provides researchers with increased flexibility in~formulating test scenarios, gathering data, and adjusting the analytical process as~new insights are discovered. 
This was particularly valuable in the context of~browser fingerprinting, where small changes in the environment or configuration can lead to significantly different results.

The qualitative methodology allowed for a comprehensive and detailed exploration of the mechanisms through which fingerprinting countermeasures function on a variety of platforms. 
This depth of understanding is challenging to achieve solely through statistical analyses.

To support this qualitative analysis, a modular experimental architecture was designed, consisting of three tightly integrated components:
\begin{enumerate}
    \item Website\ -- collects a series of semi-identifiers and browser identifiers
    \item Server\ -- receives and stores the data, detects signs of randomisation
    \item Analysis\ -- analyses the uniqueness, stability, and entropy of stored data
\end{enumerate}
Each component plays a specific role in the experimental workflow, ensuring high-quality data collection and allowing meaningful conclusions on~the~effectiveness of fingerprints under adversarial conditions.
The combination of~these three components provides a complete end-to-end pipeline to explore the fingerprints of modern browsers. 
This experimental framework allows for~a~detailed evaluation of the quality of the fingerprints and the impact of the obfuscation strategy. 

Data were collected from 3 different devices and multiple operating systems and multiple browsers as shown in Table~\ref{tab:tested-configs}.
The operating systems selected for testing include Windows 10, Windows 11, Ubuntu Linux, and macOS 14. 
Windows 10 and 11 were chosen as they represent the majority of desktop users worldwide~\cite{statcounter_os_marketshare}. 
MacOS 14 was included, as it represents another significant portion of the market. 
Ubuntu Linux was selected to represent open-source Unix-based systems and to evaluate fingerprinting behaviour in open-source environments, which may differ due to the community-driven development and alternative system configurations.

\begin{table}[H]
\centering
\caption[Overview of tested devices, operating systems, and browsers]{Overview of tested devices, operating systems, and browsers}
\begin{tabular}{|>{\raggedright\arraybackslash}p{0.1\textwidth}|
                >{\raggedright\arraybackslash}p{0.2\textwidth}|
                >{\raggedright\arraybackslash}p{0.6\textwidth}|}
    \hline
    \textbf{Device} & \textbf{OS} & \textbf{Browsers Tested} \\
    \hline
    PC A & Windows 10 & Google Chrome, Firefox, Brave, Tor Browser \\
    \hline
    PC A & Ubuntu 23.10 & Google Chrome, Firefox, Brave, Tor Browser \\
    \hline
    PC B & Windows 11 & Google Chrome, Firefox, Brave, Tor Browser \\
    \hline
    PC C & macOS 14 & Apple Safari, Google Chrome, Brave, Firefox, Tor Browser \\
    \hline
\end{tabular}
\label{tab:tested-configs}
\end{table}

Five browsers were selected for analysis. 
Among these, Google Chrome, Firefox, and~Apple~Safari are representative of the most widely used browsers~\cite{browser_usage_data}. 
The additional two, Brave and Tor, were chosen because of their unique methodologies in reducing browser fingerprinting: Brave employs a randomisation strategy, while Tor adopts a unification approach.
Microsoft Edge was excluded from selection due to its lack of supplementary anti-fingerprinting security mechanisms when compared to Google Chrome.
Collectively, these browsers account for more than 90\% of the global browser market share.
The specific versions that were analysed are listed in Table~\ref{tab:browser_versions}.

\begin{table}[h]
\centering
\caption[Browsers and their examined versions]{Browsers and their examined versions}
\begin{tabular}{|l|l|}
\hline
\textbf{Browser} & \textbf{Examined Version} \\
\hline
Google Chrome & 121.0 \\
Mozilla Firefox & 122.0 \\
Safari & 17.3 \\
Brave & 1.62 \\
Tor Browser & 13.0 \\
\hline
\end{tabular}
\label{tab:browser_versions}
\end{table}


PC1 is a desktop computer selected to represent typical stationary setups with potentially higher hardware variability and customisation.
PC2 is a laptop, included to reflect mobile computing environments with integrated hardware components and power-saving configurations that may influence fingerprinting behaviour.
PC3 is a MacBook Pro equipped with the Apple M3 Pro chip and running macOS 14, chosen to represent modern ARM-based architectures and the growing adoption of Apple Silicon devices.
Their components are listed in Table~\ref{tab:device-specs}.
It is important to describe the hardware configuration of the tested devices in order to better understand the variability of the collected fingerprint data. 
These parameters are especially important because some fingerprinting techniques, such as hardware compatibility or~canvas and~audio rendering, can be influenced by~the~underlying hardware.

\begin{table}[H]
\centering
\caption[Hardware specifications of the tested devices]{Hardware specifications of the tested devices}
\begin{tabular}{|>{\raggedright\arraybackslash}p{0.1\textwidth}|
                >{\raggedright\arraybackslash}p{0.25\textwidth}|
                c|c|
                >{\raggedright\arraybackslash}p{0.25\textwidth}|}
    \hline
    \textbf{Device} & \textbf{CPU} & \textbf{Cores} & \textbf{RAM} & \textbf{GPU} \\
    \hline
    PC A & Intel Core i5-3340 & 4 & 16 GB & NVIDIA GeForce GTX 1050 Ti \\
    \hline
    PC B & Intel Core i5-8300 & 8 & 8 GB & NVIDIA GeForce GTX 1050 \\
    \hline
    PC C & Apple M3 Pro & 12 & 18 GB & Apple M3 Pro \\
    \hline
\end{tabular}
\label{tab:device-specs}
\end{table}

Table~\ref{tab:data-number} shows the amount of data collected for each combination of~device, operating system, and browser.
Approximately 50 to 200 iterations were conducted for each configuration to determine statistical significance. 
The~combination of browser and operating system was selected to represent both practical usage scenarios and a broad range of technical parameters.
Ubuntu Linux was only tested on PC A in a dual-boot configuration to explore fingerprinting behaviour in a Unix-like system under a single hardware setup. 

During the data collection phase, the Brave browser offered two distinct levels of fingerprint protection: \textit{Classic} and \textit{Strict}. 
For the purpose of evaluating and contrasting the efficacy of these configurations, data was gathered and examined separately for each setting.
In the course of this research, Brave integrated these configurations, opting for a default protection mode based primarily on the enhanced \textit{Strict} setting.
Consequently, the \textit{Classic} mode is no longer actively implemented within the browser.
This reason is similar to~the~fact that the data gathered in Brave Browser are often twice as extensive as those obtained from other sources.
This change is explained in~detail in~Chapter~\ref{chap:brave}.

\begin{table}[H]
\centering
\caption[Fingerprinting samples comparison across devices]{Fingerprinting samples comparison across devices}
\begin{tabular}{|c|c|c|c|c|}
\hline
\textbf{OS} & \textbf{Browser} & \textbf{PC A} & \textbf{PC B} & \textbf{PC C} \\
\hline
Windows 10 & Google Chrome                        & 1 & -- & -- \\
Windows 10 & Firefox (Classic, Aggressive) & 100, 101 & -- & -- \\
Windows 10 & Brave (Classic, Strict)   & 100, 101 & -- & -- \\
Windows 10 & Tor                           & 10 & -- & -- \\
Windows 10 & Apple Safari (Classic, Private)     & -- & -- & -- \\
\hline
Windows 11 & Google Chrome                        & -- & 1 & -- \\
Windows 11 & Firefox (Classic, Aggressive) & -- & 52, 51 & -- \\
Windows 11 & Brave (Classic, Strict)   & -- & 152, 205  & -- \\
Windows 11 & Tor                           & -- & 10 & -- \\
Windows 11 & Apple Safari (Classic, Private)     & -- & -- & -- \\
\hline
Ubuntu     & Google Chrome  & 1 & -- & -- \\
Ubuntu     & Firefox (Classic, Aggressive) & 62, 50 & -- & -- \\
Ubuntu     & Brave (Classic, Strict)   & 99, 100 & -- & -- \\
Ubuntu     & Tor                           & 10 & -- & -- \\
Ubuntu     & Apple Safari (Classic, Private)     & -- & -- & -- \\
\hline
macOS 14   & Google Chrome                        & -- & -- & 1 \\
macOS 14   & Firefox (Classic, Aggressive) & -- & -- & 1, 97 \\
macOS 14   & Brave (Classic, Strict)   & -- & -- & 100, 101 \\
macOS 14   & Tor                           & -- & -- & 10 \\
macOS 14   & Apple Safari (Classic, Private)     & -- & -- & 2, 50 \\
\hline
\end{tabular}
\label{tab:data-number}
\end{table}

The data collection period occurred between January and February 2024.
Throughout this period, fingerprinting data were systematically collected across diverse browsers and operating systems via the developed website.
However, the Tor Browser posed a unique challenge, as the server provider responsible for hosting the data collection back-end implemented measures to block all traffic originating from the Tor network.
As a result, it was not possible to~collect data through the regular process.
To address this limitation, the~fingerprinting data from Tor were manually extracted by copying the JSON output from the browser's developer console and converting it into CSV format using a support script.
The manual method of this process restricts the volume of~Tor Browser entries gathered.
However, this limitation is not problematic because the Tor Browser is designed to unify fingerprinting surfaces among its users.
Therefore, it was not necessary to verify the randomness or variability in the Tor Browser data collected.

%---------------------------------------------------------------

\section{Webpage}

The first component of the system is a fingerprinting web page designed to automatically collect a comprehensive set of client-side attributes from its visitors when loaded.
These attributes include semi-identifiers such as IP addresses, language settings, user agent data, and more granular fingerprint signals such as canvas fingerprints, audio fingerprints, and available fonts. 
Together, these data points form high-entropy fingerprints that can be used to uniquely identify and track users in sessions. 
These scripts also collect information about the~user's environment, such as battery status, media devices, screen resolution, browser functionality, and available storage APIs. 
The Web page employs client-side JavaScript alongside some browser APIs to replicate the functionality of authentic tracking scripts, thereby exercising full oversight over the~fingerprinting mechanisms. 
The objective of this component is to emulate real-world fingerprinting activities and gather extensive high-entropy data utilising client-side JavaScript and browser APIs.
After the collection of all active and~passive fingerprints, the data is transmitted in JSON format to~a~back-end server for storage and further analysis.
The data collected can be divided according to chapter~\ref{chap:fingerprinting} into active and passive fingerprints.
This categorisation reflects the way each attribute is obtained, either passively through default browser behaviour or actively through explicit API calls and script execution. 
It is important to note that the objective of this thesis is to evaluate various countermeasures against fingerprinting.
Therefore, no comprehensive collection of all potential fingerprintable information was conducted. 
Although there exists a vast array of data that can be gathered for such purposes, the~compiled data set was limited to only the most relevant and significant data.
Furthermore, data capable of immediately identifying the device were not collected, as their inclusion in the analysis would not be practical.

The following section provides a detailed overview of all fingerprinting attributes gathered by the webpage, structured according to this classification.
In Table~\ref{tab:passive-fp}, all passive fingerprinting attributes collected by the website are listed, along with their corresponding names and example values.
These attributes are acquired without engaging in any browser-side computations or~active probing mechanisms. They are generally accessible by default within request headers or fundamental JavaScript properties.
The IP address was included as part of the passively collected data. 
While it is not possible to directly acquire the IP address using JavaScript because of security constraints imposed by browsers.
The data is visible to the server because of a GET request sent to it.
Consequently, the server processes this request and provides the IP address as a response.
This methodology mirrors the operational framework of numerous fingerprinting service providers, which generally function as~independent third-party organisations
In these scenarios, the acquisition of~certain fingerprinting data is conducted on the server-side, eliminating the~necessity for executing any scripts on the client's browser except during the~request phase.
Within this context, although it is feasible to bypass the initial step of this request and gather the IP address upon obtaining the dataset, it should be noted that presenting the IP address would then necessitate its transmission back to the originating source, as is currently practised.
In light of this, the dataset employed for passive fingerprinting includes IP addresses as one of its integral components.

\begin{table}[H]
    \centering
    \caption[Passive fingerprinting techniques]{Passive fingerprinting techniques}
    \begin{tabular}{|>{\raggedright\arraybackslash}p{0.45\textwidth}|
                    >{\raggedright\arraybackslash}p{0.45\textwidth}|}
        \hline
        \textbf{Technique} & \textbf{Example values} \\
        \hline
        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 \\
        \hline
        User-Agent Data & \{ "brands": [ \{ "brand": "Google Chrome", "version": "135" \}, \{ "brand": "Not-A.Brand", "version": "8" \}, \{ "brand": "Chromium", "version": "135" \} ], "mobile": false, "platform": "macOS" \} \\
        \hline
        Accept & */* \\
        \hline
        Accept-Charset & null \\
        \hline
        Accept-Encoding & gzip, deflate, br, zstd \\
        \hline
        Accept-Language & cs-CZ,cs;q=0.9,en;q=0.8 \\
        \hline
        IP Address & 85.193.2.217 \\
        \hline
    \end{tabular}
    \label{tab:passive-fp}
\end{table}




Active fingerprint attributes are listed in Table~\ref{tab:active-fp}.
Active fingerprint attributes are acquired through direct interaction with the browser and system APIs. 
Such attributes typically exhibit a higher degree of uniqueness and~demonstrate increased resilience against spoofing attempts.

It is crucial to mention that the entire gathered data set is not transmitted to the server. 
Prior to forwarding, an additional selection process is conducted to ensure that only the most identifiable pieces of information are transmitted. 
Information that does not contribute significantly to user identification is deliberately skipped from the transmission sequence. 
These specific exclusions have been instituted for the purpose of the present analysis.
However, in~a~practical, real-world context, such data points would generally be incorporated into the fingerprinting methodology.

\begin{longtable}{|>{\raggedright\arraybackslash}p{0.3\linewidth}|>{\raggedright\arraybackslash}p{0.65\linewidth}|}
\caption[Active fingerprinting techniques]{Active fingerprinting techniques \label{tab:active-fp}} \\
\hline
\textbf{Technique} & \textbf{Example Values} \\
\hline
\endfirsthead

\hline
\textbf{Technique} & \textbf{Example Values} \\
\hline
\endhead

\multicolumn{2}{r}{\emph{(continued on next page)}} \\
\endfoot

\endlastfoot

    Time Zone & Europe/Prague \\
    \hline
    Battery level & 100 \\
    \hline
    Is charging & true \\
    \hline
    Discharging time & 0 min \\
    \hline
    Connection type & Not allowed \\
    \hline
    Effective type & 4g \\
    \hline
    Network status & Online \\
    \hline
    Operating System & Windows \\
    \hline
    Device Memory & 8 GB \\
    \hline
    CPU core count & 4 \\
    \hline
    OS CPU & Not available \\
    \hline
    CPU Class & undefined \\
    \hline
    Screen Width & 2048 \\
    \hline
    Screen Height & 1152 \\
    \hline
    Usable Screen Width & 2048 \\
    \hline
    Usable Screen Height & 1122 \\
    \hline
    Colour Depth & 24 bit \\
    \hline
    Touch Screen & False \\
    \hline
    Browser Name & Google Chrome \\
    \hline
    Browser Core & Chromium \\
    \hline
    Browser Version & 135 \\
    \hline
    Build Number & 20030107 \\
    \hline
    Navigator Properties & 82 \\
    \hline
    Browser Permissions & [``accelerometer'', ``background-sync'', ``clipboard-write'', ``gyroscope'', ``magnetometer'', ``payment-handler'', ``storage-access''] \\
    \hline
    IndexedDB & Enabled \\
    \hline
    Open Database & Disabled \\
    \hline
    Local Storage & Enabled \\
    \hline
    Session Storage & Enabled \\
    \hline
    Global Storage & Disabled \\
    \hline
    PDF Viewer & Enabled \\
    \hline
    Cookies Enabled & True \\
    \hline
    AdBlock & False \\
    \hline
    Encryption Methods & Not Available \\
    \hline
    Vendor & null \\
    \hline
    Unmasked Vendor & Google Inc. (NVIDIA) \\
    \hline
    Renderer & WebKit WebGL \\
    \hline
    Unmasked Renderer & ANGLE (NVIDIA, NVIDIA GeForce GTX 1050 Ti (0x00001C82) Direct3D11 vs\_5\_0 ps\_5\_0, D3D11) \\
    \hline
    Shading Language Versions & WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium) \\
    \hline
    Available Browser Storage & 450 GB \\
    \hline
    Media Capabilities & [``id: 0, label: no label defined, kind: audioinput'', ``id: 1, label: no label defined, kind: audiooutput''] \\
    \hline
    Installed Plugins & PDF Viewer, Chrome PDF Viewer, Chromium PDF Viewer, WebKit built-in PDF \\
    \hline
    Available Fonts & Arial Black, Arial Narrow, Arial \dots \\
    \hline
    Canvas & be4268f5934d9398e17a34f5ae6435621e6409$\cdots$ \\
    \hline
    WebGL Canvas & 834970f9607c1095ba84e76b18flb092beb2a3$\cdots$ \\
    \hline
    Audio Fingerprint Sum & 99.9682779353675 \\
    \hline
    Audio Fingerprint Hash & 8aa45856cf58e5f5b3363f3lf727711dfe4c8b0$\cdots$ \\
    \hline
\end{longtable}

The underlying rationale for this methodology can be detailed as follows:
\begin{itemize}
    \item \textbf{Browser version} – was excluded because all tested browsers were updated to the latest version, resulting in identical values across configurations. Additionally, this value does not reflect every update, which makes it less useful for fingerprinting purposes.

    \item \textbf{Build number} – if each device had a different value, it would be trivial to distinguish between them. Therefore, this attribute was intentionally excluded to avoid overly simplistic identification.

    \item \textbf{Accept Header} – initial analysis showed that these values are often identical between different browsers and users, offering a minimal discriminatory value for identification.

    \item \textbf{Battery status} – this attribute is either unsupported or returns fixed values in most modern browsers. As a result, it was not considered useful for this analysis.

    \item \textbf{Connection type} – similar to battery status, this information is either unavailable or too limited in variability to be useful for analysis.

    \item \textbf{Storage information} – this attribute was excluded due to the lack of~a~clear method for utilizing it effectively in fingerprinting. Moreover, it can vary frequently and is not suitable for reliable identification.
\end{itemize}

The website is structured as follows:
\begin{itemize}
    \item \textbf{Browser and Device Attributes} \\
    This section collects information about the device and browser using \linebreak the~\texttt{navigator} object and related APIs. 
    It includes attributes such as platform, browser name, version, device memory, CPU cores, and browser permissions. \\
    \textit{APIs used:} \texttt{navigator}, \texttt{navigator.permissions}, \texttt{window}, \texttt{Batery API}, \texttt{Canvas API}, \texttt{Connection API},  \texttt{Storage API} \\
    \textit{Type:} Active and Passive Fingerprinting

    \item \textbf{Media Capabilities} \\
    This section compiles data regarding the user's audio and visual input/output apparatuses through the utilization of the MediaDevices API. 
    It acquires an inventory of linked devices, such as microphones, speakers, and~webcams, which may differ across systems. 
    The quantity, classification, and~denominations of these devices have the potential to enhance the distinctiveness of a fingerprint. \\
    \textit{API used:} \texttt{MediaDevices API} \\
    \textit{Type:} Active Fingerprinting

    \item \textbf{Plugins} \\
    Gathers information regarding installed browser plugins.  
    While this method is deprecated in contemporary browsers, it remains functional in certain instances. \\
    \textit{API used:} \texttt{navigator.plugins} \\
    \textit{Type:} Active Fingerprinting

    \item \textbf{Fonts} \\
    Utilizes JavaScript and CSS-rendering differences to identify installed fonts. 
    This approach determines the availability of specific fonts on the system by analysing the styling and rendering differences of text. \\
    \textit{APIs used:} \texttt{canvas} \\
    \textit{Type:} Active Fingerprinting

    \item \textbf{Canvas Fingerprinting} \\
    Employs the HTML5 \texttt{<canvas>} element and rendering techniques to create a distinctive fingerprint by analysing the manner in which the browser and~GPU process and produce graphics.
    This part includes a visual representation of the generated graphic outputs. \\
    \textit{API used:} \texttt{HTMLCanvasElement}, \texttt{toDataURL}, \texttt{getImageData} \\
    \textit{Type:} Active Fingerprinting

    \item \textbf{Audio Fingerprinting} \\
    Uses the Web Audio API to play and examine sound using a configured graph of audio nodes. 
    The output is affected by the device's audio stack and generates a hash as a fingerprint.
    This section additionally includes a~visual representation of the audio output that has been generated. \\
    \textit{API used:} \texttt{Audio API}, \texttt{OscillatorNode}, \texttt{DynamicsCompressorNode} \\
    \textit{Type:} Active Fingerprinting


    \item \textbf{Fingerprint Result} \\
    This section presents the outcomes of the fingerprint analysis conducted on the server. 
    Upon a client’s connection to the page, a fingerprint is generated and transmitted to the server. 
    The server subsequently assesses whether the user has prior visits and evaluates if the fingerprint appears to be randomised due to factors such as browser extensions, anti-tracking functionalities, or customised configurations. 
    The client is then notified regarding the detection of a match or the presence of randomisation.
\end{itemize}
The website also contains a drop-down menu that was used as a parameter setting during the data collection phase.

%---------------------------------------------------------------

\section{Server Back-end}

% popisuji jak a kde jsem hostoval API server \\
% duvody, proc jsem zvolil testovani na externim serveru a ne na lokalnim \\
% zminuji omezeni testovani Tor Browseru \\
% popisuji architekturu API a end-pointy \\
% kratce popisuji naivni a komplexni algoritmus \\
% nevim, zda zde i uvadet nedostatky, na ktere jsem prisel pote v prubehu, nebo az do diskuse ci vubec \\
% argumentuji zbusob ukladani dat a obecne vyber FP dat a tvorbu tohoto API \\

In order to consistently identify users without resorting to cookies or local storage mechanisms, the server-side procedures within my application employ an identification based on fingerprinting. 
This system conducts an extensive analysis of browser and device characteristics to determine if a visitor has previously accessed the application. 
The identification procedure is orchestrated through a series of distinct phases, which collectively constitute a streamlined and effective server infrastructure.

The API server was deployed on a virtual private server (VPS) that was hosted externally, rather than being hosted on a local server.
This decision was based on several factors.
\textit{Availability}, users accessing the system from~various networks and devices experienced uninterrupted service and constant uptime due to the usage of an externally managed server. 
\textit{Realistic Network Conditions}, by leveraging an external server, it was able to replicate conditions closely simulating real-world scenarios, which was particularly beneficial for~accurately assessing network latency and the intricacies of geographic routing.
\textit{Behaviour}, numerous browsers exhibit distinct behaviours when accessing a~file stored locally on a computer compared to navigating a webpage hosted on~a~remote server.
Using a remotely hosted VPS introduced several challenges. 
One significant issue was the firewall settings of the hosting provider, which restricted any inbound or outbound connections associated with the~Tor~network. 
This stringent firewall policy did not allow for any exceptions for~the~use case of this research. 
Consequently, the research was forced to~perform all Tor Browser testing operations on a local setup instead of using the hosted environment.

In order to enhance the identification of both randomised and fabricated browser fingerprints, a specialised back-end server was carefully constructed. 
This server is implemented using Python, with the Flask framework serving as its foundational platform~\cite{flask_2025}. 
Its core responsibilities include the intake of data transmitted from the client side, performing a thorough analysis of~these data through the application of detection algorithms, and systematically archiving fingerprints for subsequent detailed examination and interpretation.
The back-end architecture is organised in a modular approach to ensure clear separation of responsibilities.
In the upcoming sections, a detailed introduction to each essential component of the back-end is provided, detailing its specific duties and its integral function within the broader system framework. 
The~primary modules are described in detail below.

The \texttt{receiver.py} module serves as the central entry point for the back-end application.
The server's runtime operations are managed, and all API endpoints are specified within it. 
Constructed with Flask, the server is designed to accommodate cross-origin requests employing flask-cors~\cite{dolphin_corydolphinflask_cors_2025}.
This module offers several HTTP endpoints for interacting with the server:
\begin{itemize}
    \item \textbf{/get-accept-headers} -- Returns selected HTTP headers from the client
    \item \textbf{/get-ip} -- Returns the user's IP address
    \item \textbf{/save-user} -- Manual submission and storage of fingerprint data for~a~named user
    \item \textbf{/check} -- The main back-end logic, returns whether the user has already visited the website
\end{itemize}
The fundamental process of \texttt{/check} involves several stages. 
Initially, JSON data holding the user's fingerprint are received. 
This information is parse and~is subsequently passed on to complex and naive identification algorithms. 
The~server then returns the results of each algorithm along with an overall result. 
The result is marked as true if any algorithm identifies the user, indicating a previous visit to the website. 
If the user's identity is confirmed and~the~fingerprint has altered, the information is recorded. 
In contrast, unmodified fingerprints do not result in data storage. 
If the user remains unidentified, the~data is still saved.
The data is stored in CSV format.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.6\textwidth]{figures/methodology_user_server_communication.png}
    \caption[Illustration of communication between user and server]{Illustration of communication between user and server (own work)}
    \label{fig:methodology_user_server_comm}
\end{figure}

The diagram presented in Figure \ref{fig:methodology_user_server_comm} illustrates the detailed communication process between the browser and the server, particularly focussing \linebreak on~how~the~client-side fingerprinting webpage interacts with~the~\texttt{receiver.py} server. 
This diagram describes the sequence of data collection within the~browser via fingerprintings scripts and communication with API end-points.
Its onwards transmission to designated API endpoint and the server's actions in responding with results.

This module also manages farbling testing.
It performs a CPU examination to detect any modifications to hardware concurrency by contrasting the~recorded number against a typical array of CPU values. 
Furthermore, a~memory evaluation of the reading with a comprehensive list of possible outcomes of \texttt{navigator.deviceMemory}. 
Both checks are designed to confirm the~presence of any randomisation, returning true if detected.
In the final farbling test, the user's resolution is contrasted with the most used resolutions, resulting in~a~calculation of a similarity score. 
Should no resolution achieve a similarity score exceeding a predefined threshold, the resolution is considered as randomised.
Upon detecting a randomisation, the resolution closest in~similarity is logged in the user's record and subsequently utilised for~comparisons with other users.
The results are then returned to the browser and~used in~the~complex identification algorithm.

The \texttt{data\_manager.py} module functions as the data access and storage component of the back-end infrastructure. 
It is primarily tasked with handling the input and output processes involving CSV files that contain browser fingerprint data submissions.
The functions of this module are designed to~simplify and abstract interactions with file storage, ensuring that the main detection algorithms found in \texttt{naive.py} and \texttt{complex.py}, as well as the API interface in \texttt{receiver.py}, stay independent from fundamental input/output operations.
When data from a user are provided via the \texttt{/check} endpoint, it gets appended to the user's \texttt{ID} and \texttt{Log} records. 
In contrast, if data are acquired through the~\texttt{/save-user} endpoint, the untouched user data are stored directly in~the~file assigned to that particular user.

Once the architecture and data flow of the back-end system are outlined, it is crucial to explore the primary fingerprint identification strategies that assess whether a new browser fingerprint aligns with a previously recorded one. 
The~two core algorithms involved are the following.
Naive Identification Algorithm, is a basic yet rapid technique for fingerprint comparison.
Complex Identification Algorithm, represents a more advanced approach that uses dynamic thresholds and results from farbling tests to enhance the detection of~randomised or spoofed fingerprints.
These algorithms are tailored to address the varying demands for sensitivity and detail in fingerprint identification. 
In practical applications, the naive method offers speed but lacks robustness against methods of obfuscation, whereas sophisticated logic is fundamental to~counter more developed anti-tracking measures effectively.

The \texttt{naive.py} module offers a straightforward method for determining returning users through attribute comparison, expanding its approach by evaluating how many fingerprint fields align between a new data entry and existing records. 
This straightforward and efficient technique serves as the foundation for more sophisticated techniques. 
Each stored fingerprint is meticulously compared against the new entry, field by field, to tally the total number of~matches. 
A user is identified as recognised in one of the three circumstances. 
Firstly, if the match count reaches a predefined threshold of 36, this essentially indicates that there is no alteration in the user's fingerprint, and~the~user is considered known. 
Secondly, the user is identified if there is a~match in any one of the \texttt{Audio}, \texttt{Canvas}, or \texttt{WebGL} fields, as these methods are considered among the most reliable by Panopticlick~\cite{eckersley_how_2010}.
In the third instance, if~the~number of~matches hits a specified limit of 30 and none of~the~key attributes align, the~user is still regarded as known.
The threshold of~30 was chosen based on the~nature of the fingerprint dataset and practical trials. 
Among~the~36 primary fingerprint attributes, some vary frequently, such as plugins or fonts, while others remain stable. 
A very high threshold (e.g., 34+) might seldom recognise returning users, even with slight changes, whereas a very low threshold (e.g., 10 or 20) would cause false positives.
A threshold of 30 provides an optimal balance, accommodating minor changes, such as those from browser updates or noise, while ensuring significant similarity. 
Empirical tests showed that matching 30 fields reliably indicates a returning user. \linebreak
Reducing the threshold to 29 or 28 could lead to a significant increase in false positives.
This threshold choice avoids tailoring solutions too narrowly to specific browsers or devices, presenting a more broadly applicable and versatile approach.
This algorithm does not break many of the security mechanisms mentioned in chapter \ref{chap:def}.

The \texttt{complex.py} module offers an advanced approach to user identification. 
If the farbling tests managed by \texttt{receiver.py} return positive results, the algorithm tries to find a user that matches the most closely. 
In contrast, if~the~results are negative, the algorithm focuses its search on matching the~three key values, disregarding other semi-identifying factors, as they are unnecessary in this case.
During the look-alike search, it distinguishes between hash and exact values, assigning each type a unique weight that contributes to~the overall score assigned to each user. 
This score is compared to a threshold that adapts based on the larger value between 75 or the average similarity scores across all users. 
The assigned weights have undergone empirical testing and optimisation to minimise false positives while still identifying users using protective measures.
Upon detecting a randomisation of screen resolution, the~algorithm selects the resolution with the greatest similarity score to~match against other users and records it in the user's log for future reference.
The~list of attributes considered in the complex algorithm and their weights can be seen in Table \ref{tab:complex_weights}

\begin{table}[H]
\centering
\caption[Overview of attributes and weights in complex algorithm]{Overview of attributes and weights in complex algorithm}
\begin{tabular}{|l|l|}
    \hline
    Attributes Hash     & 0 \\
    Audio Fingerprint   & 10 \\
    Canvas Fingerprint  & 10 \\
    Fonts               & 2 \\
    WebGL Fingerprint   & 10 \\
    Media Fingerprint   & 4 \\
    Plugins Fingerprint & 4 \\
    \hline
    IP                         & 2 \\
    CPU                        & 2 \\
    Memory                     & 3 \\
    Screen Width               & 2 \\
    Screen Height              & 2 \\
    Usable Screen Width        & 2 \\
    Usable Screen Height       & 2 \\
    Colour Depth                & 2 \\
    Touch Screen               & 2 \\
    Browser Name               & 5 \\
    Browser Core               & 5 \\
    Navigator Properties       & 3 \\
    Browser Permissions        & 3 \\
    IndexedDB                  & 2 \\
    Open Database              & 2 \\
    Local Storage              & 1 \\
    Session Storage            & 1 \\
    Global Storage             & 1 \\
    PDF Viewer                 & 1 \\
    Cookies Enabled            & 1 \\
    Do not track               & 1 \\
    AdBlock                    & 2 \\ 
    Encryption methods         & 1 \\
    Navigator Vendor           & 2 \\
    Vendor                     & 2 \\
    Unmasked Vendor            & 2 \\
    Renderer                   & 2 \\
    Unmasked Renderer          & 2 \\
    Shading Langueage Versions & 2 \\
    \hline
\end{tabular}%
\label{tab:complex_weights}
\end{table}

The naive algorithm is straightforward and clear, perfect for tasks that are small or low-risk. 
However, its simplicity means it struggles with data tampering and overlooks the varying significance of fingerprint characteristics. 
However, the complex algorithm includes specific weights for attributes, uses dynamic thresholds, and accounts for possible farbling. 
Although it requires more computational power and direct interpretation is challenging, it offers a~notably better accuracy and durability in practical applications.
Mention must be made of the fact that none of these algorithms is effective against the~randomisation of the three primary attributes, nor can it counter unification-based anti-fingerprinting strategies.

The precision of these algorithms is shown in Figure \ref{fig:algorithm_matrixes}, which illustrates the confusion matrix comparing the performance of both algorithms. 
The data represent the average results for each algorithm based on all the data gathered. 
In each simulation, the model evaluated whether two browser sessions originated from the same user (actual positive class) or from different users (actual negative class).
In this context, a predicted positive means the algorithm classified the sessions as belonging to the same user, whereas a predicted negative indicates that the algorithm judged them to be from different users.
The top-left cell of each matrix represents true positives, cases where two sessions from the same user were correctly recognised as such. 
The bottom-right cell shows true negatives, sessions from different users that were correctly classified as~unrelated. 
The bottom-left cell corresponds to false positives, where different users were incorrectly identified as the same. 
The top-right cell denotes false negatives, where two sessions from the same user were mistakenly classified as unrelated.
Given the significant disparity in the amount of data collected from browsers that implement certain security features compared to~those that do not, a weighted average was not employed.
Additionally, it would fail to~replicate a real-world situation, as the majority of users do not use the~more secure browsers, which are only adopted by a small fraction of~the~user base.

\begin{figure}[H]
    \centering
    \begin{tikzpicture}[baseline]
        \node at (0, 1) {\includegraphics[width=0.5\linewidth]{figures/confusion_matrix_naive.png}};
        \node at (7, 1) {\includegraphics[width=0.5\linewidth]{figures/confusion_matrix_complex.png}};
        \node at (0, -2.5) {(a) Naive Algorithm};
        \node at (7, -2.5) {(b) Complex Algorithm};
    \end{tikzpicture}
    \caption[Confusion matrixes of identification algorithms]{Confusion matrixes of identification algorithms}
    \label{fig:algorithm_matrixes}
\end{figure}

It is essential to note that the data set includes Tor Browser data, which has the potential to artificially enhance the appearance of the data, since it always ends in a true positive for the naive algorithm.
In contrast, the complex algorithm consistently detects the application of security mechanisms and diverges from aligning users based on the trio of primary values.
If only non-Brave data were tested, the naive algorithm would have 97.42\% true positive results, since it matches the users according to the three primary fingerprints.
The~precision of the complex algorithm would also be better and the true positive rate would increase to 55.1\%.
A unification strategy completely disrupts these algorithms as it removes any means to distinguish between individual elements.
Every individual using the identical device would seem indistinguishable.
If~only Brave data were evaluated, the true positive rate would be merely 1.04\% for~the~complex algorithm and~1.9\% for~the~naive algorithm. 
However, the~false positive rate for the sophisticated algorithm would be 27.96\%, indicating its ability to~identify users, although it failed to align with the user's initial record.

In~summary, the naive algorithm excels in identifying users who haven't adopted any anti-fingerprinting measures, since it depends on consistent \linebreak and~quickly matched identifiers, making it more effective in such situations. \linebreak
On~the~other~hand, the~complex algorithm demonstrates greater resilience against users who randomise browser attributes, capturing subtle patterns indicative of fingerprinting behaviour. 
Both the randomisation and unification strategies significantly reduce the effectiveness of both algorithms. 
However, unification presents a~more robust defence against these 2 algorithms. \linebreak
Although algorithms may still report high true positive rates under unification, these are likely to be false positives in real-world scenarios, as users sharing identical platforms and screen configurations become indistinguishable from each other.

%---------------------------------------------------------------

\section{Analysis}

The thesis utilised a diverse set of mathematical and statistical methodologies to gain insight into browser data features and assess anti-fingerprinting strategies. 
To summarise multiple characteristics such as screen size, CPU core \linebreak count (\texttt{hardwareConcurrency}) and device memory (\texttt{navigator.deviceMemory}), essential descriptive statistics were calculated. 
These included the calculation of the mean, median, standard deviation, minimum, and maximum values.


To explore how various attributes interact, a correlation analysis was performed by computing the correlation coefficient, which measures the linear association between pairs of variables~\cite{bhandari_correlation_2021}. 
An extensive additional analysis was performed to assess and compare the data sets obtained from two separate user profiles operating within the same instance of the Brave browser. 
The primary objective of this comparative analysis was to determine whether there were any substantial variations in the browser's disclosed attributes or~its anti-fingerprinting mechanisms when utilised across these different profiles on~a~singular system. 

In this thesis, a Decision Tree algorithm was leveraged, not with the intention of categorising altered configurations, but to illustrate the susceptibility of~web browsers that lack robust anti-fingerprinting strategies. 
Training a basic Decision Tree with browser data illustrates how easily these browsers can be uniquely identified using accessible characteristics. 
The model's classificatory effectiveness is succinctly presented through a confusion matrix, demonstrating its precision in identifying different browser instances.

In addition, a comprehensive examination was conducted on the randomness of the values generated by web browsers, especially those equipped with randomisation functionalities, through the application of the National Institute of Standards and Technology (NIST) test suite. 
This suite is a collection of statistical tests meticulously developed to gauge the randomness present in binary sequences. 
Implementing these tests on pertinent browser characteristics allowed the researchers to conduct a quantitative evaluation of both the randomness and unpredictability inherent in the generated output values. This approach thus allowed for a comprehensive and systematic assessment of~the~efficacy of~randomisation as a technique for mitigating fingerprints.

% Popis casti: moje mat. analyza, NIST test u Brave, decision tree\\
% popisuji, matematicke funkce, ktere jsem pouzil (kvuli korelacni matici, ...) \\
% Popis co to je NIST test suite a jak jsem musel upravit data tak, abych to mohl provest \\
% Popis proc jsem vytvoril decision tree jako ukazku, ze takto naivni AI nedokaze rozpoznat zarizeni, kdyz je pouzita unifikace nebo randomizace \\ - DONE

%---------------------------------------------------------------

