Federated Learning with Differential Privacy for Sensitive Data

The problem: useful models need data that cannot be centralised

Hospitals, clinics and diagnostic labs each hold data that could train a better model together than alone: chest X-rays, diabetes risk records, lab results. They usually cannot pool it, because of patient privacy, regulation and trust. Federated learning trains a shared model without moving the data: each site trains locally and sends only model updates.

On its own this is not private. Model updates leak information about the data that produced them, and attacks can tell whether a specific record was in a site's training set. Differential privacy adds calibrated noise to bound that leakage, at a cost in accuracy. How much accuracy, for what guarantee, on realistic data, is the question this project answers.

What already exists and the gap

• Flower is an open source federated learning framework with built-in strategies for central and local differential privacy, still marked as preview in its documentation.
• Opacus, from Meta, adds differentially private SGD to PyTorch training with privacy accounting.
• TensorFlow Federated is Google's framework for federated computation research; Google has written on its research blog about deploying federated learning with differential privacy for Gboard.

The tools exist. What is missing for most practitioners, and especially for small healthcare teams, is clear evidence on a realistic setup: skewed data across sites, a real attack, and an honest curve of accuracy against privacy budget. The gap is a careful, reproducible study plus a small reference implementation someone else can rerun.

What you build

• Site (client): holds its own partition of a public medical or tabular dataset, trains locally, clips and noises its update.
• Coordinator (server): aggregates updates, tracks the privacy budget and evaluates the global model.
• Attacker: runs a membership inference attack against the global model.
• Analyst: runs the experiment grid and produces the report.

Use a public dataset (for example from Kaggle) and partition it so each simulated site has a different mix of labels or patient groups.

The technically interesting part

Getting the privacy accounting right. Decide whether you protect individual records (example-level DP) or whole sites (client-level DP), implement clipping and noise correctly, and track the cumulative budget across rounds. A wrong accountant produces a meaningless epsilon.

Non-identically distributed data. If every client holds a random sample, federated learning works easily and the results mean nothing. Realistic skew makes convergence harder and noise more damaging; this is where the interesting findings are.

The attack. A membership inference attack turns an abstract guarantee into a demonstrated one. Show its success rate against the undefended model and how it drops as the privacy budget tightens. That chart and the trade-off curve are the headline results.

How to evaluate it

• Utility: accuracy or AUC across at least five privacy budgets, against centralised and local-only baselines, averaged over several seeds with error bars.
• Privacy: membership inference advantage at each budget.
• Heterogeneity: repeat the grid with mild and strong skew.
• Cost: training time and bytes communicated per round.

Suggested plan

1. Weeks 1 to 4: read the core papers, choose dataset and model, build a centralised baseline.
2. Weeks 5 to 9: federated training with Flower, non-identical partitions.
3. Weeks 10 to 14: differential privacy, accounting, first experiment grid.
4. Weeks 15 to 19: membership inference attack and evaluation.
5. Weeks 20 to 24: stretch goal or second dataset, repeat experiments.
6. Weeks 25 to 28: report, reproducibility package, presentation.

Path to a product

This is research-shaped, so the realistic path is not a SaaS. Publish the code and results as an open source reference that others can rerun, and write it up as a workshop paper or detailed blog post. It is a strong portfolio centrepiece for machine learning and privacy engineering roles, and it can lead to consulting or a pilot with a hospital group or health startup that wants to train across sites.

Scope warning

Simulated clients on one machine is correct. Do not attempt real device or real hospital deployment, and do not use real patient data. Do not invent your own privacy mechanism; use established ones and focus on measurement.

Learn what you need on Sefism

• Machine learning roadmap : the training, evaluation and PyTorch basics you need first.
• Machine learning cheat sheet : metrics and experiment hygiene for the results grid.
• Kaggle Datasets : public medical and tabular datasets to partition across clients.
• Google Colab : free GPUs for running the experiment grid.
• Google Research Blog : posts on federated learning and differential privacy in production.

Get help with this idea

The risk here is reporting numbers that do not mean anything because the data split or privacy accounting is wrong. Tauseef can help you pick a dataset, plan the experiments, and structure the report so the trade-off curve is credible. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session