Privacy by architecture: protecting sensitive data as an act of care

Protecting sensitive data as an act of care

A reading note: This article deals with the protection of individual data — personal journals, mental-health data, personal well-being — with a focus on client-side encryption and zero-knowledge architectures. For the question of privacy in communities and collective aggregates (k-anonymity, differential privacy, sharing platforms), see the companion article: Privacy as an architecture of care.

1. Opening

You open a journaling app. You write down your most intimate thoughts. You tick "private journal." You see a padlock in the corner of the screen. You feel protected.

What you don't know: the app sends your entries, in the clear, to a server hosted in a third country, run by a provider the startup has subcontracted to a third party. The metadata — date, time, session length, approximate location — go off to an analytics service to "improve the experience." A breach at that provider exposes your notes a year later.

The padlock was a metaphor. Not an architecture.

This distinction — between privacy as a declared stance (a checkbox, a privacy policy, a reassuring icon) and privacy as a structural architecture (client-side encryption, no sensitive data readable on the server, mathematical guarantees on anonymity) — is at the heart of this article. For any platform that holds sensitive data, this distinction is not a technical detail. It is an ethical question.

2. In 30 seconds

Latanya Sweeney showed in 2002 that 87% of Americans can be re-identified with only three "anonymous" data points. Cynthia Dwork formalized the mathematical guarantees that make it possible to resist this re-identification. Together, their work defines what protecting sensitive data really means — and why privacy policies, on their own, do not protect.

3. Voices of the masters

"87% of Americans could be uniquely identified using only {date of birth, postal code, sex}." — Latanya Sweeney, "k-anonymity: A Model for Protecting Privacy" (2002)

"Differential privacy ensures that the risk to one's privacy is not substantially increased by participating in a statistical database." — Cynthia Dwork & Aaron Roth, "The Algorithmic Foundations of Differential Privacy" (2014)

"When 87% of Americans can be identified by 3 data points, no app should call its data 'anonymous' without formal k-anonymity guarantees." — Latanya Sweeney

"Privacy-as-architecture means privacy guaranteed by the structure of the code and database itself, not by a legal policy." — a founding principle of privacy-first design

4. Why it matters

Sweeney's demonstration: naive anonymization protects nothing

In 1997, the Massachusetts health research group released "anonymized" medical data — the names had been removed. Latanya Sweeney, a computer scientist at MIT, combined this data with the public voter roll of the city of Cambridge (date of birth, postal code, sex — freely available).

The result: she could re-identify 87% of Americans with only those three fields. She mailed the state governor's personal medical record to his office.

The lesson is structural: in a world where many data sources exist (social networks, voter rolls, commercial data), removing the name is not enough. The quasi-identifiers — attributes that on their own do not allow identification but combined do — are everywhere.

For sensitive data (mental health, personal journals, well-being data), the quasi-identifiers are particularly formidable:

• The time of entry (nocturnal habits)
• The frequency of use (an indicator of psychological state)
• The recurring themes (biographical markers)
• The length of sessions
• The absence of entries (can signal a hospitalization or a crisis)

Sweeney's answer: k-anonymity

Sweeney formalizes the model of k-anonymity: in any dataset that is published or aggregated, each individual must be indistinguishable from at least k-1 other individuals across the set of quasi-identifiers.

If k=100, a person cannot be told apart from 99 others. For medical data, k=100 is a standard recommendation. For mental-health or journaling data — more biographically distinctive — it is a reasonable minimum.

The concrete rule: no aggregation of data should be published or shared without a formal k-anonymity check.

Dwork's answer: differential privacy

Cynthia Dwork formalized an even more robust framework: differential privacy. The central idea is counter-intuitive: you cannot guarantee that an individual data point will never be inferred. But you can guarantee that the presence or absence of an individual in the database changes the result of the analyses so little that no one can infer anything significant about that individual.

In practice: you add calibrated random noise to the results of queries on the database. This noise masks the individual contribution while leaving the aggregated analyses statistically valid.

This is what Apple (iOS), Google (Chrome), and the US Census do today to protect their users' data during statistical analyses.

5. The practice — what real protection requires

1. Client-side encryption (zero-knowledge)

The principle: the data is encrypted on the user's device before being sent to the server. The server stores unreadable bytes. Even if the server is hacked, even under a court order, even if the startup is bought out — the data stays unreadable.

Only the user holds the key. The platform is blind by design.

What this requires technically: AES-GCM encryption on the client side, a key derived from the user's passphrase via PBKDF2 or Argon2, a random IV per entry. The data only travels to the server in encrypted form.

2. Separating data from metadata

Even with client-side encryption, the metadata (timestamp, session length, frequency) stays in the clear on the server. This metadata must be treated as sensitive data in its own right — or minimized to the strict minimum.

The rule: collect only what is absolutely necessary to the functioning. If a feature does not need precise location, do not collect it.

3. Strict k-anonymity on aggregations

If the platform aggregates data to produce collective insights, apply a k-anonymity constraint on any exposed result: each aggregate must correspond to at least 100 distinct individuals. This constraint must live in the data schema itself — not in the application logic, where it can be bypassed by mistake.

4. No precise geolocation

GPS location is one of the most distinctive quasi-identifiers. For journaling or mental-health data, never collect Lat/Long. Collect only the name the user gives their place themselves, as free text — and encrypted.

5. A real right to erasure

When a user deletes their data, it must be deleted — not "anonymized" and kept. Backups must be encrypted with the user's key, so that they become inaccessible after erasure. A real erasure means: no recoverable copy, anywhere.

6. Common pitfalls

Confusing "encryption in transit" with "end-to-end encryption." HTTPS encryption protects data during transport — not on the server. If the server stores data in the clear, HTTPS does not protect against a leak or unauthorized access on the server side.

Believing the privacy policy protects you. It distributes legal responsibility. It does not create technical protection. It can be changed unilaterally. It does not protect against leaks, court orders, or buyouts.

Collecting "for the future" what you don't need now. The temptation to store all available data "just in case" is understandable but dangerous. Every piece of data collected is a latent risk. The rule: collect only what is needed today.

Treating metadata as non-sensitive. The hour at which someone uses a well-being app at night, the frequency of their sessions, the patterns of absence — all of this is potentially as revealing as the content itself.

7. Frequently asked questions

Isn't the GDPR enough? The GDPR is a legal regulation that establishes rights and obligations. It does not create technical protection. It can impose fines after a leak — it does not prevent the leak. Privacy by architecture is the technical layer that does the preventing.

Is client-side encryption compatible with AI or analytics features? This is where the technical tension is real. If the data is encrypted on the client side, the server cannot analyze it directly. The possible approaches: ephemeral processing (the data is decrypted in the server's RAM during processing, then erased), or an explicit user opt-in for a specific entry. The trade-off must be explicit and chosen by the user.

Is this reserved for large companies with big technical teams? No. Client-side AES-GCM encryption is available through standard libraries in every language. K-anonymity is implemented with a SQL constraint. The real deletion of backups is a governance rule, not a technical challenge. These choices are within reach of modest-sized teams — if the priority is there from the start.

Why does this become an "act of care" and not just a technical matter? Because the people who share their most intimate data — their journal, their emotional states, their hard experiences — do so on the basis of an implicit trust. Betraying that trust through a technical oversight is a form of failure of care. And conversely, designing a system that structurally cannot betray that trust is a positive act of care — independent of any legal framework.

8. To go further

1. Latanya Sweeney — "k-anonymity: A Model for Protecting Privacy" (2002): the original paper, 15 pages, with the full demonstration. Required reading for any engineer working on sensitive data.
2. Cynthia Dwork & Aaron Roth — "The Algorithmic Foundations of Differential Privacy" (2014): the reference text. Read chapters 1–3 for the basics. Dense but accessible for developers.
3. *Daniel Solove — Nothing to Hide: The False Trade-off Between Privacy and Security (2011)*: a philosophical and legal overview. Useful for articulating why "I have nothing to hide" is an untenable argument.
4. *Bruce Schneier — Data and Goliath (2015)*: an overview of the risks of large-scale data collection. Indispensable context for understanding why policies alone are not enough.
5. *Helen Nissenbaum — Privacy in Context (2010)*: the conceptual framework of "contextual integrity" — privacy as respect for the norms of information flow particular to each social context. A direct application to well-being data.

Related INFUSE articles

This article deals with the protection of individual data — personal journals, mental health, client-side encryption, zero-knowledge architectures. For privacy in communities and collective aggregates (k-anonymity, differential privacy, sharing platforms), see the companion article:

• Privacy as an architecture of care — k-anonymity and the digital ethics of the collective