Sealed from the start

Your data. Your key. Your call.

We built the architecture around one constraint: we should not be able to read your life even if we wanted to, even if we were bought, even if someone compelled us. Everything below is written to be checked, and nothing has shipped yet: each technical claim carries a tag saying whether it exists as prototype code or as a plan.

Only your device and an attested enclave ever see your data in the clear. We cannot read it, keep it, or hand it over.

This is the strongest claim we can honestly make. We make no other.

01

Why this matters more here than almost anywhere

The substance of your conversations, a photo library full of private moments, where you went and how you slept. This is not data that should sit readable on someone else's server. A normal cloud app could never responsibly ask for it. We designed around that before writing a line of product code, which is the only reason we can work with material this intimate at all.

02

In plain language

Your phone already encrypts everything it stores. We add a second lock on top, and the app itself sits behind Face ID or your passcode. Opening your phone is not the same as opening your life.

Your device seals everything before it goes anywhere, the way you seal a letter before posting it. We handle the envelope; we cannot open it, because the key never leaves your phone.

Even the part of the app that collects your data cannot read it. It works through the night with an envelope it cannot open; only the app, once you unlock it, holds the key.

When you ask for something that needs real computing power, a copy of just that data is unsealed inside a dedicated, hardware-protected enclave. It lives there for seconds, in memory, and is never written to disk. We see an envelope go out and an envelope come back. We do not see what is inside.

03

For the technically curious

Storage: one random key, sealed twice. prototype Your device generates a random 256-bit master key, encrypts the database with it, and keeps it in the hardware keystore: Keychain on iOS, Keystore on Android. Your password and your recovery phrase each wrap a separate copy of that key, which is what lets you restore on a new device. We never see any of the three, so there is no server-side key to steal or subpoena. It is the envelope model WhatsApp, Bitwarden and iCloud Advanced Data Protection all use.

One limit, stated plainly. The database key becomes available after the first unlock following a restart. A powered-off phone is sealed. A running, unlocked phone is a running, unlocked phone. No encryption design changes that.

Collection: separated from reading. prototype A background worker holds only your source credentials. It seals everything it fetches to a key it does not possess; the key that opens the seal sits in the main app behind your unlock. The part of our system that runs most often is the part that can read the least.

Backups: your cloud, not ours. planned Your device encrypts backups before they leave, and they land in your own iCloud or Google Drive with the wrapped key copies alongside. Your password or recovery phrase is enough to restore. We hold no key to any of it, which also means we cannot recover a backup for you if you lose both. That is not a gap; that is the design.

Processing: attested secure enclave. planned Heavier AI will run in an EU-hosted trusted execution environment whose state your device cryptographically verifies before sending anything. Plaintext exists there for seconds, in memory, never on our disks. Before launch we intend to publish the shell that handles input and output and have an external audit confirm the published code is the running code. Until that audit exists, read this paragraph as a commitment rather than a proof.

Training: only if you donate it. planned Models train on anonymous features, never raw personal text, and even that requires you to actively offer it. Nothing is used for training by default, and nothing is ever sold or used for advertising.

04

What we will not claim

Overclaiming would be both dishonest and, under European consumer law, illegal, so here are the lines we hold. We do not call your data anonymous. We do not claim we stop being a data controller just because we cannot read it; being unable to read something does not remove responsibility for it. We do not say the GDPR somehow does not apply to us. Account metadata, meaning your email and device identifiers, is ordinary personal data that we do hold and are accountable for.

05

Other people in your data

Your messages and photos contain people who never signed up for anything. We take that seriously and we constrain the product because of it: we never run facial recognition, and we never analyse what someone wrote to you to draw conclusions about them, their mood, or their life. What the app remembers about the people around you is always your side of the story: who you spent a day with, who you had not called in a while. It describes your relationships, never the other person, and like everything else it stays sealed on your device. Nothing about anyone is combined across users in the background; there is no mechanism for it. If we ever build sharing, it will mean you deliberately showing a piece of your own timeline to someone you choose, never our systems joining what two people know about a third.

06

What is built, and what is not

This is our target architecture, and parts of it are still in active development. The tags above say where each layer really stands, we move a tag only when the work is done, and we will not claim we have achieved something until we have. The thinking behind that habit is written down in our values.

Living document · updated as we build

Looking for the legal one? The privacy notice for this website, under Art. 13 GDPR, is here.

UnderstandUrself is a well-being and self-reflection tool. It is not a medical device and does not diagnose, treat, predict or provide early warning of any condition. If you are struggling, please speak to a qualified professional.