An Anonymous Tip Said My Privacy Policy Was Lying. It Was

Does your privacy policy contain a sentence that asserts something about a third-party processor? If it does, is the basis for that sentence a contract you signed, or an impression that it probably works that way?

Mine was the impression. And it had been live for more than three months.

An email with no name

An email arrived one morning from an anonymous alias. No real name, no organisation, no signature. Not a regulator, not a store, not a user. No demand, no deadline, and it closed with "if all of this has already been handled, feel free to disregard this message."

Inside were eleven EU regulatory concerns about one of my apps — a skin-reaction diary. Medical device qualification, GDPR Article 9, EU representative, DPIA, DSA trader status.

The usual reaction to mail like this is one of two things: ignore it, or panic. I picked a third: check every quote against the actual files.

The result was striking. Every sentence the email quoted existed in my live policy and store listing, character for character. "Eczema & Acne Trigger Diary", "Flara is not a medical device", the 0–100 skin score, the 30-day heatmap — all verbatim.

So this person had genuinely read it. Which meant the claims deserved the same treatment.

Nine of the eleven could not be closed

Honestly, most of it wasn't something I could fix with wording.

Medical device qualification is a professional judgement. Whether a DPIA was done, whether an EU representative was appointed, which transfer mechanism applies to each US processor — those aren't things I "check and correct." They either happened or they didn't. If they didn't, they didn't.

So I focused on the two that were concrete. Those two hurt.

The first: "processed and discarded"

My policy said this:

Each request is processed and discarded; Anthropic does not retain your data beyond the request.

The processor table said the same thing: Deleted after each request.

The problem is that it isn't true. The default retention on the commercial API is not "discarded after the request" — it's deletion within 30 days. Immediate discard only holds if you have a separately approved zero-data-retention agreement. I don't have one.

You don't need to reach for GDPR to see the issue. I had written a promise into a document that I cannot keep. That's just false.

Reconstructing how it got written, there was no bad intent. "Our servers don't store it" was true, and that feeling slid one step outward. The shape of the mistake was taking a fact about my own infrastructure and restating it as an assertion about someone else's.

The second: "anonymized"

The policy and the store listing consistently called the data sent for AI features "anonymized." That's half right.

I opened the code. The builder that constructs the payload includes no email, no name, no account identifier. So far the document matched.

But here is what does go:

skin_condition:       self-reported conditions
recent_reaction_logs: date + symptom severity
food_logs:            date + food name + ingredients
cosmetic_logs:        date + product name + ingredients
weather_logs:         date + temp, humidity, UV
wellness_logs:        date + stress, sleep

Thirty days of dated health records. And the schema looks like this, for every log table:

user_id UUID NOT NULL REFERENCES auth.users ON DELETE CASCADE

Row-level security is user_id = auth.uid(). The source rows are bound to the account, and the generated insight is written back to the account. Re-linkage is structurally available. That is pseudonymised, not anonymous.

Stripping direct identifiers is good data minimisation. It does not make the data anonymous.

The same sentence was in a worse place

I swept the fleet. The same retention wording appeared in four apps' policies — and that's where I found the genuinely uncomfortable one.

Another app (a PCOS tracker) had this bullet on its onboarding consent screen:

Data is used only to generate your response and then discarded

In fourteen languages. And that app transmits the AI chat messages the user types exactly as typed. Not summarised.

A false sentence on a policy page and a false sentence on a consent screen do not weigh the same. The consent screen is the basis on which someone decides "in that case, I agree." If the premise of that decision is wrong, the consent itself wobbles.

What would you do here? Quietly fix the policy page, or go all the way through fourteen translations and an app release?

Three things I learned while fixing it

One. Audit tools produce false positives. I swept the fleet for discard-family words and got five hits. Opening them: Thai for "no more wasting food," Vietnamese for "eliminate trigger foods." All unrelated. Judging compliance by word matching means spending time fixing problems that don't exist.

Two. Correct sentences must be left alone. Four other apps said this:

Anthropic does not retain prompts for model training.

That one is true. "Fixing" it because it looks similar would turn a correct sentence into a wrong one. The bulk-replace temptation was the most dangerous moment in the whole job.

Three. Fixing one place is a performance of fixing. I corrected the policy page first, and the support page on the same site still said "anonymized." The same claim lives in four places — the web policy body, the in-app consent strings (every locale), the store description (every locale), and the platform privacy label. If those four don't follow the same verdict, you contradict yourself.

What it says now

The replacement wording:

Under the standard commercial API terms, request inputs and outputs are deleted within 30 days. This app does not hold a zero-data-retention agreement, so this 30-day window applies.

Plus one line explaining why it isn't anonymous:

Direct identifiers are removed before transmission, but the underlying logs remain associated with your account in our own systems, and the resulting output is written back to your account. It is therefore still personal data.

Longer, and less appealing to read. That's what accurate sounds like.

The honest part

Nine of the eleven are still open. In particular, writing an Article 9 basis into the policy would require an explicit consent step for storing health data to actually exist in the app — and right now only the AI-sharing consent does. Writing a procedure that doesn't exist into a policy would create exactly the same class of false statement I had just deleted. So I didn't write it. That item needs a product change, not wording.

The controller's address, whether an EU representative exists, whether a DPIA was performed — those are facts I don't have, and I won't invent them. Filling compliance documents with plausible-sounding text is worse than leaving them empty.

I also did not reply to the sender. Confirming to an anonymous address whether an MDR assessment exists, or that there is no zero-retention agreement, hands them material. I fixed what was wrong and stayed silent. I'm still not sure that was the right call.

A three-minute self-check

Open your policy right now and check three things.

1. Find any sentence that asserts a third-party processor's retention period. Is the source of that number a document you signed?
2. Find data you described as "anonymized." Does its source table have a user foreign key? If it does, that's pseudonymised.
3. Does the same claim say the same thing in all four places — web policy, in-app copy, store description, platform label?

Number two takes thirty seconds. You only have to look at a schema. Those thirty seconds were three months late for me.

If number one caught something, I'd like to hear whether you remember when and why you wrote it that way — in my case it wasn't malice, it was a slide, and that's exactly why it survived so long.