Security

Google’s new Gboard training system makes privacy more inspectable

By Saint Zero Day · 2026-10-06 · 4 min read

Google reports faster training and a smaller privacy budget for Gboard. Public code improves scrutiny, but hardware weaknesses keep the guarantees conditional.

Google announced a new training system for Gboard on October 2 that makes parts of its privacy protection externally inspectable while moving computation from phones to servers. The company says English and Japanese next-word prediction models already use it. The development offers a concrete benefit: privacy safeguards that outsiders can examine rather than simply accept on the operator’s word. That benefit remains conditional on the security of the underlying hardware. [1] [4]

Phones encrypt training examples before uploading them. An access policy identifies which server programs may process those examples, and a protected key-management service releases decryption keys only to approved workloads. Those workloads run inside trusted execution environments, or TEEs. Public transparency logs expose the permitted programs; differential privacy limits information released through model weights. Google also allows some proprietary processing logic to remain private, provided the inspectable program preserves the privacy guarantees. [1]

The strongest practical result is Google’s reported live English-language experiment, with 3.5 million devices in each arm. Its best new-system model used a privacy budget of 0.215 in the zCDP accounting framework, versus 0.641 for the previous production model adjusted to the same mechanism. Typing speed and the rate at which users modified suggestions remained neutral. Training took three weeks instead of two months. These are company-reported deployment results in a preprint, without independent replication located in this research. [2]

Why it matters

The roughly threefold budget reduction does not mean every privacy risk fell threefold. NIST’s guidance explains that meaningful comparisons require attention to the privacy definition, parameters and protected unit. Differential privacy constrains what outputs reveal about participation in a dataset; it does not automatically secure the original data or eliminate implementation failures. The reported budget is useful evidence about a specified mathematical guarantee, rather than a universal measure of how safe someone’s typing has become. [2] [3]

Moving computation also changes which devices can contribute. Google’s Japanese-model comparison incorporated 8.5 million devices during 38 days of conventional training, versus 17.8 million uploads collected in about six days for subsequent server training. The collection interval is not the full training time. Editorial inference: broader participation could improve representation of people whose phones previously failed to finish training tasks, but those counts alone do not establish better performance for particular groups. [2]

Public code gives researchers a route to investigate the protection. Google’s Confidential Federated Compute repository documents how attestation records and transparency-log entries can be mapped to reproducibly buildable binaries. Reproducing a build can help establish that published source corresponds to a particular executable. It cannot, by itself, establish that the source has no privacy bugs. The distinction matters because an inspectable safeguard still needs someone to inspect it, assess its assumptions and test its implementation. [6] [3]

The strongest independent adverse evidence concerns the hardware foundation. Researchers behind TEE.fail, including teams at Georgia Tech and Purdue, demonstrated physical attacks against Intel TDX and AMD SEV-SNP systems using equipment inserted into the DDR5 memory connection. Their results included extracting cryptographic secrets and forging Intel attestation evidence. Attestation is supposed to establish that approved code runs in a protected environment; compromising that mechanism can undermine the chain of trust before a privacy-preserving program even starts. [4]

Those demonstrations do not establish that Google’s new training service has been compromised. They require physical access to server hardware, and the researchers say they know of no exploitation in the wild. They also report that these attacks sit outside the vendors’ threat models. Editorial inference: this narrows the promise substantially. Protection against an untrusted software operator still depends on assumptions about physical infrastructure and hardware security, even when the software and its permitted behavior are publicly visible. [4]

Physical access is not the only concern. A separate preprint by CISPA and Google researchers found side-channel leakage in confidential-computing privacy workloads, including a Gboard word-discovery implementation. Such channels reveal information through observable execution behavior rather than intended outputs. The study also evaluated mitigations. It examined different workloads from the new training experiment, so it is evidence of a relevant failure mode, not proof that this particular Gboard training pipeline leaks. [5]

The evidence supports guarded hope: Google has reported a useful production result and supplied mechanisms for outside scrutiny. Confidence would rise with an independent audit connecting deployed binaries, public policies, privacy accounting and side-channel tests, alongside replicated performance measurements. A demonstrated leak in the deployed pipeline would weaken the verdict sharply. Until then, the advance is better verification under explicit assumptions, with important work remaining to establish how reliably those assumptions hold in practice. [2] [3] [4] [5] [6]