Google’s latest account of how it trains Gboard points to a change in the meaning of private AI: users’ information can travel to a server while technical controls restrict what that server may do with it. The important question becomes how outsiders can evaluate those restrictions.
In an October 2 research update, Google described a federated learning system using trusted execution environments, or TEEs. The company says Gboard has used it for English and Japanese next-word prediction, with improved accuracy and faster training. These are Google’s reported results, not measurements independently reproduced by TENS Magazine.
TENS Magazine’s analysis is that the development should be assessed through three separate questions: which computations are authorized, how much an output can reveal about an individual, and which attacks the computing environment can withstand. Evidence for one question cannot automatically answer the other two.
Follow the permission attached to the data
The research paper by Katharine Daly and colleagues describes devices encrypting training data before uploading it. A key-management service operating inside protected hardware limits decryption to permitted server programs. Public transparency records allow outside parties to inspect which workloads the policies authorize. The paper first appeared in September and was revised September 30; this week’s news is Google’s October account of the system and its deployment.
That makes authorization an unusually useful starting point for scrutiny. For a hypothetical user contribution, an evaluator should be able to trace the permitted purpose from the device’s policy to the program allowed to process the upload. A mismatch anywhere in that chain would matter even if the resulting keyboard model performed well. This is a proposed evaluation approach, not a reported flaw.
Google identifies Rekor as the public log used for access policies. Sigstore’s documentation describes Rekor as a tamper-resistant record of signed software metadata, with facilities for checking inclusion and log integrity. Its auditors can monitor whether records remain consistent over time.
A log therefore supplies a history that someone can examine. It does not perform the examiner’s judgment. Publishing a policy can make an overly broad permission discoverable without making that permission appropriate. TENS would look for an audit that explains what each authorized workload may learn and why that access is necessary, rather than treating the existence of a public record as the completed privacy assessment.
The output needs its own accounting
The National Institute of Standards and Technology’s differential privacy guidance provides a second lens. Differential privacy quantifies the privacy loss associated with an individual’s inclusion in an analysis. Its practical strength depends on the chosen parameters and implementation. NIST also explains that repeated releases must be considered together: privacy loss can accumulate across outputs.
Consider a hypothetical training program that produces several improved keyboards from the same contributed examples. A reader needs to know whether a stated privacy budget covers one release or the relevant sequence of releases. Without that scope, two identical-looking privacy numbers may describe different protections. This example illustrates an accounting question; it does not describe an undisclosed Gboard practice.
Putting the authorization record beside that accounting creates a more useful review. The first identifies what software may run. The second identifies the limits placed on information released by that software. An evaluator should ask for both explanations in terms that remain consistent when the program changes. A well-documented permission cannot compensate for an unclear output guarantee.
Protected hardware still has a boundary
A third source shows why the hardware assumption deserves separate attention. The SNPeek research paper, by Ruiyi Zhang and colleagues, examines side-channel leakage in confidential virtual machines. Such leakage concerns information inferred from execution behavior rather than ordinary access to protected memory. The researchers describe a toolkit for measuring leakage and testing mitigations on production AMD hardware.
SNPeek is relevant because Google itself cites it when discussing current TEE limitations. It is not evidence that the newly described Gboard deployment has been breached. Treating a general class of attack as proof of a specific compromise would overstate the research just as much as treating hardware isolation as an unlimited guarantee would.
For TENS, the useful disclosure would pair each privacy claim with its assumptions and a named check. An authorization claim needs policy and execution evidence. An output claim needs privacy accounting. A confidentiality claim needs a threat model and scrutiny of relevant leakage paths. This proposed comparison keeps an impressive result in one column from concealing an unanswered question in another.
The practical opportunity is substantial: moving training work away from intermittently available devices could make model development easier while exposing more of its privacy machinery to inspection. The corresponding responsibility is to make the inspection meaningful. Progress should be judged by the quality and scope of evidence outsiders can evaluate, alongside the accuracy of the model that users receive.
Image credit: Marco Librero, NASA Ames Research Center, via Wikimedia Commons. Pleiades supercomputer, photographed in 2008; illustrative computing infrastructure, not Google’s Gboard system. License: Public domain, United States government work. Modifications: center-cropped from 3,072 × 2,048 to 3,072 × 1,728 pixels and resized to 1,600 × 900 pixels; no generative or substantive alteration.
