Build1 publisher2 min readPublished
Google moves federated learning onto attested servers so auditors can check the privacy noise
Google Research now trains federated models inside attested TEEs and logs each access policy to the public Rekor log, with Gboard already switched over. The server-side noise step that users once had to take on trust becomes code an outside auditor can check against open source.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Google introduced federated learning in 2017, and it has powered Gboard's next-word prediction and Smart Compose, Messages reply suggestions and Android's Smart Text Selection.
- Google's production models previously got their differential privacy from matrix factorization DP-FTRL and from distributed differential privacy paired with Secure Aggregation.
- Secure Aggregation protected uploads cryptographically but was not compatible with state-of-the-art central differential privacy guarantees.
- Under the new system, workload operators can see only metrics and differentially private model weights, never the uploaded training data itself.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- capability Outside auditors can match the published training program, the attested binary and the open-source build, so the differential privacy claim can be checked by someone other than Google.
- exposure The guarantee now depends on enclave hardware, so a flaw in current-generation TEEs would reach every federated workload built on them.
- decision Teams considering a similar design have only Gboard's unquantified speed-up to go on, so accuracy and coverage gains have to be measured on their own workloads before they count.
In Google's earlier federated systems, the weak point was a single step on the server. Daly and Ramage wrote that because neither devices nor auditors could verify the server's logic, "we needed to be trusted to correctly add random noise to gradient sums to provide differential privacy." [12]
In the new system, the access policies published to Rekor directly describe the Python program that expresses the training logic [13]. So the noise step now sits in code an outsider can read. The privacy policy, in this design, is a Python program in a public log [1].
I think the structure is sound, because each part covers a gap the others leave open. Rekor records the full set of server workloads that could touch a device's upload, and external auditors can watch it [10]. Remote attestation lets a third party verify the logic a TEE is executing [5]. The key management and data-processing binaries can be reproducibly built from open source in the Confidential Federated Compute repository on GitHub [11]. Without reproducible builds, an attested binary has no public source behind it. Without the log, no outsider knows which other programs were cleared to read the same data [3].
The enclave is also how Google gets past Secure Aggregation's clash with central differential privacy [6]. Uploads are decrypted inside an attested TEE, so the noise can be added centrally by a program anyone can look up [2].
Google's own teams are bound by the same rules. Device data can be decrypted only inside TEEs running Python programs represented in the access policies, and only for a limited time after upload [9]. Devices also know at upload every server workload that may read their data [10]. Put together, a training job has to appear in a published policy before the data it wants is uploaded [4].
The post credits the server-side shift with faster training, better accuracy and wider device coverage [1]. It does not publish a figure for any of the three. The one result it reports is that Gboard is seeing "substantially faster compute times" than under the previous system [15]. That comparison is against Google's own earlier stack on one product's training jobs. It carries over only to workloads that look like Gboard's [5].
Daly and Ramage wrote that the system is "the next milestone in our ongoing effort to completely remove the need to trust the server operator." [14] The trust left over moves to the enclave hardware [6]. Google states that the TEE properties hold "subject to current-generation TEE limitations." [5]
What to watch
- Whether Google publishes speed, accuracy or device-coverage figures for Gboard under the TEE system against its previous federated stack.
- Whether external auditors publish reviews of the Rekor access policies and the Confidential Federated Compute builds.
- Whether Messages or Android Smart Text Selection move to the TEE-based system after Gboard.