In this analysis
Where computation runs matters, but the privacy claim depends on the protocol, visible information and threat model rather than the location label alone.
The October federated-learning announcement describes a shift in where some work is performed while emphasizing verifiable protection. This makes a useful retrospective question explicit: which part of a privacy argument comes from location, and which part comes from the protocol?
The dated path
-
2016-11-14: Practical Secure Aggregation for Federated Learning on User-Held Data.
-
2017-04-06: Federated Learning: Collaborative Machine Learning without Centralized Training .
-
2026-10-02: Google presents verifiable privacy for federated learning.
Location describes an arrangement, not the whole guarantee
A local workflow can still transmit sensitive intermediate information, while a server-side workflow can place constraints on what an operator can observe. The relevant comparison therefore needs more than a diagram showing where a processor sits. Our interpretation is that the history of federated learning increasingly separates placement decisions from information-exposure claims. The architecture label remains useful, but a reader must examine what crosses each boundary and which party is assumed to be able to inspect it.
The adversary and the interface need a definition
A privacy argument can change depending on whether the concern is the infrastructure operator, another participant or an observer of released outputs. The same placement can support different claims under different assumptions. A useful account states those assumptions and the interfaces involved. This is a high-level analytical requirement, not a guarantee for any particular hardware environment. It prevents an appealing label from substituting for an explanation of what the system actually protects and what remains outside the stated model.
A counterfactual with the same training objective
Compare two workflows pursuing the same learning task but exposing different intermediate information to the relevant observer. Record both the computation placement and the protocol evidence. The result may show that a placement change improves participation or efficiency while a separate mechanism supports protection. Keeping the explanations separate makes the tradeoff inspectable. It also avoids treating every performance gain as evidence of weaker privacy or every local operation as evidence of stronger privacy, neither of which follows from location alone.
What the infrastructure contract should say
A service description can identify which operations occur where, which information is released and which verification applies to the named configuration. Updates should preserve the connection between that description and the actual protocol. The October research announcement supplies a concrete milestone in this direction, rather than a universal ruling on local and cloud computing. The historical lesson is to evaluate placement as one component of a larger system. A credible privacy claim names the boundary it protects and the evidence that makes that boundary meaningful.
Technical background
Related engineering context: Local and server architecture; Execution identity.