In 2017, Google published a paper titled “Communication-Efficient Learning of Deep Networks from Decentralized Data.” The paper introduced Federated Averaging (FedAvg), an algorithm that trains a neural network across thousands of devices – each holding its own private dataset – without ever transmitting that data to a central server. The model travels to the data, not the data to the model. Within three years, Google had deployed federated learning at scale across three billion Android devices, using it to train the next-word prediction model in Gboard, the query suggestion model in Google Search, and the “Hey Google” wake word detection in Google Assistant.
By 2025, federated learning had moved from a Google-internal research project to critical infrastructure. Apple uses it for Siri voice model personalization, QuickType predictions, and the computational photography pipeline in its Neural Engine. Hospitals in the HealthChain consortium train diagnostic models across 12 European institutions without sharing patient records. Financial institutions use it for fraud detection models trained across banks that are legally prohibited from sharing transaction data. The global federated learning market was valued at $136 million in 2023 and projected to reach $465 million by 2028, according to MarketsandMarkets.
The promise is structural: train models on data that cannot be centralized without sacrificing model quality. The reality is nuanced. Federated learning reduces data exposure but does not eliminate it. Understanding the gap between the promise and the guarantee is essential for anyone building privacy-enhancing technologies.
The Federated Learning Protocol
The standard federated learning protocol (FedAvg and its descendants) operates in iterative rounds:
Round Structure
1. Server broadcasts the global model. The central server holds the current version of the model parameters (weights and biases). At the start of each round, it sends the full model to a selected subset of participating devices (clients).
2. Clients train locally. Each client trains the model on its local data for a fixed number of epochs (typically 1-5). The training uses standard stochastic gradient descent (SGD) or its variants (Adam, AdaGrad). The result is an updated set of model parameters that reflect the patterns in the client’s local data.
3. Clients send model updates. Each client computes the difference between the updated model and the original model (the “gradient” or “model update”) and sends this difference back to the server. The raw data never leaves the device. Only the model update – a set of numerical parameter changes – is transmitted.
4. Server aggregates updates. The server combines the updates from all participating clients, typically by weighted averaging (each client’s update is weighted by the number of training samples it contributed). The aggregated update is applied to the global model, producing a new version.
5. Repeat. Steps 1-4 repeat for hundreds or thousands of rounds until the model converges to acceptable accuracy.
What Is and Is Not Transmitted
The critical distinction: the server never sees the raw data (text typed, images captured, medical records, financial transactions). It sees model updates – vectors of floating-point numbers representing how the model parameters should change. A model update for a neural network with 100 million parameters is a vector of 100 million numbers, which encodes aggregate statistical patterns from the training data, not individual data points.
However, “never sees the raw data” does not mean “learns nothing about the raw data.” Model updates can leak information about the training data, a vulnerability that requires additional defense mechanisms.
Cross-Device vs. Cross-Silo Federated Learning
Federated learning operates in two distinct regimes with different technical constraints:
Cross-Device
Participants are mobile devices, IoT devices, or edge computers. The population is massive (millions of devices), each holds a small dataset, devices are unreliable (they go offline, lose connectivity, run out of battery), and the communication bandwidth per device is limited.
Google’s Gboard deployment is the canonical example. Each Android device holds the user’s typing history. The model is trained across devices to learn next-word prediction patterns. Individual device participation is optional and ephemeral – if a device drops out mid-round, the round proceeds with the remaining devices. Google reported that their production federated learning system handles populations of 10 million+ devices with a per-round participation rate of 0.1-1%.
Technical challenges specific to cross-device: communication efficiency (model updates must be compressed, often from 400 MB to 1-10 MB via quantization and sparsification), device heterogeneity (different hardware with different computation speeds), and non-IID data distribution (each user’s typing patterns are idiosyncratic, violating the independent and identically distributed assumption of standard SGD).
Cross-Silo
Participants are organizations – hospitals, banks, research institutions – each with significant computational resources and large, curated datasets. The population is small (typically 2-100 organizations), each holds a large dataset, participants are reliable and well-connected, and the communication bandwidth is high.
The HealthChain consortium trains medical imaging models across 12 European hospitals. Each hospital holds thousands of annotated MRI scans that cannot leave the institution due to GDPR and national health data regulations. The federated model achieves diagnostic accuracy within 2% of a centrally trained model while keeping all patient data on-premises. Intel’s OpenFL framework and NVIDIA’s Clara FL platform provide the infrastructure for cross-silo deployments in healthcare.
Financial services present a natural cross-silo use case. Banks cannot share individual transaction data due to banking secrecy regulations, but fraud patterns that span institutions are detectable only with cross-institutional training. The Monetary Authority of Singapore’s Project Veritas (2023) demonstrated federated learning for anti-money laundering across six Singaporean banks, detecting 30% more suspicious transactions than any single bank’s model while sharing zero transaction data.
Privacy Guarantees and Their Limits
Federated learning’s privacy guarantee is often overstated. The protocol ensures that raw data does not leave the client. It does not ensure that the server learns nothing about the client’s data.
Gradient Inversion Attacks
Model updates (gradients) can be inverted to reconstruct the training data. In 2019, Zhu, Liu, and Han published “Deep Leakage from Gradients,” demonstrating that individual training images could be reconstructed pixel-by-pixel from a single gradient update. The attack solves an optimization problem: find the input data that would produce the observed gradient.
Subsequent work improved the attack’s fidelity and scaled it to larger models. By 2024, gradient inversion attacks could reconstruct faces from facial recognition model updates, recover text strings from language model gradients, and extract individual data points from batch gradients of up to 48 images.
The practical impact: a malicious server (or a man-in-the-middle attacker) that observes raw gradient updates can potentially reconstruct the client’s training data. This is a direct attack on the privacy guarantee that federated learning claims to provide.
Membership Inference
Even without full data reconstruction, an adversary can determine whether a specific data point was used to train a specific client’s model. Membership inference attacks test whether the model’s behavior on a given data point is consistent with having been trained on that data point (higher confidence, lower loss) versus not having been trained on it.
For sensitive applications – is patient X’s medical record in hospital Y’s training set? – membership inference is a meaningful privacy breach even without data reconstruction.
Defenses: Secure Aggregation
Secure aggregation protocols, introduced by Bonawitz et al. in 2017, prevent the server from observing individual client updates. Instead, the server receives only the aggregate (sum or average) of all client updates.
The protocol uses pairwise masking: each pair of clients generates a shared random mask. Each client adds its pairwise masks (positive for one direction, negative for the other) to its gradient before sending. When the server sums all masked gradients, the pairwise masks cancel out, leaving the true aggregate gradient. No individual client’s gradient is visible to the server.
Google’s production federated learning system uses secure aggregation with dropout handling (tolerating clients that disconnect mid-protocol) at scales of 1,000+ clients per round. The communication overhead of secure aggregation is approximately 2x the cost of plaintext aggregation, which is acceptable for most deployments.
Secure aggregation defeats gradient inversion attacks against the server, but it does not protect against colluding clients. If an adversary controls n-1 of n clients in a round, the n-th client’s gradient is fully determined by the aggregate minus the adversary’s own contributions.
Defenses: Differential Privacy
Differential privacy provides a formal, mathematical guarantee of privacy protection by adding calibrated noise to the model updates.
In federated learning, differential privacy is applied in two forms:
User-level DP. Each client clips its gradient to a maximum norm and adds Gaussian noise before sending. The noise is calibrated to ensure that the inclusion or exclusion of any single user’s entire dataset changes the distribution of the aggregate update by at most a factor of exp(epsilon). Google’s production system uses user-level DP with epsilon values of 2-8, depending on the sensitivity of the application.
Record-level DP. Each client adds noise calibrated to protect individual records within its dataset. This provides stronger per-record guarantees but adds more noise, reducing model accuracy.
The privacy-utility tradeoff is real. Adding noise sufficient for strong DP guarantees (epsilon < 1) significantly degrades model accuracy, particularly for small datasets and complex models. Apple’s reported DP deployments use epsilon values of 4-8, which provide moderate privacy protection but fall short of the epsilon < 1 threshold that the theoretical community considers strong privacy.
The combination of secure aggregation (hiding individual updates from the server) and differential privacy (limiting what any update reveals about individual data) provides the strongest privacy guarantees available in federated learning. Neither alone is sufficient.
Communication Efficiency
Federated learning’s communication cost is a major practical challenge. A model with 100 million parameters requires 400 MB per round (32-bit floats), transmitted both down (server to client) and up (client to server). For cross-device deployments over mobile networks, this is prohibitive.
Three compression techniques address this. Gradient quantization represents each parameter update with fewer bits (8-bit, 4-bit, or 1-bit), reducing update size by 4-32x. Gradient sparsification transmits only the top-k% of gradient elements by magnitude, achieving 100x reduction at 1% sparsification with minimal accuracy loss. Model distillation has clients train a small “student” model guided by the global “teacher” model, reducing communication for billion-parameter models to the student’s size.
Google’s production system combines quantization (8-bit) and sparsification (top 0.1-1%) to achieve round-trip communication costs of 1-10 MB per client per round, enabling federated learning over standard mobile connections.
Federated Learning for Language Models
Training large language models with federated learning presents unique challenges. Modern LLMs have billions of parameters, making full gradient transmission infeasible even with compression. The data distribution across clients is highly non-IID (each user’s language patterns are distinct). And the training requires significantly more computation than simpler models.
Two approaches have emerged:
Federated fine-tuning. A pre-trained LLM (trained centrally on public data) is fine-tuned using federated learning with private data. Only the fine-tuning gradients (or adapter weights, using techniques like LoRA) are transmitted, reducing communication by 100-1000x. This is the approach used by Google for Gboard next-word prediction – the base language model is pre-trained centrally, and the personalization layer is trained federally.
Federated prompt tuning. Only the soft prompt embeddings (a small set of learned vectors prepended to the input) are trained federally, while the LLM parameters remain frozen. The prompt embeddings are orders of magnitude smaller than the full model, making communication trivial. Research from CMU and Google (2024) demonstrated that federated prompt tuning achieves 90-95% of the accuracy of full fine-tuning with less than 0.1% of the communication cost.
For Stealth Cloud’s architecture, federated fine-tuning offers a path to model improvement without data centralization. User interactions improve model quality without leaving the client, aligning directly with the zero-knowledge principle.
The Intersection with Other Privacy Technologies
Federated learning is strongest when combined with complementary privacy-enhancing technologies:
Differential privacy (as discussed) limits information leakage from model updates. The combination of federated learning + DP is deployed at scale by Google and Apple.
Secure multi-party computation (MPC) can replace the trusted server in federated aggregation. Rather than a single server aggregating updates, MPC distributes the aggregation across multiple non-colluding servers, each of which sees only encrypted shares. This eliminates the trusted aggregator assumption.
Homomorphic encryption allows the server to aggregate encrypted model updates without decrypting them. The server never sees individual updates, even in the aggregate. The computational overhead of HE-based aggregation is significant (10-100x slower than plaintext aggregation) but acceptable for cross-silo deployments with small numbers of participants and high-value data.
Trusted Execution Environments (TEEs) can host the aggregation server inside a hardware-isolated enclave (Intel SGX, ARM TrustZone), providing hardware-backed confidentiality with near-native performance.
The layering creates defense-in-depth: federated learning keeps raw data on the client, secure aggregation or HE hides individual updates, differential privacy limits what the aggregate reveals, and TEEs provide hardware isolation for the aggregation computation.
Limitations and Open Problems
Non-IID data. When client data distributions differ significantly (which they almost always do in practice), FedAvg can converge slowly or to suboptimal solutions. The FedProx algorithm (2020) adds a proximal term to the local objective to prevent client models from diverging too far from the global model. SCAFFOLD (2020) uses variance reduction to correct for client drift. Research is ongoing, and no single algorithm dominates across all non-IID scenarios.
Poisoning attacks. A malicious client can submit gradient updates designed to degrade model performance or introduce backdoors. Byzantine-robust aggregation algorithms (Krum, Trimmed Mean, Bulyan) can tolerate a fraction of malicious clients, but at the cost of reduced accuracy. The fraction of malicious clients that can be tolerated varies from 10-30% depending on the algorithm and the attack model.
Fairness. Federated learning can produce models that perform well on average but poorly for underrepresented clients. If 90% of clients have English-language data and 10% have Swahili data, the federated model will be heavily biased toward English. Fairness-aware federated learning (q-FedAvg, AFL) addresses this by reweighting client contributions, but perfect fairness in a heterogeneous federation remains open.
Verification. How does the server verify that clients honestly perform local training? A lazy or malicious client submitting zero or fabricated gradients is difficult to detect without additional protocol overhead. Zero-knowledge proof-based verification is an active research area but has limited practical deployment.
The Stealth Cloud Perspective
Federated learning addresses a question that every privacy system must confront: how do you improve a product based on usage data without surveilling users? The traditional answer – collect everything, analyze centrally, promise to be responsible – is the answer that Stealth Cloud’s architecture categorically rejects. The federated answer – train locally, aggregate cryptographically, reveal only the minimum necessary – is architecturally aligned with the zero-knowledge principle.
For Ghost Chat, the application is concrete. Language model personalization – adapting response style, learning user preferences, improving relevance – typically requires collecting conversation data. In a zero-knowledge system, conversation data does not exist on the server. It is encrypted end-to-end and destroyed at session end. Federated fine-tuning offers a path: the local client can adapt a model layer using the conversation data it already holds, contribute a differentially private update to a global improvement signal, and destroy the conversation data along with everything else when the session ends.
The update reveals aggregate patterns without revealing individual conversations. The differential privacy guarantee bounds the information leakage from any single update. Secure aggregation prevents the server from isolating any individual’s contribution.
This is not a solved problem. The privacy-utility tradeoff in federated learning for language models is steep, and ephemeral sessions provide less training signal than persistent accounts. But the architectural alignment is clear: federated learning is the training paradigm that zero-knowledge systems can actually use. The alternative – centralized data collection with access controls – is the paradigm that zero-knowledge systems exist to replace.
The data should stay where it is created, be used where it is needed, and be destroyed when it is done. Federated learning is the training protocol that respects all three requirements. It is also the only approach compatible with systems that treat privacy as an engineering constraint rather than a marketing claim.