Transparency

Access table

Who can read what, in plain language. “Health data” means food logs, workouts, sleep, body measurements, blood work — everything you encrypt as part of the normal flow.

What we still see, even at the strongest setting

Even with the recovery-phrase setting — the strongest one, where we hold no key to your data — syncing your encrypted records between devices means our servers still see a few plain facts. They never see what's inside your records:

• That you have records, which kinds (for example, a workout or a sleep entry), and when they last synced — never their contents.
• The public profile you choose to share — your username, display name, and avatar.
• The account essentials we need to run your account — your email, your billing identity (handled by Stripe), and a few non-sensitive app and workout-planning preferences.
• Recipes you create or save — their names, ingredients, and instructions — since recipes are built to be shared and we calculate their nutrition for you. Your food logs and meals stay scrambled.
• Anything you send our support team. When you write to support, someone on our team can read your message — that's what makes an answer possible — and the same goes for any of your data you choose to attach to a ticket. Your messages themselves are encrypted to keys held only on our support team's own devices, so a breach of our database would not expose them. Attachments are the exception: those we hold in readable form until you take them back.

Everything else you log stays scrambled to us.

When you write to support

Support is the one place in Sovei where a human on our side reads what you wrote. That is the point of it — nobody can answer a question they can't see. So it works differently from everything else here, and we'd rather you knew that before you typed than after.

• Our support team can read your messages — the details you write, and any replies. What they cannot do is read them from our database. Support messages are end-to-end encrypted between you and our support team, and the keys that open them are derived on each staff member’s own device from their own credentials. We do not hold a copy. Somebody who stole our entire database would get nothing readable out of it.
• You can see when support opened a conversation. Every time a staff member opens one of your support conversations, it's recorded in your own privacy log under Settings → Privacy. We log the moment we hand the conversation over, because the reading itself happens on their device where we can't observe it.
• Only current staff can read new messages. When someone leaves, we take their access away — but we'll be straight about what that does and doesn't mean: it stops them reading anything from that point on. It cannot un-read what they already read.
• Attaching data is a separate, deliberate choice. Nothing you log is attached to a ticket unless you attach it. When you do, support can read that data until you revoke it — and it expires on its own after 7 days. Unlike your messages, attachments are stored in readable form, so attach only what the problem needs. Every time someone on our team opens what you attached, that lands in the same privacy log, along with how many of your items they were shown.
• When support asks for your data, their reason is not encrypted. A staff member has to write down why they need what they're asking for, and you see that sentence before you answer. Unlike your own messages, we hold their words in readable form. The request opens nothing on its own — saying yes records your answer, and the data still moves only when you attach it.
• Your encrypted records are not opened by this. Writing to support doesn't give anyone a key to your food logs, workouts, or lab results. It gives them the message you sent.

The practical version: tell support what they need to help you, and no more. If a problem can be described without pasting your health data into it, describe it.

How the spare key is protected

The spare key is encrypted with industry-standard AES-256-GCM and held in a managed key vault, separate from the records it protects. It's never written to logs, error reports, or disk in plaintext.

What we audit

Every time the spare key is created, used, or removed, we log: an anonymous user ID, outcome, timestamp, and the strength of the calling session's authentication. The decrypted key itself is never logged.

We retain these audit records for 6 years, in line with healthcare data retention norms.

What you can switch

You can switch between modes at any time without losing data. Both directions are instant — we re-wrap your key, the underlying data isn't re-encrypted.

• Phrase → Easy Recovery: we store a wrapped copy of your key. Phrase still works.
• Easy Recovery → Phrase: you type your phrase to confirm you have it, we delete the wrapped copy. From then on, only the phrase unlocks your data.

The toggle lives at Settings → Account → Easy Recovery.

Two-factor authentication

Easy Recovery is designed to require two-factor authentication. When it's enabled, you'll set up a code from an authenticator app (Google Authenticator, 1Password, Authy — anything that speaks the standard 6-digit format) before we wrap your spare key, and you'll be asked for a fresh code on every new device, so a stolen password alone can't reach your data.

New-device protections

Every new browser or device that uses Easy Recovery has to pass an email confirmation step before we'll unlock your data there. The first time we see a device, we email a one-click confirm link to the address on your account. Until you click it, the unlock is paused — your data stays encrypted on that device.

You can review the last ten Easy Recovery unlocks at Settings → Account → Easy Recovery. Each entry shows when the unlock happened and whether it came from a trusted device or a new one.

What we don't do

• We don't support hardware security keys (YubiKey, passkey-only) yet — authenticator apps are the only second-factor option for now.
• We don't support customer-managed encryption keys for partner organisations yet.