Google moved phone learning into locked servers, then made the locks inspectable

THE SIGNAL IN ONE SENTENCE

Google has changed where some of Gboard's private machine learning happens. The familiar version of federated learning keeps raw examples on a phone. Each device performs part of the training locally, sends an update rather than the original data, and a server combines many updates into a shared model. Google's new system moves more of that computation back to the server. That sentence should make your privacy antenna twitch. It made mine twitch too. The reason this is not simply a return to ordinary centralized training is that the phone encrypts its examples before upload and binds them to a policy describing which programs may process them. The decryption keys are held by a key-management service running inside trusted execution environments, or TEEs. A server workload gets a key only after it proves that it matches the authorized code. The policy is also published to a public transparency log. Google has released source code for important components and says outside auditors can compare logged attestations with reproducibly built binaries. The plain signal is that Google is trying to replace one kind of trust with a chain of evidence. You do not have to trust an ordinary server operator who can quietly inspect a database. You do have to trust the enclave hardware, its attestation system, the published privacy logic, the build process and the absence of exploitable side channels. That is a much more specific bargain. It is not the same as no trust at all. The system is already being used to train English and Japanese next-word prediction models for Gboard. Google says the new architecture trains faster, reaches more devices and produces stronger privacy and accuracy tradeoffs than its previous federated-learning system. Those are Google and paper-author claims. The linked research is an author-produced preprint, not an independent audit. The public material does not give one universal speedup number, a complete external reproduction or a proof that every part of the implementation is correct. Still, the design is worth understanding because it tackles a real problem hiding inside the friendly phrase on-device learning. Phones are unreliable training workers. They go offline. They sleep. They change networks. People use them at different times of day. Batteries are precious. Models compete for limited local compute. A training round that needs a particular mix of devices can wait on geography, time zones and charging habits. Google says earlier Gboard federated-learning jobs could take one or two months. The new system allows devices to upload encrypted examples when they are available and lets an authorized server workload train later, on a schedule chosen to optimize privacy and utility. That shift removes the need for thousands of phones to be ready for the same phase of a training job. It also makes server-side parallelism available. In the experiment described in Google's post, the authors compared privacy-utility curves across 5,000 rounds with cohorts of 6,500 devices. Privacy utility is the uncomfortable seesaw in this work. Differential privacy protects individuals by limiting how much any one person's data can change the released result, usually by clipping contributions and adding carefully calibrated noise. Add too little protection and a model may reveal too much. Add too much noise and the model becomes less useful. The new system can choose a device participation schedule after uploads arrive. The authors say that improves the tradeoff, allowing smaller privacy budgets and better model accuracy than the earlier system. The journey starts on the phone. A participating device prepares training examples and encrypts them locally. It also pre-authorizes an access policy that describes the set of TEE programs allowed to touch those examples. The policy must appear in a public Rekor transparency log. Next comes the key-management service. Google describes it as a cluster of TEEs using the Raft consensus protocol. It holds the decryption keys and releases them only to workloads whose hardware attestations match the policy. Then a root TEE runs a Python training program. It can delegate parallel work to other worker TEEs. The system uses an open orchestration language derived from TensorFlow Federated to express the distributed computation. Finally, the workload releases only approved outputs. Google says operators can see metrics and differentially private model weights, not the underlying encrypted examples. Recovery state is encrypted so a failed server can resume without widening access to sensitive data. This is useful architecture, not magic dust. The strongest part is not that the server sits in a locked room. It is that the system tries to make the lock inspectable. Remote attestation lets a machine produce evidence about the software running inside an enclave. Public logs make the permitted policies observable over time. Reproducible builds let an auditor compile published source and check whether it produces the same binary identified by the attestation. Put those together and an outside reviewer can ask a sharper question than trust us. Which program was allowed to decrypt this class of uploads, which binary ran, which policy authorized it and did that permission appear in the log before the phone sent data? That is a meaningful improvement over an invisible server process. It is also an unfinished verification chain. Google's repository says binary transparency remains an eventual goal and that the build instructions will be refined as the project progresses. The blog says proprietary model details can be sideloaded at runtime as long as privacy-relevant logic remains hardcoded in the published Python program. That split may protect intellectual property while preserving privacy checks, but it gives auditors a new boundary to examine. The hardware has limits too. Trusted execution environments isolate code and data from the host system, but they are not immune to bugs or side-channel attacks. Timing, memory access, power use and other indirect signals can sometimes reveal information. Google explicitly says current hardware has limitations and points to ongoing work on side-channel defenses. Attestation proves that a measured program ran in a measured environment. It does not prove that the program is harmless, the measurement captures every relevant component, the differential-privacy implementation is correct or the hardware contains no exploitable flaw. The phone's access policy matters only if people can understand who set it, what it permits and how long the upload remains usable. A public log can expose a policy without making it legible to an ordinary keyboard user. That is the next practical challenge. For a system that learns from personal devices, public auditability should produce public receipts. A Gboard user should be able to see whether federated learning is enabled, which broad tasks use their device, how long encrypted examples may remain available and how to opt out. Researchers should be able to query the transparency log without reverse-engineering an internal naming system. Independent auditors should receive stable tools for mapping a logged policy to source, binary, privacy budget and released model. The operator should also publish incidents. If an attestation fails, a TEE vulnerability changes the risk, a policy is withdrawn or an auditor finds a mismatch, the public record should show what happened and which models or uploads were affected. This architecture has uses beyond keyboards. Hospitals could train a shared model without pooling readable patient records in one ordinary database. A fraud-detection consortium could process examples from several institutions under a narrow logged policy. Researchers could run approved analyses across sensitive survey or mobility data while releasing only protected aggregates. Each use would need its own governance. Hardware isolation cannot decide whether a dataset was collected fairly, whether the workload discriminates, whether a privacy budget is acceptable or whether a person deserves a remedy. The same infrastructure could also run synthetic-data generation or language-model inference inside attestable enclaves. Google says it is experimenting with both. That expands the opportunity and the blast radius. Arbitrary Python inside a protected environment is powerful precisely because a great many things can fit through that door. Teams considering the pattern should start smaller than the marketing diagram. Choose one bounded workload. Write the access policy in plain language and machine-readable form. Publish it before collection. Keep the encryption keys outside the ordinary operator path. Make the enclave code reproducibly buildable. Log every authorized version. Release only the minimum protected output. Commission an external review of the hardware assumptions, policy parser, privacy accounting and build chain. Practice revocation and recovery before real data arrives. Then measure the result. Did training become faster? Did more devices participate? Did model quality improve at the same privacy budget? Could an outside auditor reproduce the binary and trace the policy? How quickly did the organization react to a revoked component? Could a user understand and change participation? Google's launch is a useful correction to the idea that privacy means data never leaves a phone. Sometimes a centralized machine can provide stronger, faster and more auditable processing than a scattered fleet of small devices. But moving private examples into server enclaves does not end the trust problem. It redraws it. The good news is that the new boundary comes with source code, attestations and public logs. The honest news is that the chain still depends on hardware, implementation quality, readable policies and independent scrutiny. The lock is more inspectable. Now the inspection has to become ordinary, repeatable and public.