Google lets outsiders check what its servers do with keyboard data

Google Research says it has rebuilt its federated learning system so that people outside Google can check which server programs are allowed to touch the data phones send up. That is a narrower promise than “private” and a stronger one than “trust us.” Gboard, Google’s keyboard, already runs on the new system for its English and Japanese typing-suggestion models, according to a Google Research blog post dated 2 October 2026.

Federated learning, which Google introduced in 2017, trains a model without first piling everyone’s data into one warehouse. The learning happens across the phones and devices that hold the data, and the raw data is meant to stay there. Google uses it for Gboard suggestions, reply suggestions in Google Messages, and text selection in Android.

The new design bends that idea. Devices now encrypt their training examples and upload them, and the heavy computation runs on Google’s servers instead of on the phone. The step that moves is the calculation of gradients, the adjustments that tell a model how to improve. What does not move is control: each device attaches an access policy naming the exact server programs allowed to decrypt its data, and the decryption keys go only to programs that match.

Those programs run inside trusted execution environments, or TEEs, which are sealed regions of server hardware. A TEE can prove to an outside party which code it is running, and operators cannot peek at its internal state. Google’s pitch is that privacy no longer depends on keeping data off the server. It depends on the server being locked into code anyone can read.

Here is who can check what. Google publishes every access policy to Rekor, an open ledger that anyone can read, and auditors outside the company can follow it to see each server workload that could ever receive device data. The key-management and data-processing software can be rebuilt from open source code in the Confidential Federated Compute repository on GitHub, so a third party can confirm the running binary matches the published code. The post does not name any outside auditor that has done this.

The older systems had a gap here. Per the post, neither phones nor auditors could inspect the server logic, so Google had to ask for trust that it added random noise correctly. That noise is differential privacy: a calibrated dose of randomness that keeps any one person’s data from being picked out of the finished model. Secure aggregation, an earlier cryptographic fix that let the server combine device contributions without seeing individual ones, did not work with the strongest central version of that noise. Under the new setup, workload operators see only metrics and noised model weights.

The gains Google reports are self-measured on its own infrastructure, and the post gives no figures. Collecting uploads first means training no longer waits on which devices happen to be awake and charging at a given hour, a coverage problem for earlier systems. Training a model used to take one to two months. Google now says parallel server machines produce “significant speedups,” limited mainly by TEE capacity. The Gboard models also gain accuracy, in the company’s words, though the post does not say by how much or against what baseline.

The limits are written into the post itself. The guarantee holds “subject to current-generation TEE limitations,” and side-channel observations, where an attacker infers secrets from hardware behavior rather than from the code, remain an open research area. Proprietary model designs and preprocessing logic can be sideloaded into the TEE at runtime, so they stay uninspectable. The privacy-relevant logic must be hardcoded for the audit to mean anything. Google calls the work “a step toward” rigorous proof, a softer claim than the “provably private” in the paper’s title.

For anyone weighing privacy claims from a vendor that processes user data on its own servers, the useful test is now concrete: can a stranger rebuild the binary and match it to a public log? Over the next quarter, the signal to watch is whether independent researchers publish findings against Google’s Rekor entries, because a log nobody reads verifies nothing.

Based on the Google Research blog post “Toward provably private learning from federated data” by Google Research, published on its research blog on 2 October 2026.