4 docs tagged with "secure aggregation"

Federated analytics: compute only the "statistics," never centralize the raw data — but the guarantee still hinges on DP + secure aggregation

In one sentence that trains a model, this computes statistics. Already deployed the word "federated" does not automatically mean private — keeping data local is only the start; the real privacy guarantee hinges on whether DP and secure aggregation are actually done right; miss either layer and the aggregate result plus multi-round queries can still shake individuals loose.

Gradient leakage: "sharing gradients, not data" doesn't stop inversion — gradients can be reconstructed into training samples

In one sentence "sharing gradients" ≠ "private"; FL needs secure aggregation + DP for a real guarantee — don't read "didn't send raw data" as privacy.

Production-grade DP·FL: keeping data on-device is only the start — updates leak, so layer DP + secure aggregation

In one sentence DP (bound a single device's / user's influence on the model) + secure aggregation (the server sees only the sum of many devices' updates, not any single one). Real deployments FL ≠ private, watch local DP's ε, and don't mismatch user-level vs sample-level. This is the deployment face of Volume 3 DP fine-tuning at "federated + large-scale production."

Secure aggregation: let the server see only "the sum of everyone's updates," never any single update

In one sentence use secure multiparty computation so the server can compute only "the sum of all clients' updates," never any single update — the single point is hidden, and inversion loses what it stands on. It's communication-efficient and robust to client dropout, and is already used in Google's production FL (Bonawitz et al., MLSys 2019 secure aggregation downgrades "the server is trusted" to "the server only sees the aggregate sum"; but it's not a cure-all — it defends against "seeing a single update," not "the aggregate sum itself leaking" or "parties colluding," so still pair it with DP.