Your migraine log left your phone before you closed the app.

2am, and the entry is already gone

You log an aura at 2am. Residual photophobia, the neck stiffness that always trails it, mood flat as a parking lot. You tap save and set the phone face-down.

By the time the screen goes dark, that entry may already have left the device. Tagged to an advertising identifier, bundled with a timestamp and your rough location, queued for a company whose name you have never seen. Not because you were careless. Because the app was built that way, and the box you were asked to tick said nothing about where the data physically travels.

The uncomfortable part is how ordinary that is. For a lot of health apps, the log isn't only a record for you. It's an input for someone else's business.

The invisible export

Here is the thesis, and it has a name worth remembering: the invisible export. Your symptom data is quietly exported the moment you enter it, through code you can't see, to parties you never chose, under a consent you didn't meaningfully give.

This is not a claim about one bad app. It's a description of a default. Most consumer health software is assembled from third-party building blocks, analytics kits, crash reporters, advertising kits, cloud backends, and each block is a pipe. Data flows through pipes. A migraine timeline is unusually rich cargo: it maps your neurological state, your medication categories, your worst days, on a schedule.

Why 'just read the privacy policy' is bad advice

The standard advice treats privacy as something you can audit by reading. Open the policy, scan for the scary sentence, decide. The trouble is that the policy describes intentions in a document, while the data flows through architecture in the background, and the two are only loosely related.

A policy can promise restraint and still sit on top of a stack that ships events to a dozen SDKs. It can say "we don't sell your data" while sharing it, which is a different verb with different rules. And it can change the week after you install, on a page you will never revisit. Reading harder doesn't fix a pipe. The question that actually predicts your exposure isn't in the prose at all: does the data leave your device, and if so, to how many hands?

What the enforcement record shows

This isn't theoretical worry. The regulatory record is specific. A large 2019 study of medicines-related apps found that the majority routinely shared user data with third parties, often analytics and advertising firms, frequently in ways users would not expect. The FTC has since acted on the pattern directly: in 2021 it settled with a consumer health-tracking app over sharing sensitive data with advertising platforms, and in 2023 it levied its first Health Breach Notification Rule penalty against a health app for feeding user data to ad networks.

None of those companies called themselves data brokers. They called themselves health apps. The data-sharing was a line item in the business model, not an accident.

Four ways a symptom log leaks

Strip away the branding and the leaks fall into four repeatable patterns. Map whatever you're using onto them and you'll know your real exposure faster than any policy read.

The first is the analytics SDK: telemetry meant to measure crashes and usage that carries symptom context along for the ride. The second is the advertising SDK: discrete events tied to your advertising identifier, which is how a migraine spike becomes an ad-targeting signal. The third is the cloud-account default, the quietest and most consequential: your entire timeline living on the vendor's server, which means it is exposed to their breaches, reachable by subpoena, and, uncomfortably, an asset if the company is ever sold. The fourth is 'de-identified' resale, aggregated logs licensed as a dataset, where 'de-identified' does a lot less than the word implies for data as patterned as yours.

The privacy decision is an architecture decision

Follow the four patterns to their root and they share one cause: the data was designed to leave. Once you accept that, the fix stops being behavioral and starts being structural. You cannot toggle your way out of a pipe that was built into the foundation.

Which flips the whole evaluation. The right question about a migraine app is not "what does the policy promise" but "where does my timeline physically live, and who else can reach the copy." If the answer is a server the vendor operates, every promise depends on that vendor's competence, solvency, and future owners. If the answer is that it never leaves your control, the promise is enforced by the architecture whether the company keeps its word or not.

Built to hold nothing

Postdrome was built on a deliberately boring choice: your timeline lives in your own iCloud, not on a server we run. There is no Postdrome database of your auras to breach, subpoena, or fold into a sale, because we never hold the copy in the first place. When you export, you export your own file, on your own terms.

That design costs us the things the four patterns pay for. We don't get a warehouse of symptom data to mine, and we don't get advertising signals to sell, because there is no back-office pile of your worst nights to reach into. For a condition where the data maps something this intimate, residual photophobia at 2am, the medication you reached for, the days you lost, that absence is the point. The safest data is the copy nobody else is holding.

What we're watching next

The pressure on this pattern is building from the regulator side, not the app side. Health Breach Notification enforcement is widening, state privacy laws increasingly name health and biometric data as a protected category, and 'de-identified' is finally getting scrutinized for how re-identifiable rich behavioral data really is. We'll keep tracking those as they land, in plain English, because the patient impact is usually buried three PDFs deep. If a policy change actually shifts where your data can go, that's the kind of news worth the interruption.