By Hamza Faisal
Google Research has unveiled a next-generation federated learning system that moves model training off your phone and into sealed, attestable server hardware. The company says it is the first federated learning system to offer externally verifiable central differential privacy guarantees — meaning outsiders can now check that Google's privacy claims are real, rather than taking them on trust. The system was described in a Google Research blog post on October 2, 2026, alongside a paper (arXiv:2609.31494).
Google introduced federated learning in 2017 as a way to train AI without raw data ever leaving devices. The technique powers next-word prediction and Smart Compose on Gboard, reply suggestions in Google Messages, and Smart Text Selection on Android. But the earlier systems had a trust gap: devices uploaded data for immediate aggregation, and cryptographic Secure Aggregation could not be paired with central differential privacy algorithms like matrix factorization DP-FTRL. Users had to trust Google to add the privacy noise correctly.
How the sealed training works
The new design pushes client gradient computation into server-side Trusted Execution Environments, or TEEs — hardware enclaves built on Google's Project Oak framework — and makes that server logic attestable, so the operator no longer needs to be trusted. It works in four stages. First, devices encrypt training examples locally and pre-authorize an access policy that lists exactly which TEE computations may process the data; every policy must appear in a public transparency log. Second, a Key Management System built from TEEs running the RAFT consensus protocol releases decryption keys only to workloads matching that policy. Third, a root TEE runs the Python training loop and delegates subtasks to worker TEEs, orchestrated through Federated Language, a system derived from TensorFlow Federated — and only differentially private model weights are ever released. Fourth, each round saves an encrypted recovery state.
The access policies are published to Rekor, Sigstore's public transparency log, and the KMS and data-processing binaries can be reproducibly built from open-source code, so external auditors can trace every server workload a device could feed. To protect proprietary architectures, TEEs can sideload serialized logic at runtime, but all privacy-relevant logic stays hardcoded in the attested program. Workload operators see only metrics and differentially private weights, and encrypted data can be decrypted only for a limited window after upload.
What Gboard gains from the move
Gboard has already shipped English and Japanese next-word prediction models trained on the new system, with stronger privacy guarantees and improved accuracy. Two design choices drive the gains. First, all uploads are collected before server-side training begins, so diurnal swings in device availability no longer slow things down — the program can compute an optimal participation schedule and tune differential privacy parameters. Google's privacy-utility curves come from training an English model for 5,000 rounds with cohorts of 6,500 devices on both the old and new systems.
Second, the bottleneck moved to the server. Previous federated models took one to two months each to train. Training now parallelizes across machines, limited only by available TEE capacity, with Google reporting substantially faster compute times.
Why it matters beyond Gboard
The shift is significant because it converts a trust-based privacy promise into a mathematically verifiable one. Independent researchers can now verify how typing-derived data is handled instead of relying on Google's word. Caveats remain: full source-to-running-binary verification is still an eventual goal, and side-channel attacks on the secure hardware are an open concern. The core TEE binaries and Federated Language are released under the Apache 2.0 open-source license, inviting that external scrutiny.
By Hamza Faisal



