Privacy and PII handling
Minimising, isolating and deleting personal data on purpose.
01The intuition
The problem it solves
A maps app collects every phone's location every few seconds to compute live traffic. That data is useful and dangerous in the same bytes: aggregated, it shows which roads are slow; raw, it shows where one person sleeps, works and prays. The same is true of an email address in a log line, a face in a photo, a voice recording from a speaker in a kitchen.
The naive approach is "collect everything, decide later". Later never comes, the data spreads into logs, caches, backups and analytics tables, and a single breach, subpoena or curious engineer exposes all of it. Privacy is a design property: what you never store cannot leak, and what you store in one guarded place can be deleted on request.
Build it one piece at a time
Step 1: classify the fields. For each piece of data the system holds, label it: public, internal, personal (an email, a name), or sensitive (location, health, payment, biometrics). The label decides where the field may live and who may read it.
| Field | Class | Where it may live | Kept for |
|---|---|---|---|
| road segment speed | public aggregate | anywhere | years |
| user id | internal | databases, logs as a pseudonym | account life |
| personal | account store only | account life | |
| raw GPS trace | sensitive | ingestion buffer only | minutes |
Step 2: minimise at the edge. Do not send what you will not use. The phone can round its location to a road segment and a 5-minute bucket before uploading, so the server never receives the exact point. A smart speaker can detect the wake word on the device and only stream audio after it.
Step 3: separate identity from behaviour. Store personal fields (name, email, phone) in one account service behind strict access. Everywhere else use a pseudonymous id. Logs, analytics and caches carry the id, never the email. Joining the two requires an authorised call to the account service, which is logged.
Step 4: aggregate and add noise before sharing. Traffic speeds are computed per road segment from many phones, and a segment with fewer than, say, 10 contributors in the window is not published. For statistics that leave the system, differential privacy adds calibrated random noise so no single person's presence changes the result enough to be detected.
Step 5: delete on purpose. Every sensitive field has a retention period and a deletion job. Raw traces are dropped minutes after aggregation. An account deletion fans out to every store that holds the id, and the account service's deletion of the identity row makes the pseudonymous data in other stores unlinkable even before it is purged. Backups are encrypted with keys that can be destroyed, so deletion reaches them too.
Why it works, with the numbers
Less data, held for less time, in fewer places, is a smaller target. The raw GPS stream for 100 million phones at one point per 5 seconds is
108 ÷ 5 s × 50 B ≈ 1 GB/s ≈ 86 TB/day of sensitive data if kept; the aggregated segment speeds are a few GB/day and contain no person
The guarantee is twofold: a breach of any one store exposes either identities or behaviour but not both joined, and a deletion request is honoured within a stated time (for example 30 days including backups). The honest failure modes: pseudonyms re-identify when joined with outside data (a sparse location trace is a fingerprint even without a name, which is why raw traces are not kept); aggregates with small counts leak individuals (hence the minimum-contributor rule); and logs are where personal data hides, because a developer printed a request body once.
The trade-off you must say out loud
Every minimisation step removes a capability you might have wanted later, such as debugging a specific user's bad route or training a model on raw traces. Say what you chose not to keep and why it is still enough for the product. The interviewer will ask how you honour "delete my account" across a hundred services, which is the pseudonymous id, a deletion event on a queue, and a report that every service confirms completion.
Where it shows up in the 100 Google problems
- Collect GPS data and show live traffic: on-device rounding, short-lived raw buffers, minimum contributors per segment, and only aggregates stored.
- Design Google Home: wake-word detection on the device, audio retention limits and a visible activity log users can clear.
- Authentication platform: the account service as the one home of personal fields.
- A/B experimentation platform: exposure logs keyed by pseudonymous ids and aggregate-only results.
- Summarise e-commerce reviews with an LLM: stripping names, emails and order numbers before text reaches the model.