Federate Phishing Detection: Training a URL Classifier without Sharing Browsing Data

At Mozilla.ai, we believe useful machine intelligence shouldn’t require centralizing sensitive user data. Federated learning offers a practical path toward collective intelligence without surveillance-style data aggregation. That’s why we’re excited to be a launch partner of Flower Hub, helping move federated learning from research into real-world applications.

The Problem

APWG recorded over 3.8 million phishing attacks in 2025, averaging over 10,000 new phishing URLs per day. To catch the latest threats, classifier models need to see what URLs people are actually clicking on. Centrally collecting those clicks means asking users to hand over their entire digital paper trail. Federated learning offers a different approach: train the model where the data already lives, and share only the learned weights.

How fed-phish-guard works

fed-phish-guard is a Flower app that trains a phishing URL classifier across distributed clients without any raw URL data leaving their respective devices. It uses byte-level encoding—treating each URL as a sequence of raw bytes rather than subword tokens—so the model catches the character-level tricks attackers rely on, like swapping l for 1 in paypa1.com or hiding the real domain in a subdomain. These byte sequences feed into a 1D CNN that extracts local patterns regardless of where they appear in the string.

For training, we use Federated Averaging: in each round, a subset of clients trains locally on their private data for one epoch, then sends only the updated model weights (not raw data) to the server. The server averages these weight updates (weighted by the number of training examples each client contributed) to produce a new global model, which is then broadcast back to clients for the next round. 

For simulation, the dataset is split using IID (Independent and Identically Distributed) partitioning, where each client receives a random, balanced subset of URLs across both classes. This represents an idealized scenario, as real-world deployments may exhibit non-IID patterns (e.g., users in different regions encountering different phishing campaigns). Flower's simulation mode runs all clients as Ray actors on a single machine, enabling rapid experimentation without physical infrastructure, while deployment mode distributes clients across actual devices or servers for production use.

Results 

With default settings (10 clients, 3 rounds, IID partitioning, ~83K URLs per client):

Note: federated results will vary by number of rounds, clients, and data distribution. As a comparison, our reference centralized baseline reaches +3.2% accuracy after 20 epochs—but requires pooling all browsing data.

Try it yourself

Shell
pip install flwr
flwr new @mozilla-ai/fed-phish-guard
cd fed-phish-guard && pip install -e .
flwr run .

This project is public on Flower Hub, where you can find our source code as well as details about model architecture and dataset. Feedback, new ideas and contributions are more than welcome!