A loyalty team wants to sell an 'anonymised' grocery basket dataset - what is the privacy threat?

## The claim, and why it fails A grocery loyalty programme wants to monetise its data by selling a basket-level dataset to a consumer-goods partner. The team's position is that the release is anonymous because names, loyalty numbers and payment tokens have been dropped, leaving only per-visit item lists with a store and a timestamp. Anonymous data, they argue, is out of the privacy model entirely. The claim confuses two different things. - **Pseudonymisation** replaces direct identifiers with a surrogate. The data still relates to a distinguishable individual, and re-identification remains possible with additional information. It is a control, not an exit from the model. - **Anonymisation** means re-identification is no longer reasonably possible for anyone, including the recipient combining it with data you have never seen. That is a high bar, and it is a property of the *release plus the world*, not of a column you deleted. ### Why baskets in particular re-identify Purchase data is high-dimensional and sparse: thousands of possible products, each shopper touching a tiny subset, at particular stores, on a repeating weekly rhythm. Attributes that are not identifiers on their own become **quasi-identifiers** in combination - a specific niche brand, an unusual dietary product, a store plus a Tuesday-evening pattern. Uniqueness rises fast with the number of attributes, so a handful of distinctive points is often enough to isolate one record. Anyone holding an auxiliary source - their own transactions, a public review, a social post about a purchase, a colleague's known habits - can then attach a name. And re-identification is not the whole harm. Basket contents support sensitive inference in themselves: pregnancy, chronic illness, religious observance, alcohol dependence. Even attribute disclosure without a name attached - learning that the one household in this postcode segment buys a particular medication - is a privacy harm. ### The adversary here is authorised This is the point worth landing in an interview. There is no intruder, no misconfiguration, no exfiltration. The adversary position is a *contractually authorised third party*, receiving exactly what the agreement grants, plus whatever else they already hold. A security threat model of the transfer will happily confirm mutual TLS, a signed agreement, and a controlled export path - and report nothing. ## Controls that actually apply They work on the shape of the data, not on the gate in front of it: - **Aggregate.** Release counts, shares and trends above a minimum cell size rather than rows. Most partner questions are answerable this way. - **Generalise.** Product category instead of SKU, week instead of timestamp, region instead of store. - **Suppress.** Drop rare items and rare combinations - they carry most of the re-identification power and little analytic value. - **k-anonymity.** Ensure every released record shares its quasi-identifier values with at least k-1 others. Its known limit is homogeneity: if all k records in a group share the same sensitive value, the attacker learns it without ever isolating an individual - which is what l-diversity and t-closeness were introduced to address. - **Differential privacy.** For a query interface, calibrated noise gives a formal, quantified bound (an epsilon budget) on how much any one person's presence can change an output. It is the only option in this list that offers a guarantee rather than a heuristic. - **Do not ship rows at all.** Take the partner's question, run it yourself, return the answer. This eliminates the release rather than sanitising it, and is frequently accepted once someone asks. Contractual bans on re-identification and on linkage with other datasets belong in the deal, but treat them as a deterrent and a remedy after the fact, not as the technical control. You cannot audit an intention. ## How to raise it in a review Stated as a threat with a path, this gets traction: *a partner joins the release to their own loyalty or ad data, isolates households by rare purchases, and learns a health condition; the harm falls on customers who were told their data was anonymous*. Then offer the ladder - answers instead of rows, else aggregates, else generalised and suppressed rows with a stated k - and let the business pick a rung. Reviewers who only assert "this is not really anonymous" lose the argument; reviewers who arrive with a cheaper release shape that still answers the partner's question usually win it. ## Vocabulary check The *threat* is re-identification and sensitive inference by the recipient. The *vulnerability* is a release retaining quasi-identifiers at row level. The *risk* is the rated harm to customers plus trust and regulatory exposure. The *controls* are aggregation, generalisation, suppression, a formal privacy model, or not releasing rows.