Proxies and Privacy

1Proxy features

A proxy is a feature that carries another feature's information through correlation. Drop the sensitive column — community, gender, age — and a model can rebuild much of it from what remains: in India, pincode alone narrows community sharply, and school attended, purchasing patterns and employment history each leak more.

This is why 'we do not use that attribute' — sometimes called fairness through unawareness — is a statement about the schema, not about the model. The fit optimises through whatever paths predict the label, and a proxy path is as good as a direct one.

Feature review is therefore an engineering task with one concrete question per column: what else could this be standing in for, and would the decision survive that being said out loud?

Figure. The sensitive attribute never enters the model, and its information still does: each middle column correlates with it and feeds the score, so the dashed path is live although no direct arrow was ever coded. Dropping the community column removes the node, not the correlations.

2Auditing for proxies with a probe

You do not have to argue about proxies; you can measure them. Fit a small probe model that predicts the sensitive attribute from the feature set you intend to ship, and read its held-out AUC: 0.5 means the features carry roughly nothing about the attribute, and the further above 0.5 it sits, the more faithfully the attribute can be rebuilt.

The probe is diagnosis, not cure. A high AUC does not say which feature to drop — often no single deletion helps, because the signal is spread — but it turns 'we removed the column' into a tested claim with a number on how much of the attribute the pipeline still sees.

Figure. Hold the sensitive column out as the probe's label. Fit a simple classifier from the shipped features to that label on a held-out split. AUC 0.5 means the features carry roughly nothing; the distance above 0.5 is how much of the attribute they reconstruct.

The probe audit

1. Hold the attribute outTake the sensitive column as the probe's label; it never enters the shipped model.
2. Fit the probeTrain a simple classifier — logistic regression is enough — from the shipped features to that label, with a held-out split.
3. Read the AUC0.5 is no signal; the distance above 0.5 is how much of the attribute the features reconstruct.

Coding lab. Probe for a proxy runs in the app, with checks on your output.

3Re-identification: privacy under joins

Stripping names and IDs from a table removes labels, not identity. The columns that remain — postal area, date of birth, gender — are quasi-identifiers: individually common, jointly close to unique. Re-identification is a join: line the released table up against any other source sharing those columns, an electoral roll or a leaked customer file, and the 'anonymous' rows get their names back.

This is a well-replicated result rather than a stunt: a handful of quasi-identifiers singles out most people in most populations. The arithmetic below shows why — the number of possible combinations dwarfs the number of people available to share any one of them.

The consequence for anonymisation claims: they are claims about your release joined with every dataset that exists now or later, which is why serious privacy work reasons about what an adversary could hold, not about what your table looks like alone.

Figure. Pincode, date of birth and sex are jointly close to unique. One urban pincode of about 50,000 adults against 365 × 80 × 2 = 58,400 combinations leaves about 0.86 people per cell — most occupied cells are unique. Join the released table with an electoral roll and the names come back.

4k-anonymity and where it breaks

The classical defence is k-anonymity: generalise the quasi-identifiers — pincode to district, birth date to year — until every combination that appears in the release is shared by at least k people. An attacker who joins on those columns now lands on a crowd of k, not on a person.

It breaks in known ways. If all k records sharing a combination also share the sensitive value — the homogeneity attack — the attacker learns the secret without identifying anyone. And k-anonymity says nothing about an adversary who already knows their target is in the table.

The modern successor is differential privacy: add calibrated noise to released statistics so that any one person joining or leaving the data changes the output distribution by at most a budgeted amount. It holds against arbitrary side knowledge, at the price of noisier answers — the trade the field has largely accepted for aggregate releases.

5Collect less, keep less, say why

Every field you do not collect is a field you cannot leak, cannot be compelled to hand over, and never have to defend in a re-identification analysis. Data minimisation is the design habit of collecting only what the named use needs, and it is the cheapest privacy control there is, because it applies before any engineering.

Retention is the same control on the time axis: data kept past its use accumulates risk with no offsetting value, so real deployments set deletion dates when data arrives, not when somebody remembers it. Consent completes the triangle by naming the use — and a use not named is a use not consented to, so repurposing support logs into training data is a new collection, not a technicality.

Figure. Name the specific decision a field feeds. Collect the coarsest version that serves it — district, not pincode; age band, not birth date. Attach a retention limit on arrival and make deletion the default.

Before you collect

1. Name the useWrite the specific decision or feature this field feeds; 'might be useful' is not a use.
2. MinimiseCollect the coarsest version that serves it — district, not pincode; age band, not birth date.
3. Set the clockAttach a retention limit on arrival, and make deletion the default rather than a project.