Anonymize It, Then Attack It: A Tabular Privacy Toolkit on the Hub

Most privacy work stops at the moment the anonymized file is written. You drop the names, band the ages, add a bit of noise, and ship it. The dataset looks anonymous, so it is treated as anonymous.

That last step is the dangerous one. "Looks anonymous" is an assertion, not a measurement. The history of re-identification research, from the Netflix Prize de-anonymization to the recovery of medical records by linking on ZIP, birth date, and sex, is a history of datasets that looked fine and were not. The same story now plays out one level up the stack: membership-inference and training-data-extraction attacks have shown that models, including large language models, memorise and regurgitate the records they were trained on. A model is only ever as private as the data behind it.

So if you train on sensitive tabular data, or you want to release a dataset for others to train on, this is your problem and not only the legal team's. The fix is not a better one-shot recipe. It is a second step: after you anonymize, you attack your own output and measure what survived. That second step uses the exact same instrument the ML privacy literature points at models - a membership-inference classifier - except here you point it at the data before anything is ever trained on it.

This post introduces a small ecosystem on the Hub built around exactly that loop:

• 📂 Anonymization Before/After - a paired dataset that shows the same records before and after a 10-step pipeline.
• 🔒 Privacy Lab - upload a CSV, anonymize it with editable YAML, then run 10 adversarial attacks against the result.
• 🛡️ Synthetic Data Privacy Audit - upload a real and a synthetic CSV and get a privacy verdict.

All three are powered by the open-source data-anonymization-toolkit, and all three are schema-agnostic: every column is named in a YAML config, so nothing is hard-coded to one dataset.

The two-step loop

The toolkit treats privacy as a pipeline with a verifier bolted onto the end.

Step 1 - Anonymize. A 10-step pass over the table:

1. Drop direct identifiers (name, email, phone, national ID).
2. Generalise quasi-identifiers (band a continuous age into 50 - 60, collapse rare categories into Other, round, or cap).
3. Scrub fingerprint columns and residual fingerprint patterns (internal batch IDs, source-system codes, SSN-shaped strings).
4. Inject calibrated noise into numeric targets (multiplicative or Laplacian).
5. Perturb dates with a deterministic HMAC-based offset, so the same record always shifts by the same amount but the true date is hidden.
6. Enforce k-anonymity over the quasi-identifier groups, suppressing rare combinations until every group has at least k members.

Step 2 - Red team. Ten adversarial attacks then probe the anonymized output for the leakage the first step missed.

The point of step 2 is that it can fail. A privacy tool that always says "looks good" is theatre. The interesting result is when the red team comes back and says: row 412 is still unique on (age band, region, gender), or your "rounded" income column has values with six decimal places, or the null pattern across three columns is a fingerprint that uniquely tags 4% of the data.

The 10 attacks

These run against any anonymized or synthetic table. Each returns a pass/fail, a continuous risk score, a severity, and a remediation hint.

The uniqueness and rare-combination attacks are the workhorses, and they are why k-anonymity enforcement is not optional. The numeric-precision and ratio attacks catch the subtle failures: you added noise, but you forgot to round, so the noise itself became a fingerprint.

See it on a real before/after

The Anonymization Before/After dataset makes the pipeline concrete. It ships two splits of the same records:

The 161 missing rows in the anonymized split are not lost data. They are the cost of k-anonymity: every combination of (age band, region, gender) that appeared fewer than 5 times was suppressed. That row count drop is the privacy budget made visible. For anyone who trains on the output, it is also the privacy-utility tradeoff in its rawest form: 161 rows of training signal exchanged for a guarantee you can state precisely. Tune the k target up and your model gets safer and hungrier at the same time. The toolkit lets you watch exactly where those two curves cross instead of guessing.

The PII in the raw split is entirely synthetic. Names follow the pattern Person_001, emails are person_001@example.com, and "national IDs" are random 9-digit strings. No real person is represented. The dataset exists precisely so you can demonstrate privacy techniques on PII-shaped data without ever touching real PII.

Try the pipeline in the browser

Privacy Lab is the toolkit with a UI. Upload a CSV, or hit Run immediately against the bundled 500-row sample. You edit two YAML configs directly in the page:

• the anonymization config (which columns are direct IDs, how to generalise each quasi-identifier, how much noise, the k target), and
• the red team config (which columns are quasi-identifiers, which fingerprint patterns to scan for, which numeric targets to test).

Run anonymization, watch the row and column counts drop in the summary, then switch to the Red Team tab and fire all 10 attacks at the output. Because the configs are editable, the Space doubles as a teaching tool: lower the k target and watch the uniqueness attack start to fail; remove the rounding step and watch numeric precision light up.

Everything is processed in memory. Uploaded files are never persisted, and reloading the page clears all state.

Why this is its own ecosystem

The three artifacts are designed to reinforce each other:

• The dataset is the worked example: a frozen before/after you can read, cite, and benchmark against.
• Privacy Lab is the interactive version of that example, on your own data.
• The Synthetic Data Privacy Audit Space extends the red team to a different threat model: synthetic data generators. (More on that in a companion post - synthetic data has its own failure modes, and most generation libraries never check for them.)

If you take one idea away: anonymization without adversarial validation is a hope, not a guarantee. The tooling to turn that hope into a measurement is now a few clicks away.

Links

• 📦 Toolkit: github.com/timothy22000/data-anonymization-toolkit
• 📂 Dataset: t22000t/anonymization-before-after
• 🔒 Space: t22000t/privacy-lab
• 🛡️ Space: t22000t/synthetic-data-privacy-audit

The toolkit is MIT-licensed. Configs are plain YAML, so pointing it at your own schema is a copy-paste-and-rename exercise, not a code change.