Nothing to Breach, Nothing to Restore: The Real Trade in Local-First Skin Data

The scariest message a skincare site can receive

It is never "this cream broke me out." It is "my flare diary is empty." Eleven weeks of dated severity scores, the trigger notes, the photograph taken the morning the rash crossed the jawline — all gone, on a phone nobody else has touched, with no error message and nothing in a trash folder.

Nothing went wrong. The browser did precisely what it was built to do, on a schedule published years ago, and the tool that respected your privacy most completely is the one with no copy to give back. That is the honest shape of the deal: a system where the data never leaves your device cannot be breached, subpoenaed, sold to an analytics broker or leaked by a vendor three companies downstream — and equally cannot be restored by anyone, including us.

Most explanations of this stop at "your data is stored locally," which sounds like a feature and behaves like a hazard. The useful version is the mechanism: what the browser actually considers your data to be, the two entirely different ways it decides to delete it, and why the photos are the fragile part.

The inversion that keeps the server ignorant

Personalized health products almost all work the same way. You describe yourself, that description travels to a server, the server does the matching and sends back a result. It is a clean architecture, and it produces — as a by-product, not a betrayal — a database of people with skin conditions sitting somewhere with a login screen in front of it.

The local-first inversion sends the catalog to you instead of sending you to the catalog. Every visitor downloads the same public product data; the profile stays in your browser; the comparison runs on your own processor. When a page decides that a cream built on ↗ceramides and ↗petrolatum, like CeraVe Moisturizing Cream, fits a barrier-repair profile, or flags La Roche-Posay Toleriane Double Repair as an easy match for reactive skin, that judgement was made on your device against data everyone receives identically. The request log on our side records a page being fetched. It cannot record a person, because the person half never travelled.

The same inversion runs the trackers. Enter a flare in the diary and it goes into your browser's own storage; add a patch-test failure and the ingredient joins a personal avoid list that starts flagging products site-wide — a fragranced formula gets a warning, a plain one like Illiyoon Ceramide Ato Concentrate Cream does not — with the matching still happening locally. The My Skin profile, the Flare Diary and the Photo Tracker are all built on the same rule, which is why they work instantly with no sign-up and why they have nothing to send.

The cost lands in exactly one place: durability. Browsers were not designed to be a health record. They were designed to be a fast, disposable scratchpad, and they behave accordingly.

Safari deletes your data on purpose, and it is not sorry

On 24 March 2020, WebKit's John Wilander published the change that quietly redefined what "saved" means on an iPhone. Intelligent Tracking Prevention had already capped script-set cookies at seven days; trackers responded by moving their identifiers into other storage. So WebKit aligned the rest: after seven days of Safari use without user interaction on a site, that site's entire script-writable storage is deleted — Indexed DB, LocalStorage, Media keys, SessionStorage, and Service Worker registrations and cache.

Read the clock carefully, because the detail matters. It counts days of Safari use, not calendar days, and it resets on interaction with the site — a click, a tap, keyboard input. Reading an article you arrived at from search may not be enough to keep a tool's data alive; a visit that never becomes an interaction is, to that counter, a visit that did not happen. Web apps added to the home screen run outside Safari and keep their own counter, which is why the same site can be permanent in one place and ephemeral in another on a single phone.

It is worth being fair to the rule. It exists because cross-site tracking genuinely migrated into first-party storage, and it works. But the enforcement is structural, not semantic: the browser has no way to distinguish an advertiser's identifier from a person's eczema log, so both are treated as script-written data with a shelf life. Your diary is not being punished. It is simply indistinguishable, at the level where the decision is made, from the thing being punished.

Chrome has no timer. It has a landlord.

The Chromium model is quieter and easier to misread as safety. There is no seven-day rule; instead each origin gets a quota calculated as a share of total disk size rather than free space — deliberately, since a quota that tracked available space would leak a fingerprintable detail about your machine. In practice that allowance is generous: a large fraction of the disk, far beyond what a decade of dated skin entries could occupy.

Eviction is triggered by pressure, not by time. When the device runs short of storage, the browser clears the least recently used origins first and keeps going until it is back under its ceiling. Firefox applies its own limits and its own group cap; Safari layers this on top of the seven-day rule rather than instead of it. Chrome's own telemetry suggests eviction is rare for sites people visit regularly — which is true, and is also the reason it is dangerous. A mechanism that almost never fires teaches you it does not exist, right up until the month you fill your phone with video.

There is an opt-out: an origin can request persistent storage, which exempts it from routine eviction. Firefox asks the user; Chromium and Safari decide silently from your engagement history, so it is a request rather than a guarantee, and it does nothing about a manual "clear site data" or a switch to a different browser. Persistence is a probability improvement, not a backup.

Why the photos are handled as a separate object

Progress photos break the usual storage model on size alone. The key-value store that holds a profile or a wishlist is capped in the single-digit megabytes per origin — fine for text, absurd for images — so photos live in IndexedDB as compressed blobs with their dates, labels and notes, in a database the rest of the site is only ever allowed to read. Nothing outside the Photo Tracker creates it; a tool that offers to attach photos will find an empty result on a device where the tracker has never run, rather than quietly building an empty shell.

That separation is good engineering and no protection at all against the thing that actually kills data, because eviction operates on the origin, not the store. When a browser clears a site, everything that site kept goes at once — key-value entries and the image database together — specifically to avoid leaving an application half-remembering itself. The consequence is worth internalising: your diary and the photographs that prove what the diary describes have exactly the same expiry date, and it is not a date you chose.

Photos are also where the privacy trade earns its keep most obviously. A dated series of images of your face, torso or scalp, labelled by condition, is the most identifying health data a skincare product will ever hold. Keeping it in a database on your own hardware means there is no bucket of other people's photographs for it to sit next to — and no vendor incident that can ever include it.

The homework, ranked by how much it will hurt to skip

First: if you use Safari on an iPhone, iPad or Mac and you are tracking anything you would be upset to lose, the seven-day rule is not a footnote — it is the single most likely cause of your data disappearing, and it will happen during a fortnight away, an illness, a busy stretch at work. Either sign in so a copy exists off the device, or export deliberately before any gap in use.

Second: an export is a snapshot, not a subscription. A file made in March contains nothing from April, and nothing anywhere will remind you of that. If you stay account-free, tie the export to something you already do — the day you refill a prescription, the appointment you booked, the end of a month — because the failure mode of manual backups is never a corrupted file, it is a good habit that stopped in week three.

Third: two browsers on one device are two separate worlds. Data entered in Chrome is invisible to Safari on the same phone, not hidden but genuinely absent, and a private window is a world that is deleted when you close it. Fourth: "clear cookies and site data" is total and immediate, as are the phone-cleaner apps that do it on a schedule you have forgotten you enabled.

And the flip side, which is the part people rarely get told with a straight face: deletion actually works. Clearing site data removes the profile, the diaries, the scores and the local photo database, permanently, with no copy retained anywhere to be reconstituted later. On most health platforms "delete my data" is a request that enters a queue. Here it is a browser operation, and it is done when the dialog closes.

The case for keeping it this way

It would be easier to require accounts. It would also put us in the same building as everyone else. When researchers intercepted the traffic of 36 top-ranked depression and smoking-cessation apps for a 2019 JAMA Network Open analysis, 29 transmitted data to services run by Google or Facebook — and of the 28 sending data to Google, only 12 disclosed it in a privacy policy. A larger 2021 BMJ study of 20,991 Android health apps found 88.0% contained code capable of collecting user data, 28.1% published no privacy policy at all, and 23.0% of observed user-data transmissions travelled over insecure protocols.

None of that requires bad intent. It is the ordinary gravity of a system that has your data: analytics get added, a crash reporter ships identifiers, an acquisition changes who "we" refers to. The only architecture immune to that gravity is one where the sensitive half never arrives — which is why a barrier cream like La Roche-Posay Lipikar Eczema Cream can be matched to your eczema profile without any server learning that you have eczema.

We are not going to pretend the trade is free. Local-first is worse than the alternative at exactly one thing — surviving — and that one thing is what people notice. An account fixes the survival problem by reintroducing a server, honestly and narrowly: storage and sync, nothing else. Both positions are defensible. What is not defensible is letting someone learn the difference by losing eleven weeks of their own evidence the week before a dermatology appointment. So: check which browser you are in, decide today whether your copy lives in a file or a login, and let the tools be the fast, private scratchpad they are good at being.