Consent is a feature, not a policy

Dermiva analyses photographs of people’s faces. There is not much input more personal than that, and the ordinary way to handle it is to write a privacy policy: a document explaining what is collected, how it is used, who it is shared with, and how long it is kept. Every company that handles sensitive data has one. Almost nobody reads them, and there is a good reason for that.

A privacy policy describes intentions. Intentions are held by companies, and companies change — they get new leadership, new investors, new revenue targets, and eventually a quarter where a metric has to move and the data sitting in the warehouse is the obvious way to move it. The policy is updated. Users are notified in an email they do not open. Nothing has been violated, and the guarantee has evaporated anyway.

The only privacy commitment that survives commercial pressure is one that would take an engineering project to break. So we stopped writing the guarantee down and started building it in.

Three decisions

In Dermiva this comes down to three things, none of which are particularly clever. They are just decisions made at the point where they are cheap, instead of promised at the point where they are free.

The camera opens when the user opens it. Not on launch, not while the app is backgrounded, not briefly to check the lighting conditions, not to improve any model. There is one path to the camera and it starts with a deliberate action. This sounds obvious and is not universally practised, and the reason it is worth stating is that the alternative always arrives disguised as a feature request — a live preview that helps framing, an auto-capture that fires when the face is centred, a passive check that reminds you to scan. Each is defensible. Together they turn a camera that opens on command into a camera that is occasionally open.

Reminders live on the device. A skincare routine notification does not require a server. It requires a local notification, scheduled locally, which iOS has supported for a very long time. Routing it through a backend would give us a record of every user’s routine and schedule, and would give us nothing in return except a slightly easier analytics query. Data you never collected cannot leak, cannot be subpoenaed, and cannot be quietly repurposed two years later by someone who was not in the room when the decision was made.

Deletion deletes. Any scan can be removed by the user, from inside the app, without contacting anyone. Not marked deleted and retained for ninety days for operational purposes. Not queued for removal in the next batch job. The button removes the thing.

Why the structural version is different

The difference between these being architecture and being policy is what happens when someone proposes reversing them.

If the guarantee lives in a document, reversing it is a copy change. One person, one afternoon, no review beyond legal. If the guarantee lives in the system — no server endpoint for reminders, no code path that opens the camera without a user gesture, no soft-delete column — reversing it is a project. It has to be scoped, scheduled, built, and reviewed, which means it has to be justified out loud to several people, at least one of whom will ask why.

That is the whole mechanism. We are not claiming better intentions than anyone else. We are claiming that we made the wrong thing expensive enough that it will get argued about, and that argument is the actual protection.

What it costs

It would be dishonest to present this as free. It is not.

Local-first designs are harder to build. State that lives on one device does not sync to another one for free, and every feature that seems to want a server has to be re-examined to see whether it really does. Debugging is harder when you cannot inspect the data. Support is harder when a user reports something you cannot reproduce and cannot look at.

The analytics cost is the one people underestimate. There are questions we simply cannot answer about how Dermiva is used, because answering them would require collecting things we decided not to collect. Some of those questions would genuinely have improved the product. We accepted that, deliberately, and it is worth being clear that the trade is real rather than pretending the privacy-respecting path is also the conveniently optimal one.

The question that generalises

The useful habit that came out of building Dermiva is a question we now ask of every system, including ones with no sensitive data in them at all:

What would this feature look like if the data never left the device?

Often the answer is that it would look almost the same, and the server was in the design out of habit rather than necessity. Sometimes the answer is that the feature genuinely requires central data, in which case you now know exactly which data and exactly why, which is a much better position than having collected everything in case it turned out to be useful.

The same question works in B2B software, where it has a different name. Every field you store about a customer’s business is a field you are responsible for securing, retaining correctly, deleting on request, and explaining in a security review. Teams tend to treat data collection as free and storage as cheap, which is true financially and false in every other respect.

Showing uncertainty

One more thing that came out of this work, adjacent to consent but pointing at the same underlying idea.

Dermiva reads eight signals from a scan — oil, pores, redness, texture, acne, spots, eye area, fine lines. These are estimates. They are useful estimates, and they are not measurements, and the difference matters enormously to a user who is deciding whether to trust the routine built on top of them.

A system that presents an estimate as a fact gets exactly one chance. The first time it is confidently wrong about something the user can see in a mirror, the entire product loses credibility, including the parts of it that were right. Communicating confidence honestly is harder than producing the estimate — it is a design problem more than a modelling one — and it is the difference between a product people rely on and a product people test and discard.

Consent and calibration turn out to be the same discipline. Both are about not taking more from the user than you have actually earned: not more data, and not more trust.