Gboard’s new privacy system moves learning off the phone

A phone keyboard has to keep learning because people keep changing what they write. A newly popular game, a technical term or an unfamiliar name can leave yesterday’s dictionary behind. Google’s researchers used Wordle and COVID-19 as examples when explaining the problem in 2024. Gathering those words presents an awkward task: the keyboard needs to discover what has become common without exposing something that is private to the person typing it.[4]

On October 2, Google described a new training system already used for English and Japanese next-word prediction models in Gboard. It moves learning work from phones to protected servers. Encrypted training examples leave participating devices, and Google says the permitted processing can be checked externally. The deployment is Google’s reported result; it has not been independently verified for this article.[1]

The change is easier to understand against Google’s original explanation of federated learning in 2017. A phone downloaded a shared model, improved it using information on the device, and sent back a compact update. The server combined updates from many phones. The training examples themselves stayed on the phone. That arrangement separated learning from the conventional practice of collecting a central training dataset.[3]

It also separated two activities that can look identical to a user. A model can run on a phone to suggest the next word, while the process used to improve future versions happens elsewhere. Google’s original approach brought both prediction and part of the training onto the device. Whether a suggestion appears instantly on your screen does not, by itself, explain how its underlying model was trained.[3]

A longer history than Friday’s announcement

Server-assisted privacy work was already reaching Gboard before this announcement. In March 2025, Google described a system for discovering common words that encrypted device contributions and restricted server processing to published analyses. The company reported finding 3,600 previously missing Indonesian words in two days. That was an analytics task: discover vocabulary worth adding. Friday’s announcement concerns the broader work of training prediction models. Treating it as the first time Google had explored protected server processing would erase that history.[5]

The new training paper was first submitted on September 25 and revised on September 30. Its operational change is to collect encrypted examples before training begins, so a server can schedule the learning work without waiting for each phone to remain available. The researchers report an English-model experiment with 3.5 million devices in each arm. Their best protected-server model used roughly one-third of the comparison model’s privacy budget, while typing speed and the rate of modified suggestions stayed broadly unchanged. Training took three weeks rather than two months.[2]

Those are useful but bounded findings. A smaller mathematical privacy budget is not a measurement showing that a user is three times safer. Nor does faster training mean that people type three times faster. The paper reports models up to 10 million parameters; scaling much further remains future work. Its experiment supports a more efficient way to improve a keyboard while maintaining measured usability, rather than a general claim about every AI system.[2]

What happens after an example leaves the phone

The published design binds each encrypted device contribution to a policy describing permitted processing. A key-management service releases decryption keys only to approved components that establish what code they are running. The restriction therefore governs which software may open the data after it reaches the server.[6]

Processing happens inside a trusted execution environment, or TEE: a protected part of the server. The repository describes a chain linking the device to later-starting processing components. Enforcement relies on software checks and hardware-backed evidence about the running program.[6]

A separate protection is needed for the results. Even if nobody can inspect individual inputs, a useful output might reveal too much about one contributor. Differential privacy addresses that problem mathematically. NIST explains it by comparing an analysis performed with someone’s data to the same analysis without it. A properly designed mechanism limits how much the output can change because that person participated.[7]

One way to achieve this is to introduce carefully calibrated randomness. There is a trade-off: too much noise can obscure useful patterns, while too little weakens the protection. Removing names is a different operation. NIST notes that supposedly de-identified records can still be linked to other information. For a keyboard, the goal is to learn a useful population pattern while limiting what the resulting model reveals about an individual contribution.[7]

The details of that guarantee matter. NIST’s 2025 evaluation guidance distinguishes protection for a single event from protection for all of a person’s contributions. Protecting one transaction is weaker than protecting a customer’s whole pattern of purchases. Repeated analyses also have to be accounted for together: privacy loss can accumulate. A useful assessment therefore asks what is being protected, over what period and across how many uses of the data. A small number without those definitions is an incomplete description.[8]

Who can check the promise?

The system’s public record uses Rekor, a transparency log maintained by the Sigstore project. Rekor is designed to hold signed software metadata in a tamper-resistant record that others can query. Its job is to make a history available for inspection. The existence of an entry does not itself establish that the associated program has no privacy flaws; someone still has to examine what the recorded software does.[9]

Google’s inspection guide shows the next steps: find an endorsement in the log, retrieve the associated artifact, check its identifying digest and follow the evidence toward the software build. The guide includes tools for monitoring new entries and tracing published components. This is a concrete route for technically equipped reviewers to investigate the claim. It also shows how much work sits behind the word verifiable. Publishing the route makes scrutiny possible; it does not establish that an independent reviewer has completed it.[10]

The hardware still has limits

A protected server can leak information through its behavior even when an attacker cannot simply read its memory. Researchers from CISPA and Google examined this problem in SNPeek, a study presented at the 2026 Network and Distributed System Security Symposium. Their tool measured traces such as memory-page activity and processor-cache behavior on AMD confidential-computing hardware. Those observations can reveal distinctions between otherwise protected inputs.[11]

The team tested three kinds of privacy workload and found leaks, then studied ways to reduce them. The work makes the risk more specific than a generic warning that no computer is perfectly secure: the surrounding system may observe patterns created while the protected computation runs. It does not establish that the new Gboard training deployment has suffered such an attack. It does establish why the application’s behavior and defenses matter alongside the processor’s isolation features.[11]

Google’s October announcement acknowledges these hardware limits and presents complete proofs of software correctness as a future possibility. Its claim is a step toward stronger, inspectable privacy guarantees, with continuing assumptions about the machinery that enforces them.[1]

There are also different ways to combine the protections. In May, Google described a separate private-analytics design that adds a cryptographic aggregation layer to hardware isolation. In that design, individual raw contributions are not reconstructed in server memory, even inside the protected environment; the visible result is already combined and anonymized. That is not the same mechanism as uploading examples for the new training system. The distinction matters because phrases such as private analytics and confidential computing can cover different paths through the machine, with different assumptions about what may be decrypted where.[12]

What the person typing can actually see

Google’s current Gboard help page still describes federated learning as sending what a device learns rather than the text a person types. That wording does not explain the encrypted-example upload described in the research announcement. The documentation leaves a practical question about how the newer approach is explained to users and which devices participate. A claim about deployed models does not establish that every Gboard user’s phone is already contributing through this system.[13]

The help page says federated learning is enabled by default and can be turned off in Gboard’s privacy settings. It also distinguishes learning for everyone from personalization on the device, and both from voluntary donations of audio recordings. Those are separate choices. Declining to donate an audio snippet is not, by itself, the same as disabling federated learning.[13]

For a user deciding what to share, the meaningful promise has several parts: the information collected, the processing allowed and the limit on what results can disclose. Each needs an explanation that survives contact with the actual product. The progress worth watching is whether these details become easier to inspect and compare—and whether the protections cover the person’s contributions as a whole, rather than only a narrowly defined fragment of them.[8]