Differencing Attack Scan¶
Differencing-attack scan — instantiates Reconstruction-Resistant Disclosure Design
Checks whether two overlapping releases — aggregates that differ by one record, a before/after refresh, a changed filter — can be subtracted to expose the hidden individual value.
Two perfectly safe-looking numbers can betray a person the instant you subtract them. The Differencing Attack Scan hunts that leak: it checks whether a set of released aggregates — counts, sums, averages — overlap so nearly that their difference isolates a single hidden record. Report the total salary of a team, then the total for the same team excluding its one manager, and the manager's pay falls out of the subtraction, though neither figure ever names anyone. The scan's defining focus is composition: the danger lives not in any one output but in the arithmetic between outputs — overlapping filters, a before-and-after refresh, two cuts of the same table. It needs no outside data at all, which is exactly what separates it from a linkage attack; everything it exploits is already inside what you published. Run as a pre-release audit, it inventories the outputs that will exist and flags the pairs whose difference is dangerously thin.
Example¶
An HR analytics dashboard lets managers filter compensation stats by department, level, and location, and shows an average only when at least five employees match — a rule that feels safe. The differencing scan tries the arithmetic anyway. It notices that Average salary — Sales, London covers six people while Average salary — Sales, London, excluding VPs covers five; both clear the five-person floor, yet their totals differ by exactly one person, so the difference divided out reveals the lone VP's pay. It finds the same shape across a quarterly refresh: last month's team of six and this month's team of seven — the same people plus one new hire — difference down to the newcomer's salary.
The scan reports these as thin-difference pairs, before anyone outside sees them, so the dashboard can widen the minimum group, coarsen the filters, or add noise. The point is not to break the dashboard but to catch the leak that each individual view passed and only the pair created.
How it works¶
- Inventory the disclosure surface — every aggregate, filterable slice, and re-release or version that will exist and could be set against another.
- Search for thin differences — pairs or small sets whose supporting rows overlap down to a single differing record.
- Test whether the difference isolates a protected value, rather than a harmless aggregate.
- Flag the exposed cases for a preventive fix upstream of release.
What distinguishes it is that it reasons about the relationships among outputs, not any output alone, treating a sequence of individually-safe queries as one composite disclosure.
Tuning parameters¶
The dials that adapt the scan to a release surface:
- Surface scope — whether it looks within one release, across time and versions, or across separate products; wider scope catches more but explodes the number of combinations.
- Overlap threshold — how few differing records counts as "thin," from exactly one up to any group below the size floor; tighter flags more, including benign near-misses.
- Composition depth — whether it considers only pairs or longer chains of queries that jointly narrow to an individual; deeper is truer to a patient adversary but combinatorially heavier.
- Automation — an automated sweep of a query API versus manual review of a fixed report set; automation scales, while manual catches semantic overlaps a matcher misses.
When it helps, and when it misleads¶
Its strength is catching the exposure that every output passes individually and only the combination creates — the failure that minimum-cell rules alone cannot see. This is the canonical reason privacy loss must be treated as cumulative rather than certified one query at a time.[n1]
Its limitation is scale: the space of query combinations is effectively unbounded, so a scan can never prove the absence of a differencing path on an open-ended API — it is sound for a fixed set of releases, not a live query service. Its classic misuse is to clear each release in isolation and pronounce the system safe. The discipline is to treat composition as additive, cap it with a budget, and hand ongoing enforcement to the query-control siblings rather than leaning on detection alone.
How it implements the components¶
The scan fills the composition-detection side of the archetype — what an audit of the release surface can produce:
disclosure_surface_inventory— to scan for differences it first enumerates the full surface: every aggregate, filter slice, and re-release that will exist and could be subtracted against another.composition_and_query_control— it operates on composition risk directly, detecting where the arithmetic between outputs leaks; it is the detection half of controlling how releases compose.
It finds composition leaks but does not fix or prevent them: applying a remedy is release_transformation_policy via Coarsening and Generalization Policy or Noise or Randomization Release, and enforcing hard limits on overlapping queries is Query Rate and Overlap Limit; modelling an outside-data join instead of internal subtraction is reconstruction_attack_model, owned by Linkage Attack Test.
Related¶
- Instantiates: Reconstruction-Resistant Disclosure Design — the scan is the internal-consistency check that proves a release set cannot be subtracted back to an individual.
- Sibling mechanisms: Coarsening and Generalization Policy · Query Rate and Overlap Limit · Privacy Budget Accounting · Noise or Randomization Release · Small-Cell Suppression Rule · Auxiliary-Prior Review Workshop · Linkage Attack Test · Membership Inference Probe · Model Inversion Red Team · Post-Release Reconstruction Monitor · Synthetic or Perturbed Data Validation
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Differencing Attack Scan operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it checks whether two overlapping releases — aggregates that differ by one record, a before/after refresh, a changed filter — can be subtracted to expose the hidden individual value.
Independent corroboration: The frozen evidence defines Differencing Attack Scan as 'Checks whether two overlapping releases — aggregates that differ by one record, a before/after refresh, a changed filter — can be subtracted to expose the hidden individual value', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Statistics & Experimental Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Statistical disclosure control cohered analysis of overlapping aggregate releases whose arithmetic differences isolate a protected record; computer privacy research formalized query composition and systematic controls.
Related originating lineages:
- Computer Science & Software Engineering — Statistical-database security and differential-privacy research formalized adaptive query attacks, composition, and enforceable privacy budgets.
Review resolution: Official statistical disclosure control predates differential privacy as the practice of testing whether released aggregates can reconstruct protected records. Statistics is therefore primary, while database security and differential privacy are a constitutive computer-science lineage; governance is downstream control rather than a separate origin.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
A clean differencing scan on today's fixed reports says nothing about tomorrow's ad-hoc query. Detection does not scale to an open query service, so on live APIs the scan must be backed by a preventive budget (Privacy Budget Accounting) rather than trusted on its own.
[n1] The two-queries-differing-by-one-person case is the standard illustration of why privacy must be reasoned about under composition — the motivating example behind differential privacy (Dwork and colleagues), which accounts cumulative privacy loss across queries rather than certifying each in isolation. ↩