FP-Fed: Privacy-Preserving Federated Detection of Browser Fingerprinting

FP-Fed: Privacy-Preserving Federated Detection of Browser Fingerprinting

Speakers: Meenatchi Sundaram Muthu Selva Annamalai

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=8I6uQO4_8aw

Overview

This article delves into FP-Fed, a groundbreaking system designed for the Privacy-Preserving Federated Detection of Browser Fingerprinting. Presented at the NDSS Symposium by Meenatchi Sundaram Muthu Selva Annamalai, this research addresses a critical and evolving threat to user privacy in the wake of the impending deprecation of third-party cookies. As major browsers increasingly restrict traditional tracking mechanisms, adversaries are pivoting to more insidious methods like browser fingerprinting, which can create persistent, unique identifiers for users across the web, often without their knowledge or consent.

FP-Fed introduces a novel, distributed approach that leverages Differentially Private Federated Learning (DP-FL). This allows users to collaboratively train robust on-device models for fingerprinting detection based on their real browsing patterns, crucially, without ever sharing their sensitive raw browsing data with a central server. The system demonstrates the feasibility and effectiveness of DP-FL for security tasks, achieving high detection performance with minimal false positives while providing strong, formal privacy guarantees. Its ability to operate efficiently on-device using a small, runtime-based feature set makes it a practical solution for real-world deployment.

The significance of FP-Fed lies in its direct response to the limitations of existing fingerprinting detection methods. Prior machine learning approaches have largely relied on centralized web crawls, which struggle to capture the full spectrum of real-world user interactions and are often detected by anti-bot measures. By enabling privacy-preserving collaboration among real users, FP-Fed offers a more comprehensive and robust defense against the escalating threat of browser fingerprinting, paving the way for a more private web ecosystem.

Background

▶ Watch: Introduction to browser fingerprinting and privacy motivation (0:00)

The landscape of web privacy is undergoing a profound transformation. Traditional third-party cookies, long the backbone of cross-site user tracking, are rapidly being phased out. Browsers like Safari, Firefox, and Brave already implement significant restrictions, and Google Chrome, the dominant browser, is slated to deprecate them entirely by 2024. While this move is a positive step for user privacy, it has catalyzed a shift among trackers towards more sophisticated and often less transparent alternative methods, predominantly browser fingerprinting.

Browser fingerprinting involves the collection of various client-side information via JavaScript programs—details such as screen resolution, installed fonts, device hardware specifics, browser version, and operating system. This high-entropy data is then combined and hashed to generate a unique, stable identifier for a user's browser. This identifier can persist across different websites and over extended periods, often capable of tracking users even in incognito or private browsing modes for months. While fingerprinting can serve legitimate purposes like web authentication or fraud detection, its widespread use for pervasive, non-consensual tracking poses a significant threat to user privacy, often exceeding the intrusiveness and transparency issues associated with cookies. The prevalence of fingerprinting has been on a steep upward trajectory, with domains employing it in the top 1 million websites quadrupling between 2016 and 2019, a trend expected to continue.

Early countermeasures against fingerprinting relied on manual blocklists and basic heuristics. More recently, machine learning has emerged as a promising avenue for building high-precision and high-recall detectors. However, these existing machine learning approaches suffer from critical limitations. They predominantly depend on centralized web crawls to gather scripts, which are then manually or heuristically labeled to train detection models. Centralized crawlers face inherent challenges: they struggle to mimic human-like browsing behavior, are often identified and blocked by bot detectors, and cannot easily navigate common web obstacles like logins, paywalls, or CAPTCHAs. Crucially, the behavior of JavaScript scripts can differ significantly in a controlled crawling environment compared to real-world user interactions, due to variations in device types, operating systems, and other attributes. A small-scale study mentioned in the talk, focusing on the top 300 domains, revealed that crawls involving real users—who perform logins and solve CAPTCHAs—can capture up to three times more fingerprinting scripts than automated crawlers. This discrepancy highlights that training data derived from centralized crawls may miss a substantial number of active fingerprinting instances on top-ranked websites.

Collecting real-world browsing observations directly from users, while providing richer data, introduces significant privacy concerns, as raw browsing data can reveal highly sensitive information. Conversely, training models exclusively on individual user devices (local-only training) offers optimal privacy but typically yields insufficient data for robust model accuracy.

To overcome these challenges, FP-Fed was developed as the first distributed system for browser fingerprinting detection. It enables collaborative, on-device model training using real user browsing patterns, without sharing sensitive raw data. This is achieved through Differentially Private Federated Learning (DP-FL).

Federated Learning (FL) is a decentralized machine learning paradigm where multiple participants collaboratively train a global model. Instead of centralizing raw data, each participant trains a local model on their private dataset and only shares model updates (e.g., gradients or parameter differences) with a central server. The server then aggregates these updates to refine the global model, which is subsequently propagated back to the participants for further local refinement. FP-Fed specifically utilizes the Federated Averaging (FedAvg) algorithm, where in each round, a subset of participants downloads the current global model, computes local updates, and sends these updated parameters back to the server for aggregation.

Differential Privacy (DP) is a rigorous mathematical framework for quantifying and guaranteeing privacy loss in data analysis. It achieves this by introducing carefully calibrated statistical noise, making it difficult for an adversary to infer whether any individual's data was included in the dataset. Formally, a randomized mechanism M is (ε, δ)-differentially private if, for any two neighboring datasets d and d' (differing by a single individual's record), the probability of M outputting a result in set S for d is bounded by e^ε times the probability for d', plus a small failure probability δ. Here, ε (epsilon), the privacy budget, quantifies the privacy loss (lower ε values indicate stronger privacy), and δ (delta) is an asymptotically small failure probability, representing the chance of the privacy guarantee failing.

In the context of FL, DP guarantees can be applied at either the record-level (protecting individual data points) or the participant-level (protecting all data contributed by a single user). FP-Fed employs participant-level DP, which is crucial because each user contributes their entire local dataset to the training process. DP can be integrated into FL in different ways based on trust assumptions. Local DP (LDP) involves participants adding noise to their updates before sending them to the server, offering strong privacy but often severely impacting model utility. FP-Fed uses Central DP (CDP), where participants send unperturbed updates to a trusted server, which then applies a differentially private aggregation algorithm. CDP generally offers better utility than LDP because noise is added only once at the aggregation step. While CDP assumes trust in the server for the aggregation process, this is a significantly weaker assumption than trusting the server with raw training data. This approach is similar to real-world deployments like Google's next-word prediction. The researchers acknowledge that Distributed DP, which combines CDP with secure aggregation protocols, offers even stronger guarantees by removing the trust assumption on the central server, but it is typically computationally complex and impractical for large-scale production systems.

Defining browser fingerprinting is challenging due to the difficulty in discerning intent. FP-Fed adopts a conservative definition based on well-known heuristics and signatures from FP-Inspector 39, a prior work in the field. This approach focuses on four prevalent forms of fingerprinting: Canvas, Canvas Font, WebRTC, and AudioContext. By adhering to a conservative definition, FP-Fed aims to minimize false positives, a critical requirement for real-world deployment, even if it means potentially missing some newer or more obscure fingerprinting techniques.

To collect the necessary fingerprinting scripts and execution data, the researchers instrumented web browsers to capture execution traces, specifically the arguments and return values of called APIs during simulated web crawls. Unlike prior work that often used OpenWPM with Firefox, FP-Fed utilizes Puppeteer with Google Chrome (specifically, Chrome M114 for the prototype). Chrome was chosen for its broader API surface and more robust native API tracing capabilities, which are less susceptible to evasion techniques. The system focuses exclusively on dynamic features, such as API call counts and the values passed to/returned from APIs, as static features (e.g., from code analysis) are less robust to obfuscation and more resource-intensive to extract on-device.

Key Findings

▶ Watch: Foundational concepts: Federated Learning and Differential Privacy (4:00)

FP-Fed's extensive evaluation yielded several significant findings that underscore its potential as a robust, privacy-preserving solution for browser fingerprinting detection:

• High Accuracy with Strong Privacy: The system demonstrated that Differentially Private Federated Learning (DP-FL) is feasible and effective for security tasks. FP-Fed achieved a reasonably high Area Under the Precision-Recall Curve (AUPRC) of 0.8 even at strong privacy levels (ε=1.0) with a simulated 1 million participants. This significantly outperforms traditional local-only training approaches, validating the power of collaborative, privacy-preserving models.
• Efficiency on Resource-Constrained Devices: FP-Fed operates efficiently on-device, relying solely on runtime signals extracted from execution traces. Its lightweight nature, achieved through a simple logistic regression model and a small feature set, makes it practical for deployment on end-user devices like Android smartphones, without requiring resource-intensive operations.
• Discovery of a Minimal, Informative Feature Set: A crucial contribution is the identification of a highly effective and minimal feature set. Through feature importance analysis, the researchers distilled the total 1,514 features down to an Extended High Entropy set comprising only 149 features (17 API call counts and 23 custom features). This significantly reduced feature set achieved performance comparable to the full feature set at high privacy (ε=1.0), despite using only 9.8% of the total features, making on-device deployment highly practical. The BatteryManager.level API call count was noted as particularly informative.
• Superiority of Real User Data: The study empirically confirmed that real-world user interactions, including navigating logins and solving CAPTCHAs, capture significantly more fingerprinting scripts than automated crawlers. A manual crawl mimicking real user behavior captured 3.07 times more fingerprinting scripts than automated methods, highlighting FP-Fed's advantage in utilizing authentic browsing data.
• Benefits of Differentially Private Feature Normalization: FP-Fed is the first work to implement differentially private feature normalization in a federated setting. This pre-processing step was shown to generally improve model performance, especially with richer custom features. For instance, the performance of the 'JShelter' feature set improved by up to 20.8% at high privacy (ε=1.0) with this normalization.
• Resilience to Non-IID Data Distributions: The system demonstrated reasonable resistance to Non-IID (non-independently and identically distributed) data, where participants have limited knowledge or access to only specific types of fingerprinting scripts. Model performance degradation was only pronounced when over 80% of participants exhibited limited knowledge, a scenario deemed unlikely in practical deployments.
• Practical Deployment Potential: By focusing on natively traced Chrome APIs, FP-Fed can be deployed directly within the browser (e.g., as a Chrome extension), which increases participant coverage and simplifies integration into existing browser ecosystems. The prototype Chrome extension demonstrated a negligible mean performance drop of 0.0018 (maximum 0.078) using Lighthouse metrics, confirming its efficiency.

Technical Deep Dive

▶ Watch: FP-Fed's specific Differential Privacy application and trust model (4:48)

The FP-Fed system is architected as a distributed platform for detecting browser fingerprinting, leveraging the power of Differentially Private Federated Learning (DP-FL). Its design meticulously balances detection accuracy, privacy guarantees, and operational efficiency on end-user devices.

The system operates through a well-defined lifecycle involving participants and a central server:

1. Participants: End-users run an instrumented Chrome M114 browser (or later) on an FL-supporting platform, such as Android. As users visit websites, the browser actively collects execution traces for a predefined set of high-entropy, monitored APIs.
2. Pre-processing Phase: For each loaded script, the instrumented browser extracts a set of features from the collected execution traces. Concurrently, it generates initial seed ground truth labels (categorizing scripts as either fingerprinting or non-fingerprinting) using high-precision heuristics derived from FP-Inspector 39. Participants then engage in a differentially private pre-processing phase (Algorithm 2 DP-FedNorm), where they compute local summary statistics (mean and variance) for their features and share these with the central server. The server aggregates these local statistics, adds Differential Privacy (DP) noise to them, and then shares the noisy global statistics back with the participants. Each browser then uses these DP-normalized statistics to scale its local features.
3. Training Phase: In each round of the federated learning process, the server selects a subset of active participants. It sends the current global model parameters from the previous round to these selected participants. Each participant then instantiates a local model with these parameters and updates it using their locally collected and pre-processed data. Once local training is complete, participants send their updated model parameters back to the server. The server aggregates these updates, crucially adding DP noise at this aggregation step (Central DP), and then generates the new global model. This iterative process continues until the model converges to a stable state.
4. Detection Phase: Finally, the converged global model parameters are propagated to all participants. These parameters are used to instantiate an on-device detection model, enabling real-time browser fingerprinting detection based on the collaboratively learned intelligence.

Key Components and Design Choices:

• Participants: These are the distributed clients, typically end-user devices, that collaboratively contribute to building the detection model. They maintain their raw browsing data locally, ensuring privacy.
• Server: The central server orchestrates the federated learning process. Its responsibilities include selecting participants, distributing global model parameters, aggregating local model updates, and applying DP noise during aggregation. The server is assumed to be trusted with model updates but not with raw user data.
• Model: A simple logistic regression model was chosen. This decision was driven by its fast convergence properties and lightweight nature, making it highly suitable for resource-constrained devices. Adapting more complex models like deep neural networks or decision trees to DP-FL settings often introduces significant computational and privacy-budget complexities that are prohibitive for on-device deployment.

Differentially Private Pre-Processing (Algorithm 2 DP-FedNorm):

A critical step before training any machine learning model is feature normalization (e.g., scaling features to have a mean of 0 and a variance of 1). In a federated setting, calculating global mean and variance directly would violate privacy. FP-Fed addresses this with Algorithm 2, which allows participants to calculate their local means and variances. These local statistics are then aggregated by the server, with carefully calibrated DP noise added to ensure that individual participants' contributions to these statistics remain private. This is the first work to apply DP to feature normalization in FL for this domain, and it significantly contributes to the overall model performance, particularly for custom features.

Ground Truth Labeling:

A significant challenge in browser fingerprinting detection is the absence of definitively labeled datasets, as intent is hard to ascertain. FP-Fed overcomes this by generating seed ground truth labels using a set of high-precision heuristics derived from FP-Inspector 39. These heuristics define specific conditions for identifying four prevalent fingerprinting techniques: Canvas, Canvas Font, WebRTC, and AudioContext fingerprinting. For example, a script is labeled as Canvas fingerprinting if it writes text to a Canvas element, applies styling, calls toDataURL(), and notably, does not call methods like save(), restore(), or addEventListener(), which are often associated with legitimate Canvas usage. This conservative approach is vital for minimizing false positives, which would degrade user trust and the practical utility of the detector.

Data Collection and Distribution for Evaluation:

To evaluate FP-Fed, the researchers simulated a distributed environment. A single crawl of 20,000 popular websites was performed, comprising the top 10,000 domains from the Chrome User Experience Report (CrUX) and 10,000 random domains from the 10k-100k CrUX ranking. Of these, 18,300 websites were successfully visited, yielding 181,633 unique JavaScript scripts. The ground-truth heuristics identified 752 (0.41%) of these scripts as fingerprinting. The dataset was split into 80% for training and 20% for testing. To simulate realistic distributed browsing patterns, the training data was distributed among simulated participants based on the Tranco ranking, which follows Zipf's law, accurately reflecting real-world website visit frequencies where a few sites are visited frequently and many are visited rarely. Each participant was configured to sample a fixed set of URLs and store the scripts loaded from them.

Feature Extraction and Sets:

FP-Fed extracts a total of 1,514 features, categorized as follows:

1. API Call Counts: The number of times 684 potential fingerprinting JavaScript APIs are called. This includes 75 additional Chrome-specific APIs and 184 High Entropy APIs that are natively traced by Chrome, making them more robust against evasion techniques.
2. Custom Features: 830 hand-crafted features derived from FP-Inspector 39. These are extracted from the arguments and return values of API calls and often represent specific signatures found in known fingerprinting scripts. The researchers acknowledge that processing raw execution traces for these features could potentially leak sensitive information, underscoring the necessity of DP.

For experimental evaluation, several distinct feature sets were defined:

• All: The complete set of 1,514 features.
• FP Inspector: 1,330 features (500 API call counts + 830 custom features), mirroring the original FP-Inspector work.
• JShelter: 588 features (96 API call counts + 492 custom features), based on the JShelter browser extension.
• High Entropy: 109 features (only API call counts flagged as high entropy by Chromium, with no custom features).
• Extended High Entropy: A refined, minimal set derived from analysis, which became a key finding.

The primary metric for model performance was the Area Under the Precision-Recall Curve (AUPRC). AUPRC is particularly robust for highly imbalanced datasets, such as those found in fingerprinting detection where fingerprinting scripts are rare, and it provides a comprehensive summary of performance across various classification thresholds. All experiments were averaged over five runs to ensure statistical reliability.

Evaluation and Results (Detailed):

• A. Non-DP Federated Training (without privacy noise):
• Federated Learning significantly improved model accuracy compared to local-only training (simulated with W=1 participant). With the 'All' feature set, AUPRC improved by 25.5% with 1,000 participants.
• Optimal performance (AUPRC of 0.98 for 'All' features) was achieved with approximately 100 participants, demonstrating FL's efficiency.
• The 'All', 'FP Inspector', and 'JShelter' feature sets performed close to the centralized baseline (0.97 AUPRC). However, the 'High Entropy' set performed poorly, not exceeding 0.8 AUPRC, indicating that raw Chromium high-entropy API calls alone are insufficient.

• B. Impact of the Privacy Parameter (ε):
• FP-Fed was evaluated with differentially private noise using ε values of 1.0 (strong privacy), 5.0 (moderate), and 10.0 (low privacy), alongside a Non-DP baseline.
• With a small number of participants (W=104), AUPRC was below 0.7 at high privacy (ε=1.0).
• As the number of participants increased to W=105, the model performed better, achieving AUPRC above 0.8 even at high privacy (ε=1.0).
• With W=106, the Non-DP performance could be recovered at low privacy (ε=10.0). This confirmed that a larger pool of participants is essential for maintaining good model performance in DP-FL, as it allows for less noise to be added per participant while preserving privacy.

• C. Impact of Feature Sets:
• 'All', 'FP Inspector', and 'JShelter' performed well even at high privacy. Notably, 'JShelter', despite using only 40% of the 'All' features, showed comparable performance, likely due to the effectiveness of the DP feature normalization step. 'High Entropy' continued to perform poorly (AUPRC 0.6).
• To identify an optimal lightweight feature set, features were sorted by importance. Adding only API call counts to 'High Entropy' showed marginal improvement, remaining below 0.8 AUPRC, indicating API call counts alone are insufficient.
• However, adding custom features significantly improved performance. The researchers found that 40 additional features (17 API call counts and 23 custom features) provided an optimal trade-off, with performance plateauing after 20 features for ε=5.0 and after 40 for ε=1.0. The BatteryManager.level API call count was highlighted as particularly informative.
• The Extended High Entropy set was defined as the union of 'High Entropy' and these 40 additional features, totaling just 149 features. This set performed significantly better than 'High Entropy' and comparably to 'All' at high privacy (ε=1.0), despite using only 9.8% of the total features. This was a key finding, demonstrating that a minimal, informative feature set can achieve good performance with DP, making it highly practical for real-world deployment.

• D. Impact of Feature Normalization and Non-IID Distributions:
• Feature Normalization (Figure 9): FP-Fed's pioneering use of differentially private feature normalization in FL proved advantageous. This step generally improved model performance, especially with richer custom features. For instance, at high privacy (ε=1.0), 'JShelter' performance improved by up to 20.8%. This suggests that allocating privacy budgets for pre-processing steps like normalization is beneficial, even if it introduces some noise into the training process.
• Non-IID Distributions (Figure 10): The system was stress-tested by simulating "Participants with Limited Knowledge," who only encountered one type of fingerprinting script. While model performance did drop with increasing levels of non-IIDness (as confirmed by the Non-IIDness score in Table II), this drop was only pronounced when over 80% of participants had limited knowledge, a scenario deemed unlikely in practical, large-scale deployments. This indicates FP-Fed's reasonable resilience to non-IID data distributions.

Demo / Proof of Concept

▶ Watch: FP-Fed's focus on dynamic features for robust detection (7:25)

To assess the real-world deployability and practical overhead of FP-Fed, a prototype was developed as a Chrome extension. This prototype served as a tangible proof of concept, demonstrating the system's capabilities and efficiency on an end-user device.

The prototype's evaluation focused on two key aspects:

• Effectiveness in Capturing Real-World Data: The researchers conducted a manual crawl using the prototype extension, mimicking genuine user interactions such as logging into websites and solving CAPTCHAs. This allowed for a direct comparison with traditional automated crawling methods. The results were compelling: this manual, user-driven crawl captured 3.07 times more fingerprinting scripts than automated crawlers (as detailed in Table III of the original paper). This empirical finding strongly validates FP-Fed's core advantage: its ability to leverage actual user browsing behavior to collect a more comprehensive and representative dataset of fingerprinting activities, which centralized, automated systems often miss.
• Computational Overhead: To quantify the impact of the FP-Fed prototype on browser performance, Lighthouse performance metrics were used. The evaluation revealed a remarkably negligible mean performance drop of 0.0018, with a maximum observed drop of only 0.078, when the extension was enabled. This minimal overhead confirms FP-Fed's efficiency and suitability for on-device deployment without significantly degrading the user's browsing experience. This is crucial for mass adoption, as users are unlikely to tolerate performance penalties for privacy-enhancing tools.

The successful development and evaluation of this Chrome extension prototype provide strong evidence for the practical viability of FP-Fed. It demonstrates that a privacy-preserving, federated approach to fingerprinting detection can be integrated directly into a widely used browser, effectively capture real-world threats, and operate with minimal impact on performance.

Defensive Implications

▶ Watch: Beginning of FP-Fed's overall system design explanation (8:00)

The FP-Fed research provides critical insights and actionable intelligence for defenders and browser developers striving to protect user privacy against browser fingerprinting:

• Embrace DP-FL for Real-World Threat Detection: FP-Fed clearly demonstrates the feasibility and effectiveness of Differentially Private Federated Learning (DP-FL) for a challenging security task like browser fingerprinting detection. Defenders should explore integrating similar DP-FL systems into their security strategies, particularly for threats that require real-world, dynamic data for detection but where raw data sharing is privacy-prohibitive.
• Browser Integration is Key: The ability to deploy FP-Fed as a Chrome extension with negligible performance overhead suggests that browser vendors could directly integrate such privacy-preserving detection mechanisms. Embedding these systems natively would significantly increase participant coverage and provide a robust, always-on defense against evolving fingerprinting techniques.
• Focus on Dynamic Analysis with Minimal Features: The research highlights the superiority of dynamic features (runtime API calls, arguments, return values) over static analysis, which is prone to obfuscation. Furthermore, the identified Extended High Entropy feature set (149 features) proves that highly effective detection can be achieved with a minimal, carefully selected set of features. This is crucial for optimizing performance and resource consumption on end-user devices. Defenders should prioritize collecting and analyzing these specific runtime signals.
• Acknowledge Limitations of Centralized Crawls: The finding that real user interactions capture 3.07 times more fingerprinting scripts than automated crawlers is a stark reminder of the blind spots in traditional, centralized threat intelligence. Defenders relying solely on automated crawls for threat detection should recognize these limitations and seek ways to incorporate real-world user data, ideally through privacy-preserving mechanisms like FP-Fed.
• Proactive API Evaluation: The call for a common framework to evaluate new web APIs for their fingerprinting potential before deployment is a crucial defensive implication. This proactive approach would allow browser developers to balance new web capabilities with privacy concerns, preventing the introduction of new high-entropy sources that could be abused for tracking.
• Understanding DP Trade-offs: While DP offers strong privacy guarantees, it often comes with a trade-off in model utility, especially at very strong privacy levels (low ε). Defenders must carefully consider the balance between privacy budget (ε) and desired detection performance, recognizing that a larger pool of participants can help mitigate the performance impact of DP noise.
• Consider Trust Assumptions: FP-Fed's use of Central DP assumes trust in the aggregation server. For scenarios demanding even stronger guarantees, future defensive strategies could explore more complex Distributed DP approaches combined with secure aggregation, although the computational overhead must be carefully weighed.

In essence, FP-Fed offers a blueprint for building more resilient, privacy-aware security systems for the web. It encourages a shift towards collaborative, on-device intelligence that respects user privacy while effectively countering sophisticated tracking methods.

Key Takeaways

• Browser fingerprinting is a rapidly escalating privacy threat, poised to become the dominant tracking method as third-party cookies are deprecated, making privacy-preserving detection critical.
• FP-Fed offers a novel, distributed solution for browser fingerprinting detection by leveraging Differentially Private Federated Learning (DP-FL), enabling collaborative model training among real users without compromising their sensitive browsing data.
• DP-FL is a feasible and effective paradigm for security tasks, achieving high detection accuracy (AUPRC > 0.8) even with strong privacy guarantees (ε=1.0) and operating efficiently on resource-constrained devices using only runtime signals.
• A minimal, carefully curated feature set (Extended High Entropy, 149 features) provides high performance with significantly reduced overhead, making on-device deployment practical for end-user devices.
• Real user interactions are paramount for comprehensive fingerprinting detection, as they capture significantly more (3.07 times) fingerprinting scripts than traditional automated web crawls, highlighting the limitations of centralized approaches.
• Differentially private feature normalization is a beneficial pre-processing step in FL, improving model performance, especially for custom features, even with the associated privacy budget allocation.

About the Speaker(s)

Meenatchi Sundaram Muthu Selva Annamalai is a researcher focused on developing advanced, privacy-preserving solutions for critical web security challenges. Their work, as presented in the FP-Fed talk, specifically highlights expertise in applying Differentially Private Federated Learning to address the growing threat of browser fingerprinting. This research demonstrates a deep understanding of both web privacy mechanisms and the practical implementation of machine learning techniques in distributed, privacy-sensitive environments.