Skip to content
The Data EngineeringThe Data EngineeringBeta
About
Main content

Consent, clean rooms and synthetic data

Why is consent propagation unsolved, and what do clean rooms and synthetic data really protect?

Consent is a per-person, per-purpose, time-varying yes/no ("Patient 4471 allows research use until withdrawn"). Data flows in datasets. The mismatch is total: the policy unit is (individual × purpose × time), and the enforcement unit is (table × job). This is the law of granularity mismatch, in the most extreme ratio anywhere across the platform.

There are three ways to try to bridge it.

Filter at ingest. Admit only consented records. This is cheap and correct for the current state. But consent can be withdrawn, so a withdrawal has to reach back through everything already derived. That is the right-to-be-forgotten problem again.

Carry consent as data. Add a consent column that travels with the row, and filter on it at every read. This works and is the honest approach. The price: every join must decide how to combine the consent flags. The safe choice is intersection (both sides must consent), which shrinks the usable data at every step of the pipeline. Every aggregate must also decide what a partly consented group means.

Carry consent as metadata. Tag the dataset and pass the tag through lineage. This is what most platforms do, and it is a convention, not an enforcement. Nothing stops a job from reading the data and writing output without the tag. A policy attached to metadata goes only as far as every tool chooses to cooperate. This is the again: the control must sit where all the data passes (the read path), and tags are not on the read path, so they are documentation.

The honest conclusion: is not solved at the level that regulation assumes. What exists today is a dataset-level approximation plus manual review.

Secure multi-party computation and clean rooms

The problem: two parties want the result of a join over their combined data, and neither may see the other's rows. (Example: Hollis and a pharmacy chain want to count patients who appear in both lists.) Classically this needed a trusted third party, which is a legal arrangement, not a technical one.

Secure multi-party computation (MPC) removes the third party with cryptography: the parties jointly compute a function and each learns nothing except the output. (PSI), which finds the overlap of two lists, is the special case efficient enough for wide use. General costs orders of magnitude more compute and, more limiting, many communication rounds. So it is used for narrow, fixed functions and not for interactive analytics.

Here is the point that clean-room marketing usually hides: Nothing in the protocol stops the output from revealing individuals.

  • An intersection of size one identifies a person exactly.
  • A party who controls their own input can design it to probe: submit a list that contains one target and learn exactly whether that person is in the other party's data. This is the again, arriving through a legitimate participant.

So every practical (a managed environment where two parties combine data under rules) adds output controls: minimum aggregation thresholds, limits on query shapes, limits on repeated similar queries, and manual review. These are k-anonymity thresholds and query auditing, and we saw that both are defeated by composition. Clean rooms therefore give strong cryptographic protection of inputs and weak, syntactic protection of outputs, and the output is where the real privacy risk lives. The sound design is MPC (or a trusted mediator) plus on the output. That combination is rare, because DP noise hurts most on exactly the small, targeted aggregates that clean rooms exist to produce.

Synthetic data

The idea: fit a generative model to the real data, sample new records from it, and use those samples. The appeal is that no real record is present.

The argument that breaks the naive version: the usefulness of comes from fidelity to the real joint distribution, and identity lives in that joint distribution. A generator good enough to be useful has learned the structure that makes records identifiable. Generative models memorize, especially rare records, which are the outliers. Outliers are at once the highest privacy risk and the most interesting test cases. Membership-inference attacks (is this person in the training data?) and extraction attacks against generators are practical. "Synthetic, therefore private" is false as a general claim, and it is one of the most confidently repeated falsehoods in this area.

The sound version trains the generator under differential privacy. The synthetic output then inherits a DP guarantee. This is the one elegant construction in this article: it turns a one-time privacy cost into unlimited later queries with no further budget spent. It is the escape from the depleting budget: pay ε once when you generate, then query the synthetic set as often as you like.

The price is what the noise argument predicts. DP training keeps the bulk of the distribution and destroys the tail. The synthetic data is faithful on common cases and wrong on rare ones.

  • For testing, this is often fine. Schema conformance, volume, shape, join and performance behaviour do not depend on the tail.
  • For analysis, it is dangerous. Any conclusion about a rare segment is an artefact of the generator. Correlations that the generator failed to learn are silently absent, so a query that returns a plausible answer gives no signal that it is wrong.

Honest scope: synthetic data is a good mechanism for non-production data and a poor one for analysis. It is a privacy mechanism only when the generator is DP-trained.