Made to be trusted with a life.

Our promise

Told exists to keep the voice and words of someone you love. That only works if you can hand us the tender parts of a life — grief, family, the things rarely said aloud — and trust that they'll be held carefully. So security here isn't a compliance checkbox bolted on at the end; it's the design brief.

We treat every story as confidential by default. We minimise who and what touches it, we encrypt it, and we give you the controls to take it back whenever you want. The sections below describe what we actually do today — not aspirations.

Your story is never used to train AI

This is the line we will not cross. The memories, answers, recordings, and drafted prose you create in Told are never used to train our systems, and are never contributed to training a third-party model.

Told uses AI to do a specific job — to interview gently, to organise answers into chapters, and to shape them into readable prose in the teller's own voice. The AI providers we use process your content only to return that result to you, under commercial API terms that prohibit training on your content. Your family's story is a keepsake, not a dataset, and we've made choices at every layer to keep it that way.

Encryption at rest and in transit

In transit

Every connection to Told is served over HTTPS. We send Strict-Transport-Security (HSTS) so browsers refuse to talk to us over an unencrypted connection, closing the door on SSL-stripping attacks.

At rest

On our servers, the sensitive parts of your story are encrypted before they're written to disk — the raw answers you record and the assembled book (draft bodies and summaries), along with media, audio, and interview text. We use authenticated encryption (Fernet: AES-128-CBC with an HMAC-SHA256 integrity tag).

The encryption key lives separately from the database. A stolen copy of the database file, on its own, is unreadable ciphertext without the key. In production the app refuses to start without an encryption key configured, so we can't accidentally ship a deployment that stores your memories in plain text. (Chapter and topic titles, and your account name and email, are kept readable so the app can list and route them.)

Who can see your story

Your project is scoped to you. Every single request that touches a project, a chapter, a draft, or an answer runs an ownership check on our servers before returning anything. There is no "list everyone's projects" path; there is no shared bucket.

• Owners control everything — structure, drafts, exports, invitations.
• Contributors you invite see only the topics you assign to them, and only their own answers on shared topics — never yours, and never each other's raw interviews.
• When a permission check fails, the app returns a plain "not found," never a "forbidden." That refusal deliberately reveals nothing about whether a given project even exists, so the boundary can't be probed by enumeration.

These rules are enforced in one central place in our code and covered by an automated test suite, so a future change can't quietly loosen them without a test failing.

Accounts & sign-in

• Passwords are never stored. We keep only a one-way Argon2id hash — the modern standard, deliberately slow and memory-hard to resist cracking. We can't see your password, and neither can anyone who steals the database.
• No account-existence leaks. A sign-in attempt for an address that isn't registered does the same amount of work as a real one, so the response timing can't be used to discover who has an account.
• Sessions are revocable. Changing your password, signing out everywhere, or a security-triggered event instantly invalidates every outstanding session token — not just the one on the device in front of you.
• Social sign-in can't be used to hijack an account. A verified Google or Apple identity is required before it can adopt an existing address, and doing so rotates that account's credentials. Someone who merely guessed your email can't claim your story through a social button.
• Brute-force protection. Sign-in and other sensitive endpoints are rate-limited per client, keyed on an IP address our edge network sets and a client can't forge.

Who we rely on

We keep the list of companies that touch your data short and name them plainly. Each processes your content only to provide its part of the service, and none is permitted to train on it.

We don't sell your data, and we don't share it for advertising. The current, authoritative list of subprocessors also lives in our Privacy Policy.

Recordings & audio

When someone answers by recording their voice and uploading it, we transcribe the audio and then immediately delete the uploaded file — it isn't kept on our servers after transcription. What's retained is the text of the answer, which becomes part of the book.

The "voice on every chapter" keepsake — the QR code that plays a chapter back in the teller's own voice — is produced from recordings you deliberately keep for that purpose. You choose what's saved to be heard again.

Export & deletion — you can always leave

• Export everything. From your account you can download a complete, decrypted archive of your account and all your content.
• Delete your account. This removes your account and everything you own. Where you contributed answers inside someone else's shared book, your name is removed rather than the words deleted, so their book survives intact.
• No lock-in. The finished book is yours to keep, edit, print, and publish. There's no lapse that takes it away.

Infrastructure & operations

• Hardened response headers on every page — a Content-Security-Policy that constrains what can run in your browser, plus anti-clickjacking (X-Frame-Options: DENY), X-Content-Type-Options: nosniff, HSTS, and a strict referrer policy.
• Rate limiting on authentication and other sensitive routes, to blunt brute-force and abuse.
• Defence in depth against injected content. Because contributors' answers can flow into a shared book, our print/export path renders text with raw HTML disabled, so one contributor can't smuggle markup into another's document.
• Least-privilege secrets. API keys and the encryption key are supplied to the running app as secrets, never committed to source control, and the encryption key is never stored alongside the data it protects.

Honest limits

Trust is earned by being straight about what a system does and doesn't do. So, plainly:

• What you send to AI providers is processed by them. We choose providers under terms that forbid training on your content, but if some material is so sensitive you'd never want it to leave your own machine, don't put it into any cloud app — including this one.
• Encryption at rest defends the stored data, not a live break-in. It protects against a stolen database; it does not, on its own, protect against an attacker who fully compromises the running server. We reduce that risk with the controls above and by keeping our surface small.
• We're a small, early team. We don't yet carry formal third-party certifications (such as SOC 2). We'd rather tell you exactly what we do than imply a badge we haven't earned. Our security posture is documented and version-controlled, and we harden it continuously.

We publish this page — and keep it honest — precisely because you're trusting us with something irreplaceable.

Report a vulnerability

If you believe you've found a security issue, please tell us privately rather than posting it publicly — email [email protected]. We read these, we act on them, and we'll credit you if you'd like. Please give us a reasonable window to fix an issue before disclosing it.

Questions about how your data is handled? See the Privacy Policy and Terms of Service, or write to [email protected].