Privacy engineering · September 2026
A visual field guide to privacy engineering: why “delete” is rarely deletion, how two harmless tables name a stranger, and how a promise becomes a mechanism.
Scroll ↓ Every figure below is interactive. · The interactive companion to the PaddySpeaks field guide, Privacy Engineering (2026 edition).
01 Cold open
Not their name. Nobody needs their name. Watch what happens when five ordinary identifiers — each collected for a perfectly reasonable reason — are allowed to meet.
None of these is secret on its own. The email arrived at sign-up. The device ID came with the app. The payment token is how checkout works. The location ping powers “stores near you”. The cookie keeps you logged in. The harm is not in any one of them. It is in the join.
“Likely pregnant” is not far-fetched. In 2012, public reporting described a retailer’s purchase model that predicted pregnancy — reportedly before a customer’s family knew. The broken assumption: “we only use what customers gave us.” Inference counts as collection.
Five identifiers. Zero names. One person.
TakeawayPersonal data is not a column. It is what the columns become when they are joined.
The discipline, in one line
A privacy policy is a promise written in English. A database is not written in English. Somewhere between the two there has to be a chain of things that actually happen — and every link in that chain is somebody’s job.
Reads designs before launch and finds the exposure nobody drew on the whiteboard.
Output: findings, required changes, a risk ratingShips the controls: consent propagation, retention, deletion, purpose enforcement, identity isolation, access control, privacy-enhancing technologies, deployment gates.
Output: libraries, platforms, deploy gatesChecks what really runs: logs, joins, retention and runtime enforcement — not what the design said, not what the policy says.
Output: invariants, dashboards, incident fixesLawyers write what must be true. Product decides what users should feel. The privacy engineer makes the system actually behave that way. The job is not saying no. It is finding the design where the product works and the exposure shrinks.
02 The history hole
Here is a week in a shared document. On Monday someone pastes a salary sheet into it: forty names, forty numbers. On Tuesday they delete the table. The doc looks safe. On Friday a contractor is added as an Editor. At 4 p.m. the contractor opens File › Version history › Monday. Every name, every number.
Google Docs, like most modern editors, keeps a version history — being able to rewind is the feature. Per Google’s own help pages, owners and editors can open that history; commenters and viewers cannot. Scrub the week, then change who is looking.
Illustrative scenario and people. The roles and the missing per-version delete are as described in Google Docs Editors Help, as summarised in the PaddySpeaks field guide.
Who can open the past
The cruel part: an editor added today sees every version from before they joined — and a link set to “anyone can edit” hands the history to strangers.
Native Docs keep their history; there is no per-version delete.
File › Make a copy. History doesn’t travel — leave comments unticked.
Viewers and commenters never see history at all.
Trash holds it 30 days; your organization’s retention rules may hold it longer.
Every tool that remembers edits is a leak waiting for the wrong reader. Eight places “deleted” data keeps living:
Docs, Sheets, Slides, Notion, Confluence: every editor can rewind.
A 2003 UK government dossier’s Word file named the officials who had edited it.
A 2019 court filing for Paul Manafort used black boxes over text you could still copy.
A password committed and then deleted lives on in every clone and fork. Rotate it.
Edits, recalls and unsends rarely reach copies already in inboxes, exports and backups.
Recycle bins, snapshots and legal holds keep “deleted” files for weeks or years.
Search indexes, previews and thumbnails keep their own copy of what you removed.
An assistant’s memory, logs or training set may hold what the source no longer does.
Before you hit share
TakeawayDelete removes it from your view. History keeps it for everyone else. If it was ever in the document, assume it’s still in the document.
03 Promise → mechanism
Take one promise almost every company makes: “We don’t log personal data.” Now ask what, exactly, stops an engineer from typing logger.info(user) at 6 p.m. on a Friday.
The answer sits somewhere on a ladder. The bottom rungs depend on people remembering. The top rungs depend on machines refusing. Climb it.
Every rung up is harder to build and harder to bypass. Rule of thumb: every hard gate should trace back to a real postmortem. And mind the gap between rungs 3 and 4 — pre-deploy is not runtime. A check that passed at merge says nothing about the batch job that runs tonight.
TakeawayA promise nobody can violate by accident is worth more than a promise everybody has read.
04 The review
Privacy reviews go wrong in two ways: they become a forty-page questionnaire nobody reads, or a vibe. The fix is a short, fixed set of questions that works on any feature — even one you have never seen — asked in the same order every time, each with the red flag to listen for.
Here they are, applied to one ordinary feature: a smart reorder reminder that nudges shoppers when they are probably running low on something they buy regularly. Pick a question.
Applied to · Smart reorder reminder
Review outcomeShip — with four conditions.
“Is it personal?” is too blunt to act on. Tier the data first. The tier decides the default controls — so reviewers debate exceptions, not basics. One subtlety matters more than the rest: tier data by what it reveals, not by the column type. A list of SKUs is “just purchase history” — until one of them is a pregnancy test.
TakeawaySame eight questions, same order, every feature. Consistency is what turns a review into an instrument.
05 The map
Architecture diagrams are drawn to explain how the system works. Privacy review reads the same diagram differently: each arrow is a copy, made for a reason, kept for a time, readable by someone. Most of those decisions were never made on purpose — they were made by default.
Data moves through a lifecycle. A good review asks one question — and names one control — at every stage. Tap a stage.
An illustrative system for an online shop. Orange arrows leave your trust boundary or change purpose. Select any arrow — in the diagram or the list — to open its privacy object.
Every one of these started as an ordinary marketing or analytics integration. The pixel or SDK behaved exactly as designed. What failed was a review that never asked where the events went.
Shared prescription and health details with ad platforms through pixels and SDKs, despite privacy promises. First Health Breach Notification Rule case: $1.5M penalty and a ban on sharing health data for ads.
A “standard” pixel on a health page is a health-data disclosure.
Online counseling service shared emails, IP addresses and intake answers with advertisers after promising privacy. $7.8M for refunds; barred from sharing health data for advertising.
Hashed emails of therapy seekers are still health data.
Location broker sold precise coordinates tied to mobile ad IDs, exposing visits to clinics, places of worship and shelters. A proposed settlement bars selling sensitive location data without express consent.
An “anonymous” ad ID plus precise location is a person.
TakeawayIf an arrow has no purpose, no retention and no owner, it is not a design. It is an accident with a network connection.
06 Linkability
On the left, a health dataset with the names removed — the textbook definition of “de-identified”. On the right, a public list of the kind many places publish. Neither table, alone, tells you who has which diagnosis.
Now join them on the three columns they share.
| ZIP | Birth date | Sex | Diagnosis |
|---|---|---|---|
| 02139 | 1974-02-11 | M | Asthma |
| 02139 | 1961-07-31 | F | Depression |
| 02141 | 1988-11-03 | F | Migraine |
| Name | ZIP | Birth date | Sex |
|---|---|---|---|
| J. Okafor | 02142 | 1990-05-19 | M |
| R. Alvarez | 02139 | 1961-07-31 | F |
| M. Chen | 02139 | 1974-02-11 | F |
In 2000, Latanya Sweeney estimated that about 87% of the US population is likely to be uniquely identified by just three things: five-digit ZIP code, gender and full date of birth. None of those looks like an identifier. Together they usually are one. Try it on a crowd of 1,000 synthetic people — your target is in there somewhere.
people match. No one is identified.
Synthetic population · computed liveEach broke a different assumption. Learn the assumption, not just the headline.
Released “anonymized” search logs keyed by user number. Reporters identified a real person from her queries alone.
“Removing names makes data anonymous.”
Researchers re-identified subscribers by matching “anonymous” movie ratings against public IMDb reviews.
“Data nobody else has is safe to publish.”
A retailer’s purchase model predicted pregnancy — reportedly before a customer’s family knew.
“We only use what customers gave us.”
A global activity heatmap outlined the layout of sensitive military sites around the world.
“Aggregates can’t reveal anything sensitive.”
A quiz app used friend permissions to harvest data on tens of millions who never used it.
“One user’s consent covers their friends.”
Identifiers are not equal. A global, durable one (an email, a phone number, a government ID) links a person across every system that sees it — and hashing an email does not change that: the same email hashes the same way everywhere. Move right along the spectrum whenever the feature allows. The review question is always: can we use a weaker, rotating, scoped or purpose-specific identifier?
Takeaway“We removed the names” is not anonymization. Linkability is the risk; identifiers are the lever.
07 Purpose drift
Nobody sets out to misuse a phone number. It is collected, carefully, for two-factor authentication. It sits in a table. Two years later a growth team discovers the table, and the number is “already there”. That is purpose drift: the data did not move; the reason did.
Consent screens and privacy notices happen once, at collection. Drift happens at every read. So the check has to run at every read too. Press the button to run a use-time purpose check against six real-world-shaped requests.
Same data. Different flow. Different verdict.
Helen Nissenbaum’s contextual integrity (Privacy in Context, 2010): privacy breaks when information flows against the norms of the context it came from. The reviewer’s move: don’t ask “is this data sensitive?” — ask “does this flow match what the user expected when they shared it?”
@purpose("account_security", "fraud_prevention") @tier(T2) @retain(account_lifetime) phone_number: Phone read(phone_number, purpose="ad_targeting") → DENY purpose not in allow-list
This is not hypothetical. In May 2022 the U.S. Federal Trade Commission and the Department of Justice announced that Twitter would pay a $150 million civil penalty to settle allegations that it had used phone numbers and email addresses — collected from users for account-security purposes such as two-factor authentication — to serve targeted advertising. The data had not been stolen or leaked. It had simply been reused.
TakeawayBind purpose to the data, and evaluate it at the moment of use. A purpose written only in a privacy notice cannot stop a query.
08 The burn button
The story, as it’s commonly retold from Apple’s iDVD era: a team showed Steve Jobs a many-step design for burning a DVD. He went to the whiteboard, drew one window with one button, and wrote a single word. Burn.
The product absorbs the complexity. It never hands it to the person. Now look at what most consent flows hand the person instead. Try to make a genuine choice in the banner — then press the button.
We value your privacy
We and our 847 partners store and access information on your device and process personal data based on consent and legitimate interest for…
Manage 847 partners · reject
Allow “Shop” to track your activity across other companies’ apps and websites?
Your data will be used to deliver personalized ads to you.
Five purposes, 847 partners, one pre-ticked “legitimate interest” — and one bright button that says yes.
The banner is an illustrative composite. The question is the kind of single system prompt apps must show on iPhone before tracking across other companies’ apps.
That prompt shipped in 2021 as App Tracking Transparency: apps must ask, and silence means no. One honest, identical question in every app — and a “no” that apps must respect. When asked plainly, most people say no. (It was also good strategy for its maker; regulators in France and Italy later fined Apple over how the rules treated its own apps. Both things are true.)
But a “no” is only a promise until it reaches every system that acts on the person. That is the next scene.
TakeawayThe best privacy setting is the default nobody has to find. One honest question beats 847 toggles.
09 Consent
A checkbox is a moment. Consent is a value that changes over time — unknown, granted, revoked, expired — and every system that acts on a person has to know its current value. That makes consent a distributed-systems problem: the truth changes in one place and must arrive everywhere else.
Grant consent, then revoke it, and watch the revocation propagate. Every consumer still acting on “granted” after the person said no is stale.
TakeawayYour real consent latency is the slowest consumer’s. Measure P99, not the demo.
10 Time
Retention is a risk multiplier. Every extra day is another day for breach, subpoena, misuse, inference and scope creep. A raw event is most useful in the first days of its life — to compute a feature, fire a reminder, catch a fraud. After that, its usefulness decays fast. Its risk does not decay at all: a two-year-old row leaks exactly as well as a two-day-old one.
Drag the retention window. Watch how little value you give up, and how much exposure you stop carrying.
The answer is rarely “keep nothing”. It is: keep the conclusion, not the evidence. Each step down this ladder is narrower, less identifying and safe to keep for longer.
{account: 81723, sku: "PRN-VIT-60",
ts: "2026-09-12T23:41:07Z",
lat: 37.7793, lng: -122.4193}Lives 30 days
{account: 81723,
category: "vitamins",
cadence_days: 28}Lives 180 days
{week: "2026-W37",
category: "vitamins",
reorders: 14203} -- groups ≥ 50Lives 3 years
Illustrative lifetimes. The right numbers depend on the feature, the law that applies to you and the promise you made — which is the point: they should be chosen, written down and enforced by a job, not inherited from a default of “forever”.
Imagine one button that erases a person everywhere. One “delete my account” fans out to every place the data was ever copied — miss one and the promise breaks. Deletion is a distributed-systems problem. Mark the stores your deletion genuinely reaches today.
TakeawayThe only data that can’t be subpoenaed, breached or sold is data you never kept.
11 Threat modeling
Security threat models ask who can break in. Privacy threat models ask a wider question: what can anyone — including us, legitimately, doing our jobs — learn or do that the person would not expect? LINDDUN, a privacy threat-modeling framework from KU Leuven, names seven categories — the STRIDE of privacy. Walk every category across every element of your data-flow diagram.
Can items or actions be tied to the same person?
Can someone learn who the person is?
Is a person unable to deny an action they’d want to?
Can someone tell that data about a person exists?
Is personal data exposed more than necessary?
Are users uninformed, or unable to act?
Does it violate law, policy, or promise?
“Unencrypted column” does not move a roadmap. “A partner learns about a diagnosis” does. Pick an issue.
TakeawayThe privacy question: what can an actor learn or infer — even if the system behaves exactly as designed? Put “future you” on the list.
12 Your worst day
Think of a windshield. The outer glass is security: it stops most stones. The plastic interlayer is privacy engineering: when the glass does crack, it holds the pieces together and keeps them out of the passengers’ laps. Stopping the stone is security’s job. Privacy decides how much the break can hurt.
You can’t promise zero. You can decide, before launch, the most a failure could ever cost. Same event, five designs: someone steals the message server.
Illustrative index The four factors are scored 0–1 for a hypothetical messaging service and multiplied; the result is scaled so the worst design is 100. It compares designs; it does not predict harm.
The floor. Even the best design leaves something: metadata, the unlocked phone in your hand, and the person you sent it to.
TakeawayYou can’t stop every fire. You can decide, in advance, how many rooms it reaches.
13 Privacy-enhancing technologies
Differential privacy, federated learning, secure enclaves: the vocabulary is seductive, and teams reach for it before they have said what they are defending against. Sort the technologies by what they change — the data you hold, the form it takes, or who can see a computation — and choose from the threat backwards.
Every PET has a price: some utility, some trust in someone, some risk left over. The expert habit: state the threat model before naming the technology. Pick a threat.
Each differentially private answer spends some privacy loss, measured as epsilon (ε). Under basic composition the spends add up, and once the budget is gone the honest answer to the next query is no. Here the dataset has a total budget of ε = 4. Four queries have already run.
“ε = 4” is meaningless until you say epsilon per what. A budget of 4 per day is a very different promise from 4 for the life of the dataset. And cache released answers: asking the same question again spends budget again.
Q5 · weekly reorders by ZIP
requests ε = 1.0
TakeawayAsk “what threat are we addressing?” before “which PET?” — and write down the utility you paid and the trust you assumed.
14 The north star
If you cannot answer, the uncertainty is the finding.
Policy says what should happen. Architecture determines whether it actually happens. Every arrow is a decision — make it on purpose.
A working demo on synthetic data for Northstar, a fictional company: every flow, identifier, retention clock and control from this essay, in one place.
Everything else is illustrative: the people, documents, systems, latencies, retention periods and breach numbers are invented to show mechanisms, and are labelled as such where they appear. Nothing here is legal advice. The Steve Jobs “Burn” story is an anecdote as commonly retold, not a documented quotation; the consent banner is an illustrative composite.
