Differencing Attack

Two queries are each permitted. Each returns an aggregate over a group large enough to pass the minimum threshold. The groups differ by one person — and subtracting one result from the other discloses that person's value exactly.

No individual record was returned, no policy was violated, and the disclosure is complete.

Why threshold controls do not prevent it

A minimum group size evaluates a single query in isolation. The attack lives in the relationship between queries, which a per-query check cannot see. Adding more thresholds makes each individual query safer and leaves the composition unprotected.

The same reasoning applies to any aggregate-only interface, including row-level security that permits arbitrary grouping, BI tools over restricted datasets, and analytics APIs — this is not specific to clean rooms, it is simply where it is most consequential.

Implementation patterns

• Query budgets per party, limiting how much can be asked in total, since the risk accumulates across queries rather than residing in any one.
• History-aware policy that evaluates a new query against what has already been answered, refusing combinations that narrow toward an individual.
• Result perturbation — adding calibrated noise — which is what differential privacy formalises and which makes differencing unreliable rather than merely difficult.
• Approved query templates rather than arbitrary SQL, so the analysis is agreed in advance and the space of compositions is bounded.
• Query logs visible to both parties, which is both a deterrent and the input to reviewing what was attempted.
• Minimum group sizes as a floor, not the control — necessary and nowhere near sufficient.

Industry example

Advertising measurement between two platforms is the canonical case: both want overlap and lift analysis, neither may see the other's users. The naive design — a shared environment returning aggregates above a threshold — is defeated by repeated queries with slightly varying filters.

The designs that hold up constrain the query surface rather than only the output: a fixed set of measurement questions, a budget, added noise, and mutual visibility of what was run. That trades analytical flexibility for a guarantee that can be stated, which is usually the correct trade when the alternative is a guarantee that cannot.

A related trap in the same domain: hashed identifiers are not anonymised. The identifier space is enumerable and the hash is deterministic, so either party can test membership for anyone they can guess.

Failure scenarios

• Thresholds as the only control, defeated by composition.
• Arbitrary query access, which makes the composition space unbounded.
• No budget, so an attacker simply asks more questions.
• Hashing treated as anonymisation, which it is not for enumerable identifiers.
• No mutual query visibility, removing both the deterrent and the audit trail.

Trade-offs

Every mitigation costs analytical utility. Noise reduces precision, budgets end the analysis, templates prevent exploration, and history-aware policy refuses queries that are individually harmless.

The framing that makes this acceptable to the business is that the alternative is not more analysis, it is a data-sharing agreement nobody will sign. Constrained measurement that both legal teams approve delivers more value than an unconstrained design that never launches.

Interview question

"Your clean room refuses any query returning a group smaller than fifty. A partner runs two permitted queries that differ by a single filter value. What have they learned, and what should the platform have done?"