In a test federation you reconstructed a client's training window from one uploaded update — what does that establish for production?

## The chair you are sitting in You are red-teaming a federation before rollout — a load-disaggregation model across household smart meters, where a recovered training example is a specific home's consumption window and therefore says whether anyone was in the house. You played the aggregation server, took one client's uploaded update, and rebuilt the window behind it. The finding is real. The question is what it licenses you to say. ## What the result actually establishes It establishes one conditional: **under the configuration you ran, an adversary with your vantage and your effort recovered training content from the update channel.** Everything that matters is in the conditions, and a finding written without them is not actionable — it is a demonstration. The conditions to state, every time: - **Local batch size.** Reconstruction from a single example is the strongest case and degrades steeply as examples are mixed. - **Local steps per round.** One step means you inverted a gradient at weights you knew. Several means the upload was a delta across a trajectory you did not observe, which is a different and much harder problem. - **Update visibility.** Did you read an individual client's update, or a cohort sum? A result from an individual update says nothing about a deployment where individuals are never visible. - **Cohort size**, if sums are what the server sees, and **who selects membership**. - **Any per-example contribution bound and calibrated noise**, and their settings. - **Rounds and effort** — how many attempts, how long, and how reliably it reproduced. ## The report that is worth something The useful artefact is a ladder: the same attack against increasing batch, increasing local steps, and then against cohort sums, with the quality of what came back at each rung. That turns a demonstration into a curve, and it lets whoever owns the rollout read off where their planned configuration sits. And here is the sentence that separates a senior finding from a junior one: **the rung where your attack stopped working is a bound on your attack, not on the channel.** A different adversary with a stronger prior over household energy patterns — knowing typical appliance signatures, typical daily rhythms — replaces some of the constraints your larger batch removed, and gets further at the same setting. Nothing you measured forbids that. If the deployment needs a claim that survives attacks nobody has run, batch size and aggregation cannot supply it; only bounding each example's contribution during training and adding noise calibrated to that bound produces a stated guarantee, and it costs accuracy — landing hardest on the households whose usage patterns are unusual, who are often exactly the ones the product cares about. ## Reproducibility and triage If the reconstruction worked once in five attempts, say so in that form. Attacks in this family are optimisation searches with initialisation-dependent outcomes; unreliability is a property of the search, not evidence that the leak is marginal. A one-in-five recovery of a household's occupancy pattern is a finding, because the adversary chooses how many attempts to make and which client to target. ## What to ask for Turn the finding into configuration requirements rather than a warning: 1. A minimum local batch size and a minimum number of local steps before any upload, enforced in the client, not documented in a wiki. 2. No individual update ever readable by the server — cohort sums only. 3. A minimum cohort size, with membership the server does not unilaterally choose and a rule preventing the same participant from being isolated across consecutive rounds. 4. An explicit decision, made by a named owner, on whether the deployment must offer a stated bound rather than an empirical curve — and if so, budget for the accuracy it costs and check where that cost lands across households. ## The failure modes to avoid in the write-up - Reporting the reconstruction without the configuration, which invites either panic or dismissal, both unearned. - Reporting the rung where it stopped as a safe setting. - Claiming the finished model is safe because the channel was fixed — attacks on the trained artefact are a separate family and untouched by any of this. - Framing it as a protocol flaw. Nothing malfunctioned: the update is a function of the data, and the deployment simply chose settings that let that function be inverted.