%---------------published-----------------------------------
\chapter{Results and Discussion}
%---------------------------------------------------------------

This chapter details the experimental evaluation outcomes of browser fingerprint defences. 
It offers a compact summary of results, emphasising browser behaviour during fingerprinting evaluations, and subsequently interprets these findings within the context of user privacy protection.


\section{Summary of Findings}
\label{chap:summary_of_findings}

The following sections summarise the observed behaviour of the tested browsers with respect to fingerprinting resistance. 
The results are grouped into two categories: findings specific to the Brave browser and findings from the remaining browsers. 
This framework enables a clearer and more comprehensive comparison between browsers centred on randomisation and those focused on~unification.

\subsection{Brave Browser}
\label{chap:findings_brave}

This part is dedicated to an in-depth analysis of the outcomes derived from~evaluating the Brave browser. 
The browser is notable for~its integration of~sophisticated mechanisms designed to protect against digital fingerprinting. 
Examines how different configurations, such as the \textit{Classic} and \textit{Strict} modes, affect the~visibility and consistency of the browser attributes.

% descriptive statistics

From the analysis of data derived from the Brave browser, unique trends became apparent regarding the usage of resources and the reporting of plugins, observed across a multitude of different configurations.
Upon an extensive evaluation of the Brave dataset, collected across various operating systems and the~browser's distinct \textit{Classic} and \textit{Strict} modes, quantitative variations emerged in how certain attributes were reported. 
Specifically, differences in~the~reported values of hardware concurrency, device memory capacity, and~plug-in availability were identified.

A particularly illustrative example of these defensive strategies can be seen in how the number of CPU cores was reported.
For the CPU core count, the~analysis revealed different randomisation strategies based on the Brave setting. 
Within the \textit{Classic} configuration, the CPU core count was randomised between 2 and the actual value. 
In contrast, the \textit{Strict} configuration consistently randomised the CPU core count between 2 and 8.
A potential explanation for this could be the prevalence of devices equipped with merely 8 cores, which aids in allowing a user to seamlessly integrate into a broader user base while still maintaining distinctiveness through other characteristics.
In every configuration analysed and across multiple environments, the reported median number of CPU cores was consistently 5, assuming that the maximum value reached 8. 
The precise numerical values are available for detailed examination in~Table~\ref{tab:analysis_brave_cpu}, which offers an in-depth look at the data.
\begin{table}[H]
\centering
\caption[Mean CPU core counts]{Mean CPU core counts under classic and strict settings}
\begin{tabular}{|l|c|c|}
    \hline
    \textbf{System} & \textbf{Classic Setting} & \textbf{Stroct Setting} \\
    \hline
    PC A (Ubuntu)        & 2.96 & 4.79 \\
    PC A (Windows 10)    & 3.00 & 5.11 \\
    PC B (Windows 11)    & 4.93 & 5.00 \\
    PC C (MacOS)         & 6.83 & 5.10 \\
    \hline
    \end{tabular}
    \label{tab:analysis_brave_cpu}
\end{table}
Figure \ref{fig:analysis_brave_cpu} illustrates the visual representation of the distribution pertaining to the documented number of CPU cores.
\begin{figure}[h!]
    \centering
    \includegraphics[width=\textwidth]{figures/analysis_brave_cpu.png}
    \caption[Distribution of CPU core count across OS by setting]{Distribution of CPU core count across OS by setting}
    \label{fig:analysis_brave_cpu}
\end{figure}

Regarding device memory, the randomisation displayed variability dependent on the specific configuration settings. 
In~the~\textit{Classic} setting, the reported memory ranged from 0.5 to 8 GB. 
In~the~\textit{Strict} setting, the reported memory ranged from 0.25 to 8 GB. 
The analysis of the mean reported memory showed that for the \textit{Classic} setting, the average was consistently around 3~GB.
For~the~\textit{Strict} setting, the average reported memory was consistently around 2.7~GB.
The exact values are shown in table \ref{tab:analysis_brave_memory}.
\begin{table}[H]
\centering
\caption[Mean reported device memory]{Mean reported device memory (in GB) under classic and strict settings}
\begin{tabular}{|l|c|c|}
    \hline
    \textbf{System} & \textbf{Classic Setting} & \textbf{Strict Setting} \\
    \hline
    PC A (Ubuntu)        & 3.11 & 2.69 \\
    PC A (Windows 10)    & 3.36 & 2.78 \\
    PC B (Windows 11)    & 3.10 & 2.64 \\
    PC C (MacOS)         & 3.04 & 2.69 \\
    \hline
    \end{tabular}
    \label{tab:analysis_brave_memory}
\end{table}
Figure \ref{fig:analysis_brave_memory} presents the visual representation of the documented device memory distribution.
\begin{figure}[h!]
    \centering
    \includegraphics[width=\textwidth]{figures/analysis_brave_memory.png}
    \caption[Distribution of device memory]{Distribution of device memory across OS by setting}
    \label{fig:analysis_brave_memory}
\end{figure}

In terms of screen dimensions, the deviation was obtained by adding a~random value ranging from 0 to 8 to the actual measurements. 
The results indicated consistent stability in the mean deviations in all configurations.
Refer to Table \ref{tab:analysis_resolution_deviation} for precise measurements.
The uniformity in the average deviation indicates a consistent use of this randomisation technique across various devices, operating systems, and Brave settings.

\begin{table}[H]
\centering
\caption{Mean width and height deviation}
\begin{tabular}{|l|c|c|}
\hline
\textbf{System \& Setting} & \textbf{Width Deviation} & \textbf{Height Deviation} \\
\hline
PC A Ubuntu (Strict)       & 4.00 & 3.39 \\
PC A Ubuntu (Classic)      & 4.39 & 3.54 \\
PC A Windows 10 (Strict)   & 3.93 & 3.55 \\
PC A Windows 10 (Classic)  & 4.06 & 3.48 \\
PC B Windows 11 (Strict)   & 4.11 & 3.70 \\
PC B Windows 11 (Classic)  & 4.10 & 3.74 \\
PC C MacOS (Strict)        & 4.18 & 3.62 \\
PC C MacOS (Classic)       & 4.03 & 4.17 \\
\hline
\end{tabular}
\label{tab:analysis_resolution_deviation}
\end{table}

The analysis of plugin reporting confirmed Brave's documentation. 
Under the \textit{Classic} settings, 2 plugins, both from documented substitutions, are recognised. 
The \textit{Strict} mode reveals 4 plugins: 2 via substitution and 2 with randomised identifiers, consistent with Brave's anti-fingerprinting strategies per plugin enumeration described in Chapter \ref{chap:brave}.

% Correlation Analysis

The correlation analysis revealed no significant relationships between attributes that are subject to randomisation by Brave's anti-fingerprinting mechanisms. 
This supports the effectiveness of these defences in breaking statistical dependencies that could otherwise be exploited for user identification.
Specifically, the parameters examined, including CPU core count, device memory, and screen resolution deviation, did not show a meaningful correlation between the tested sessions. 
This analysis was performed exclusively on the~Brave browser, as it was the only one in the study that actively randomised these specific attributes.

To further examine the potential for identifying users within the same environment, additional tests were conducted using multiple user profiles on~a~single machine. 
Despite the thorough evaluation of the data associated with each profile, the investigation did not uncover any significant disparities in~the~observed parameters or~in~the~efficacy of the anti-fingerprinting techniques. \linebreak
The~randomised values remained independent and statistically uncorrelated even when generated under identical hardware and operating system conditions.

The~observed absence of correlation among these attributes, which have the~potential to serve as~identifiers, effectively illustrates the~proficiency \linebreak of~Brave's anti-fingerprinting mechanisms. 
These techniques successfully separate these values, thus lowering their utility in the unique identification of~a~user.
For example, the correlation matrix illustrating PC A with Windows 10 set in~\textit{Strict} mode is presented in~Figure~\ref{fig:analysis_correlation_matrix}.
This matrix provides a visual depiction of the relatively weak linear associations that exist between these attributes within this particular arrangement.

\begin{figure}[h!]
    \centering
    \includegraphics[width=0.7\textwidth]{figures/analysis_brave_correlation_matrix.png}
    \caption{Correlation matrix of Brave attributes for PC A Windows 10}
    \label{fig:analysis_correlation_matrix}
\end{figure}

% NIST

The application of the NIST statistical test suite to Brave browser configurations revealed that most standard tests produced results consistent with random behaviour.
Most basic statistical tests,including the Monobit test, the~Frequency test within a block, the Runs test, and the Cumulative Sums test, produced valid p-values, indicating that randomised data typically passed standard randomness checks.
On the other hand, the Approximate Entropy Test frequently yielded very low p-values. 
Additionally, both the Runs Test and the Test for the Longest Run of Ones in a Block showed low p-values across multiple setups. 
These findings suggest deviations from ideal randomness in~relation to pattern complexity and the sequential distribution of identical bits.

A potential factor influencing small p-values in pattern-sensitive tests is the~data origin. The randomised values originate from a narrow numerical range (0 to 8) and must be converted into binary sequences for compatibility with the NIST test suite.
Any lack of perfect uniformity in the number generation, or bias introduced during binary conversion, may result in systematic patterns.
These can affect statistical tests sensitive to entropy and sequence structure, leading to observed deviations.

Although limitations exist, the findings indicate that despite outputs appearing random in basic assessments, measurable deviations in entropy \linebreak and~structural regularity suggest a~degree of~limited randomisation
Based on~the~application of~the~NIST statistical test suite to different Brave configurations, the~results suggest generally random behaviour, with some important exceptions.

A comprehensive evaluation was restricted since a number of tests, specifically the Binary Matrix Rank, Non-overlapping and Overlapping Template Matching, Maurer's ``Universal Statistica'', Linear Complexity, Serial, and Random Excursions tests, repeatedly indicated ``Error''. 
This suggests that the data set was not large enough to carry out these tests reliably.
The~exact results can be seen in the attached table.

%
% ====================================================================================================================================
%

\subsection{Other Browsers}
\label{chap:findings_others}

In addition to examining Brave's randomised attributes in detail, an evaluation of other browsers was performed. 
This thesis aimed to detect any unusual patterns in their management of randomised versus static attributes relevant to~fingerprint resistance. 
In both Firefox and Apple Safari, the uniqueness of attributes meant to be randomised was specifically evaluated and confirmed, indicating their effective variation across different browsing sessions as planned. 
Additionally, the uniformity of other non-randomised attributes designed to~ensure consistent fingerprinting was examined and verified, showing that these browsers adhere to expected fingerprinting defences without displaying atypical behaviour that could affect privacy.

Unlike Firefox and Apple Safari, the Tor Browser showed unique behaviour \linebreak in~terms of~WebGL and~Canvas fingerprinting. 
The analysis indicated that these fingerprinting methods vary according to the hardware architecture, differentiating x86 from ARM devices.
Notably, these metrics were consistent on~various devices within the~identical architecture.
Determining the~existing goals and intricacies of the Tor Browser's fingerprinting countermeasures is difficult because official documentation lacks timely updates. 
The latest and~most reliable insights into the browser's dynamic behaviour and developments are discovered not in official records but scattered across discussions and public reports, mainly necessitating a review of GitHub Issues concerning the Tor Browser project.

% Decision Tree
To further explore the consistency and distinctiveness of browser characteristics across different platforms, a basic decision tree classifier was trained using the collected dataset. 
This analysis aimed to determine how easily browsers, without any fingerprinting protection, could be distinguished based on their exposed attributes.

The decision tree was used to differentiate between the origin files of~the~data set provided, achieving a classification precision of~60\%. 
It should be noted that the actual accuracy might be marginally higher, considering that the decision tree algorithm used at least one data point from each file. 
Some files consisted of only a single data entry, which led to a calculated accuracy of 0\% for those specific files.

Interestingly, the decision tree achieved this classification without relying on any of the three most stable fingerprintable attributes. 
Instead, it based its initial splits on the operating system, followed by additional browser-specific properties such as screen resolution and navigator object characteristics. 
The~resulting model is illustrated in Figure~\ref{fig:decision_tree_model}.

\begin{figure}[H]
    \centering
    \includegraphics[height=\textheight]{figures/decision_tree.png}
    \caption{Model of used decision tree classifier}
    \label{fig:decision_tree_model}
\end{figure}

%
% ====================================================================================================================================
%

\section{Discussion of Results}
\label{chap:discussion}

This thesis utilised a comprehensive analytical method encompassing descriptive statistics, randomness testing, correlation analysis, and classification modelling to assess browser data traits and anti-fingerprinting mechanisms' effectiveness.

An in-depth examination of the Brave browser's randomised properties identified distinct strategies for its \textit{Classic} and \textit{Strict} settings across diverse environments. 
In the \textit{Classic} mode, \texttt{hardwareConcurrency} varied from~2 to~the~actual core count, while the \textit{Strict} setting used a constant range of~2~to~8.
Although various approaches exist, the median CPU core count consistently hovered around 5, with a maximum of 8, as displayed in Table \ref{tab:analysis_brave_cpu}.
The randomisation of \texttt{navigator.deviceMemory} differed by setting, with classic settings showing memory values from 0.5 to 8 GB, while \textit{Strict} settings showed a~range of 0.25 to 8 GB. 
The average memory reports converged to approximately 3~GB for the \textit{Classic} configuration and 2.7~GB for the \textit{Strict} configuration, as~shown in~Table~\ref{tab:analysis_brave_memory}.
The size of the screen was randomly assigned by introducing a~variable of~0~to~8~units into existing measurements, leading to uniform average deviations in every configuration tested (see~Table~\ref{tab:analysis_resolution_deviation}).
An~evaluation of plugin reporting verified Brave's documented method, identifying 2~substituted plugins in~\textit{Classic} mode and 4 (2 substituted and~2 with~randomised identifiers) in~\textit{Strict} mode, consistent with claimed anti-fingerprinting strategies.

An important component of the Brave analysis was the evaluation of the~connections among these randomised attributes using correlation analysis. \linebreak
The~lack~of substantial linear correlations among randomised parameters like CPU cores, device memory, and resolution confirms their independence, thus validating Brave's anti-fingerprinting strategies in mitigating fingerprinting potential.
Moreover, a comparative analysis of different user profiles within the~same Brave instance revealed minimal variance in reported attributes and~anti-fingerprinting, indicating uniform protection across any profile on~a~single system.

The application of the NIST test suite for evaluating randomness revealed multiple ``Error'' messages, attributed to the limited amount of data.
Although fundamental tests usually succeed, tests such as Approximate Entropy, Runs, and Longest Run often return low p-values, suggesting deviations from true randomness.
This non-randomness is likely due to the data being sourced from a restricted 0-8 range and challenges in completely concealing inherent biases or patterns from the predictable original values in the randomisation step.

Simultaneously with the comprehensive examination of Brave, an extensive evaluation of other web browsers was also performed. 
The evaluation of~Firefox and Apple Safari revealed typical fingerprinting defences. 
All randomised attributes were unique per instance, while unified static attributes were consistent, confirming expected anti-fingerprinting strategies. 
However, the Tor Browser displayed distinctive behaviour, with WebGL and Canvas fingerprints varying by~hardware architecture but consistent across devices of identical architecture.
One of the primary challenges faced while examining the present functioning of the Tor Browser was the absence of contemporary official documentation. 
This deficiency compelled the thesis to depend on reports shared by the user community and dialogues, predominantly accessible through GitHub Issues, in~order to~comprehend the evolving strategies employed by the browser for its fingerprinting countermeasures.

Ultimately, a Decision Tree algorithm was utilised, not with the intent to directly investigate the randomised configurations of Brave, but rather to serve as~a~demonstration mechanism, illustrating how such configurations could be systematically examined.
By training a basic decision tree on data from browsers without robust anti-fingerprinting, it was shown how easily such browsers can be differentiated using commonly accessible attributes such as operating system, screen resolution, and navigator properties, achieving a notable classification precision of 60\% without using the three key values.
This has illustrated the core vulnerability to fingerprinting in the absence of effective countermeasures.

The results of the analysis highlight that unification and randomisation each present unique benefits and encounter particular obstacles when employed as strategies to counteract fingerprinting. 
Their individual characteristics offer diverse solutions, impacting the effectiveness of anti-fingerprinting measures in~different ways. 

When unification is applied extensively and efficiently within a large group of users, it possesses the capacity to considerably obstruct tracking activities by enabling individuals to merge into a significant, indistinguishable group, a principle notably demonstrated by the Tor Browser strategy regarding specific attributes. 
However, the practical application of unification may involve certain trade-offs, especially related to attributes such as screen resolution, where a rigorous unification approach might adversely affect user interaction or disrupt the proper rendering of websites. 

Alternatively, the method of randomisation addresses the issue of precise fingerprint matching by introducing variation into the attributes of a browser. 
This method proves to be effective in differentiating individual occurrences by~making them unique. 
A~vital distinction compared to the approach of~unification is that randomisation allows for the theoretical potential to reconstruct an approximate form of the original dataset or to discern underlying patterns from a series of values subjected to randomisation. 
This potential for~data reconstruction or pattern identification presents a challenge that does not arise when attributes are merely standardised through unification.
A~crucial conclusion drawn from the analysis highlights the need for thorough randomisation.
In order to maximise its effectiveness, randomisation should encompass the~broadest possible range of identifying features. 
Failing to adequately randomise even a handful of persistent attributes, such as key fingerprinting elements like Canvas, WebGL, or Audio, can drastically curtail the~potential user group size. 
This reduces the privacy enhancements achieved by randomising other features and facilitates user identification through the~unaffected stable components. Consequently, the selection and implementation of randomisation strategies necessitate carefully balancing intricate trade-offs among privacy enhancement, user-friendliness, and the level of complexity needed to~prevent sophisticated tracking techniques.

Interestingly, the browsers analysed mostly use either randomisation \linebreak (as~seen in~Brave for~several attributes) or~unification (as~observed in~Tor/Firefox for~specific values) as~their main tactics, yet none seem to~integrate both methods systematically across various attribute types by default. 
A hybrid strategy, potentially randomising highly variable or~complex fingerprinting values (e.g., Canvas, WebGL, Audio) while unifying simpler or~less variable attributes (e.g., \texttt{hardwareConcurrency}, \texttt{deviceMemory}) could offer a~balanced approach. 
This might leverage the strength of randomisation against complex identifiers while utilising unification to create large cohorts for simpler ones, potentially optimising both privacy and usability compared to relying solely on~a~single strategy for all attributes.
This approach is being used as the aggressive configuration in~both Firefox and~Apple Safari but~not by~default in~any tested browser. 
However, the current implementation of~any browser designed to~prevent fingerprinting automatically categorises users into a particular subset of~the~broader user base, thereby diminishing the total number of~possible user matches due to the distinctive nature of such browser attributes.

% Brave \\
% - znovu zduraznit, rychlou evoluci oproti ostatni prohlizecum
% 
% TOR \\
% - napsat ze jak Audio tak Canvas+WebGL API vykazuje ruzne vysledky pro ARM a x86, coz jsem nikde v dokumentaci nenasel, \\
% - zastaralá dokumentace oproti Githubu \\
% 
% Diskuse o tom, proc je mozna lepsi unifikace \\
% uvest obecne dopady toho, ze uzivatel pouziva nejakou vetsi ochranu -> rovnou ho to dava do urcite skupiny uzivatelu