Is it safe to track your cycle in an app

The short answer

It depends on one thing — where the key is kept. If an app encrypts your entries with a key it holds itself, "encrypted" means only "encrypted against an outsider", not against the app. If the key stays on your phone, nobody can read the entries — including the people who built the app.

Those are two different things, and the word "encryption" hides the difference between them. What follows is how to see that difference for yourself, in any app, not only in ours.

Why "we encrypt your data" is not an answer

Almost every app encrypts something today, and technically none of them is lying. But one word covers three different things, and only the third guarantees anything.

• Transport encryption. Data is protected while it travels from your phone to the server. That is HTTPS, and every website has it, including a shoe shop. On the server the data is in the clear again.
• Encryption at rest. The disk or the database is encrypted, but the key belongs to whoever owns the server. This protects you against somebody carrying a disk out of a data centre. It protects you against the app's owner not at all.
• End-to-end encryption. Data is encrypted on your device with a key the app does not have. Ciphertext is what reaches the server, and the server's owner cannot open it even when they very much want to.

The first two are technical hygiene. The third is a property that a promise cannot revoke.

Three things that can actually happen

Cycle entries are health data. The risk here is not abstract, and it comes in three shapes.

• Access from the inside. If the key sits with the app, anyone with access to the database can technically read the entries. "We don't read them" is a promise, not a mechanism.
• A breach. A database that can be read from the inside can also be read by whoever got in without permission. The number of health-data leaks each year is not a hypothesis.
• A change of owner or of rules. A policy can be rewritten at any time: apps get sold, companies get bought, jurisdictions change. A mechanism cannot be rewritten — if the key does not exist, it still does not exist after the sale.

The third point is the most important and the least obvious. A privacy policy is an intention held today. Architecture is what will still be true tomorrow.

The question worth asking

Not "do you encrypt data" — everyone answers yes to that. There is one question: where is the key kept?

And two follow-ups:

• What exactly is encrypted — everything, or only part of it?
• What is visible on the server in the clear?

If there is no answer to the second, that is an answer already. An app that understands its own architecture can list the fields. An app that would rather not usually has something to hide — not from an attacker, but from you.

How Kvit does it

On the phone. The local database is encrypted in full. A 256-bit key is held in the system's secure storage — Keychain on iOS, Keystore on Android — and never leaves the device. It is the same store the operating system uses for passwords and for other apps' keys — the most protected place it offers an app at all.

In the cloud. The cloud copy is optional: the app works completely without it. If you turn it on, an entry is encrypted on the phone itself (AES-256-GCM) and only then uploaded. What reaches the server is a row shaped like "entry id, your id, ciphertext, time of change".

Where the key to the cloud copy is. Here we are obliged to put this article's own question to ourselves, and to answer it uncomfortably. The local database key is on your phone and is not known to us: entries that never left the device we cannot read. The key to the cloud copy is ours. On the scale above that makes the copy encrypted at rest rather than end-to-end, and it means we have technical access to whatever was uploaded.

We say it plainly, because that is the answer this article asks you to demand of other apps. An app that teaches you to ask "where is the key" does not get to dodge the question itself.

What is nevertheless visible on the server

This is the most important part, and the part usually left out. Visible in the clear:

• the time each entry was last changed;
• how many of them there are;
• whether you have turned on PIN or biometric entry.

Plus one more thing that has to be named: the presence of a file in the journal photo storage reveals the fact that you keep a pregnancy journal. Its contents stay ciphertext.

So the server sees that you are recording something, and when. It does not see what. We say this out loud, because an app claiming that nothing at all is visible on its server either does not understand its own architecture or is describing it inaccurately.

Section 3.2 of the privacy policy describes what sits on the server: an opaque blob in which neither the contents nor even the field names are visible. The metadata above is what surrounds that blob, and we name it here because a policy that stops at "we cannot read it" leaves out the more interesting half.

Who the data goes to

Kvit has no servers of its own, so the providers are named — all five: Supabase (database, storage and authentication; EU, Ireland region), Qonversion (subscription status, no health data), Apple and Google (payment, subscription management and sign-in), Google (Firebase) (technical installation identifiers and notification delivery, when notifications are on) and Cloudflare (hosting for the pages on kvitcare.com — it sees your IP address when you open this site, and nothing from the app).

Naming them is a mechanism too, not a courtesy: once a provider is named, we lose the ability to quietly add another. Who sees exactly what, and how long it lives, is worked through line by line in Who can see your cycle entries.

What this approach costs

There is a price here, and it is better known in advance. It is no longer where it used to be.

You cannot have both properties at once, and that is not a quirk of ours but a property of the problem. Either the app can restore your access — in which case it can technically read your data. Or it can do neither.

Kvit used to choose the second, and you paid for it: there was a recovery code to keep, and the usual ending was not stolen data but a lost code and lost entries. The code is gone. We chose the first and took the key to the cloud copy ourselves.

What follows in practice:

• If you do not want us holding the key, leave the cloud copy off. The app works fully on its own, and then the key exists only on your phone. That option has a stated cost too: lose the phone and you lose the entries.
• With the copy on, changing phones stops being a loss. Sign in on the new one and the entries are there. Nothing to save in advance, nothing to type.
• The decision is not final. The account and the cloud copy are deleted in one action, and what remains is the local entries on the phone.

What happens if you delete your account

Another question worth asking any app in advance, because the answer only ever gets tested once.

In Kvit, deleting the account erases the cloud copy. A deleted entry disappears from the app immediately and is permanently erased from the server within 90 days at the latest — that window exists so the deletion reaches your other devices, not "just in case". You can delete the account without installing the app: there is a page for that.

A checklist for any app

Five questions whose answers should be in a document, not in a store listing:

1. 1.Where is the encryption key stored?
2. 2.What exactly is encrypted, and what is not?
3. 3.What is visible on the server in the clear?
4. 4.Who else receives the data — and are they named individually?
5. 5.What happens to the data if the account is deleted?

A missing answer to any of them is also an answer. And one more check that takes a minute: open the app's privacy policy and search for "advertising partners" or "affiliates". If the list is not named, the list is open-ended.

What Kvit does not have, and what it does

There are no advertising libraries in the app and no advertising, and data is neither sold nor passed to data brokers.

The app does run analytics, and it should be named plainly: Kvit uses Google Analytics to see which screens get used. That measures how the app is used, not what you wrote in it: the entries are encrypted with a key that stays on your phone, so to Google they are an unreadable string.

One more detail worth knowing: a cycle forecast is information for you, not a decision about you. Kvit makes no automated decisions with legal effect concerning you, and the policy says so directly.

What this does not mean

Finally, the limit — because that has to be named too. End-to-end encryption protects data on the server. It does not protect you from someone holding your unlocked phone, and it does not make the app a medical device.

Kvit is a wellness app. It does not diagnose, it does not replace a clinician, and it is not a contraceptive. On how it calculates and where the limits of its forecast are, see How ovulation is actually calculated.