Privacy by architecture
Minimal retention, transparent processing, and data minimisation as defaults. How privacy can be built into the structure of a system rather than bolted on at the end.
Privacy is easy to describe and hard to retrofit. Once a system is built to collect everything and keep it, a privacy policy is mostly an apology for the architecture. We would rather make the architecture itself the thing that protects you, so the safe behaviour is the default behaviour and not a setting you have to find.
The principle is plain: the data that is never collected cannot be lost, leaked, or misused. So the first question we ask of any feature is not how to secure the data it gathers, but whether it needs to gather it at all.
Collect first, protect later
Gather broadly, store indefinitely, then add controls and promises on top. Privacy becomes a feature competing with every other feature.
Minimise first, by default
Collect only what a task needs, keep it only as long as the task needs it, and make deletion the normal path rather than the exception.
Data minimisation
Three defaults
Data minimisation is not a single rule. It is a set of defaults applied at each point where data could accumulate, and each one is only useful if the next one holds.
Collect less
A feature should ask for the narrowest information that lets it work, and no more, even when more would be convenient to have.
Keep less
Minimal retention by default. Where data is not needed after a session, the default is for it not to persist beyond it.
Expose less
Internal components see only the slice of data they require, so a single part of the system never becomes a view of everything.
Following a single request
The clearest way to show the idea is to follow one request through the system and watch where data does, and does not, come to rest.
Arrive
A request carries only what the task requires. Optional context stays optional, and the choice to include it sits with the person, not the default.
Process
Transparent processing: the request is handled for the purpose it was sent, and components receive only the part of it they need to do their job.
Retain, minimally
What does not need to persist is not kept by default. Where memory is useful, it is a clear, reviewable choice rather than a silent accumulation.
Let go
Deletion is a first-class path, not an afterthought. The system is designed so that removing data is straightforward rather than theoretical.
A good privacy design is boring to describe, because most of the work is in what does not happen: the data not gathered, the field not stored, the copy not made.
We are deliberate about what we do not say. We do not make absolute promises that an architecture cannot keep. What we can describe honestly is the direction every decision points in: collect the minimum, keep it for the shortest sensible time, and make the private choice the default one.
The short version
Data that is never collected cannot leak. We design for that first, and treat everything else as a careful exception to it.