End-to-end encrypted

We built it so we can't read your cycle.

Your entries start on your device. If you turn on sync, they're end-to-end encrypted with a key only you hold before they ever leave your phone — so we can't read them, can't sell them, and have nothing readable to hand over if someone asks. Here's exactly how, including what we can still see. A privacy page that hides its limits isn't one.

Applies to RhythmHer & RhythmHer Partner · September 2026

Pending legal review. This page describes verified product behavior and code. It sits alongside — and does not replace — the full Privacy Policy.

Local-first, then locked

Your data doesn't leave unless you send it.

Core tracking works with no account and never leaves the device. Everything beyond that is opt-in — and encrypted when it is.

On device

Tracking, by default

Periods, symptoms, mood, notes and reminders are written to your phone first. No account required to use the app.

Off until you enable it

Encrypted sync

Turn on an account and your entries are encrypted on-device, then stored only as scrambled text. We hold the ciphertext, never the key.

Your choice

Partner sharing

Pair with a partner and they see only the one summary you approve. Your raw entries never cross that line.

Always

No trackers in the app

Zero analytics, advertising or tracking SDKs. There is no profile on you to leak.

The honest ledger

What we can & can't see.

"Can't see" is the whole point of the design. "Can see" is what we won't pretend away.

What we can see

Your account emailOnly if you create an account — so you can sign in and recover it.
That an account exists & when it last syncedTimestamps, not contents.
The type and count of records you syncThat a "cycle" or "symptom" entry exists — never what it says.
A device notification tokenOnly if you turn on partner alerts, via Apple/Google push.
Your subscription statusHandled by Apple; we never see card details.

What we can't see

The contents of any cycle, symptom, mood or noteEncrypted on your phone before it's ever uploaded.
Your password or recovery keyNeither ever reaches our servers.
Anything we could decrypt and hand overNot for an advertiser, not for a legal request — we don't hold the key.
What you share with a partner, beyond the approved summaryRaw entries never cross the boundary.
You, anywhere elseThe app runs no analytics, ad or tracking code.

Plain terms

How the encryption actually works.

Three steps, all on your device.

Your phone locks the entry first

The moment you save, your phone scrambles the entry with a 256-bit key. Only the scrambled text is uploaded — the readable version never leaves the device.

Your key is sealed by things only you know

That key is itself locked by your password and a one-time recovery key — neither of which is ever sent to us. So the key that opens your data can't be rebuilt on our side.

A new phone unlocks it — we never do

Because your key is sealed under both your password and your recovery key, either one restores your data on a new device. We only ever store the sealed key and the scrambled text.

The boundaries that make it true

What we simply don't do.

Privacy isn't a setting you dig for — it's the shape of the whole app. These aren't toggles; there's no code path for them.

×Read your cycle or symptom entries

×Sell or share personal data

×Run analytics, ads or tracking SDKs in the app

×Share raw entries with a partner

×Hold a key that could decrypt your data

×Build a profile on you across apps or the web

Your controls

Take it, or erase it — anytime.

Export

Your data, out

Create a PDF summary or a full export from the app whenever you want.

Delete

Gone for good

Delete your account to erase its encrypted contents. Remove local entries on the device separately.

Lock

Face ID gate

The app sits behind your device's biometric lock, so a borrowed phone doesn't open your history.

Straight with you

What we won't pretend.

Your email and the fact that you have an account live on our server. End-to-end encryption protects your entries, not the existence of the account.
If you lose both your password and recovery key, we cannot restore your encrypted data. That's the unavoidable cost of a design where only you hold the key — and it's also why no one can compel it out of us.
No app can protect data after it's decrypted on a screen someone else can see. On-device security is yours to keep.
An independent security review of our encryption is in progress — we'll publish the result here. Until then, these claims describe our design and code, not yet a third party's audit of it.

Technical details, for the skeptics

Record encryption: AES-256-GCM — 96-bit nonce, 128-bit authentication tag. Every synced record crosses the wire already encrypted.
Key derivation: PBKDF2-HMAC-SHA256, 150,000 iterations, 256-bit output — run on-device from your password and, separately, your recovery key.
Key model: A random 256-bit Data Encryption Key encrypts your records. It's envelope-wrapped under a password-derived key and a recovery-key-derived key, so either unlocks a new device. The server stores only wrapped keys, public salts and ciphertext — never the password, recovery key or Data Key.
Server boundary: The database is row-level-security isolated per account. Everything crossing the boundary is ciphertext or a public salt.
Partner boundary: A paired partner receives only the single owner-approved summary string and its timestamp. No raw records are ever transmitted.
Third-party code: No analytics, advertising, crash-reporting or tracking SDKs in the app. Dependencies are infrastructure only: encrypted store + auth, platform payments, push delivery.
Report an issue: Security contact and disclosure details at /.well-known/security.txt.

Reviewing our privacy?

Security researchers and reviewers — write to us. We'll answer specifics and share what you need.

[email protected]