What protects what

Encryption

Traffic to this site is served over HTTPS, and the site asks browsers to refuse an unencrypted connection to it in future. Every page carries a content security policy that is enforced rather than merely reported, and every write that relies on a cookie is checked against the origin it came from.

Encrypting the disk would not be the thing that protects what you write here. That is the next section, and it is the one that matters — encryption at the volume level answers a stolen machine and does nothing against a backup file, a replica, or a database credential that has been copied.

Application-layer encryption

Everything you write is encrypted by the application before it reaches the database: AES-256-GCM, a fresh random initialisation vector for every record, and a subkey derived per column purpose. The purpose is bound into the encryption, so a value cannot be moved from one column into another and still open.

The key depends on who the content belongs to. What you kept to yourself is sealed under a key belonging to your account; what you deliberately shared into a space is sealed under that space’s key. Each of those keys is itself stored only in wrapped form, encrypted under a master key held in the environment rather than in the database, so a copy of the database alone yields sealed text and wrapped keys and nothing that opens them.

This is not end-to-end encryption and is never described as such. The server unwraps keys in memory in order to show you your own writing and to assemble the context the AI features need, so it can read what passes through it. Making that untrue would remove every feature this product has. The claims we do make are that a stolen database yields nothing readable, that deletion is irreversible, and that one account’s compromise is not every account’s.

Longer: how the privacy model works.

Data retention

Some records age out on a schedule. The windows are operator settings, and these are the ones in force as this page was served:

• Product analytics events: 365 days.
• Notifications, once delivered or failed: 90 days.
• Sessions that have ended: 30 days.
• Audit entries for privileged actions: 730 days, and never fewer than 90, because a log that can be shortened to nothing is not a log.
• A safety excerpt: until the case it belongs to is closed, then it is destroyed.
• A voice recording: until it has been transcribed, unless you asked for it to be kept.

Nothing on that list is something you wrote. What you write — entries, check-ins, the messages in a joint session — has no expiry today. It stays until you delete it or delete your account, and no schedule an operator sets touches it.

Planned, not done: a decision has been taken to stop keeping ordinary conversation content by default, and it is being applied in increments. Two of those have shipped — a conversation with your guide is no longer written down at all, and the memory the guide used to keep between sessions has been removed. The journal, check-ins, joint sessions, imports, debriefs, parked issues and shared goals are all still stored today, and will be until each increment lands. Nothing has been bulk-deleted as part of it.

Backups

The database is backed up daily. Each run writes the dump and then reads the whole file back to check it can be restored, so a truncated or corrupt backup is caught when it is taken rather than discovered when it is needed. Old dumps are pruned; the deletion page states how long a copy can persist.

The encryption key is not in the backup. Restoring one without the key gives an intact database of unreadable noise. Each backup records only a fingerprint of the key — enough to tell whether the key being held is the right one, and useless to anybody who takes the file. This is what makes deletion reach a copy taken last night: destroying a key makes every sealed row it ever produced unreadable in every copy that exists, at once.

One exception, stated because every other line here is about sealing and somebody skimming would assume this one was too: the audio of a voice recording is stored as it was captured and is not encrypted. What protects it is that it usually does not exist for long, and that the transcript derived from it is sealed and dies with the key.

Longer: what deletion covers.

Account deletion

Deletion is asked for inside the product rather than by emailing us. Nothing is touched for 30 days and you can cancel for the whole of that time. After that it is carried out and it cannot be undone — not by you, and not by us.

It destroys the key before it deletes any rows, deliberately: if the job dies half-way, what is left is unreadable sealed text rather than readable content waiting for a retry. 88 places in this system identify a person, and every one of them has a written decision about what forgetting you means for it. A test asks the database which of those places exist and fails the build if any is missing a decision, so a new one cannot be added without somebody saying what happens to it.

Some of it is left rather than destroyed, and the reason is always the same: a message in a shared session is one side of a conversation the other person was also in, so the authorship goes and the words stay under the space’s key. You can ask for those to be destroyed too, and the choice is on the deletion screen.

Longer: what deletion covers, which lists every one of those 88 decisions in the software’s own words.

AI providers

One model provider, OpenAI, and it receives the text of the prompt that was assembled for a request. There is no second inference vendor and no route in this product that can reach one. The endpoint used is stateless: nothing is stored with the provider between requests — no threads, no uploaded files, no vector stores, no assistants.

What may be in a request is decided before anything is sent. Context is assembled into typed buckets and sealed with an audience, and a request whose output another member can see is permitted exactly one bucket: material that was deliberately shared. Your private and never shared writing is not filtered out of such a request — it is never loaded into the process that builds it, so there is nothing in it for a model to reveal, be tricked into revealing, or allude to. The check runs before the network call and throws rather than quietly correcting itself.

Every call is recorded with its provider, model, token counts and cost, which is how usage is metered. Those records hold no words of what was said.

Longer: AI disclosure · what you are charged for.

Transcription providers

Speech-to-text goes to the same provider as inference, and the audio of a voice note is uploaded for it. The recording is discarded once it has been transcribed unless you chose to keep it; the transcript is sealed under your key like anything else you wrote.

Where no provider is configured, nothing is transcribed and the product says voice is unavailable. There is deliberately no fallback that invents plausible words: a fabricated transcript would put sentences in somebody’s mouth and then store them as their own account of an argument.

Whether transcription is running, and who receives the audio, is stated live on the subprocessors page.

Payments

Stripe is the payment processor, and it is the only one — there is no second processor to select and no code path that could reach one. It receives your email address, an account identifier and the plan you chose. Card details go to Stripe directly and never reach our servers.

Every message Stripe sends back is signature-checked before it is believed, and the processor is the record of what was paid: an invoice exists in our database because Stripe said it does, never because we decided a payment probably worked.

After an account is deleted, an anonymous billing record remains — amounts and dates, with no name and no email address — because we are required to keep one.

Longer: what you are charged for · the plans.

Email provider

Email carries sign-in links and the account messages you asked for. A notification carries no relationship content unless you have switched that on, and content you marked never shared is excluded from a notification preview by default.

We do not publish the name of the mail provider on this site. If you need it for a data-protection assessment, ask at privacy@onbetterterms.com.

Authentication

Three ways in, and no third party in any of them: a link sent to your email address, a password, or a passkey. There is no “continue with” button here, and no company learns that you have an account with OnBetterTerms because you signed in to it.

• Sign-in links, invitations and sessions are stored only as hashes, so reading one out of a database disclosure does not turn it into access. A sign-in link is single-use and short-lived.
• A passkey never leaves your device, so not even we receive it. You can remove one from the account from anywhere you can still sign in, without being asked to prove another way in remains — somebody removing a passkey from a device they have lost is doing the right thing under pressure.
• Repeated failed sign-ins are throttled with a lockout that lengthens, and the account holder is alerted when a sign-in arrives from a country it has not seen before.

Nobody here can reset a member account’s credentials, and there are no printable recovery codes. If the email address, the password and the passkey are all lost, the account is lost with them. That is a deliberate decision — a support route into an account is a way past every other control on this page — and it is stated here rather than discovered at the worst possible moment.

Session management

A session is an opaque random token, and only its hash is stored, so a database disclosure yields no usable session. There is deliberately no signed token that carries its own authority: a signed token cannot be withdrawn before it expires, and “sign this device out now” has to mean now — which matters most for somebody whose device may be in the hands of a person they are trying to get away from.

A session lasts 30 days and is extended while it is being used. Every session is listed in your account and each can be revoked on its own. A session that has ended is deleted 30 days later.

Audit logs

Every privileged action by staff is written to an audit log: a setting changed, a role granted, a safety record opened, a second factor removed. Reading the audit log is itself an audited action.

An audit entry records an action, an actor, a subject and a time, and never content. That is enforced rather than asserted: every write passes through a check that withholds any value shaped like prose and records that it did so, so a careless caller cannot put a sentence somebody wrote into this table. Entries are kept for 730 days, with a floor of 90 days that an operator cannot go below.

Safety-review access

No staff role in this system has permission to read relationship content. There is no such permission to grant, and there is no “view as this member” mode. The safety queue is the single exception, and it is reachable only by the safety-reviewer and platform-administrator roles.

• Only the two most serious assessments reach the queue at all. Seeing that a case exists is not reading it: the queue shows the assessment and never the writing.
• Opening an excerpt is a separate, deliberate step, and each one is recorded individually before the content is decrypted, so who read what and when is answerable afterwards.
• The excerpt is destroyed when the case is closed. The decision survives; the words do not, so no archive of people’s worst moments is ever built.
• The other member of your space is never told a safety concern was raised — no notification, no activity signal, no visible change.

The limits are as important as the controls: nothing here contacts emergency services, nobody is watching in real time, and detection is not guaranteed in either direction.

One honest residual risk, because a page like this is where it would be easiest to leave it out: staff holding both the database and the master key can read what is in it. The controls above make such access recorded and accountable; they do not make it impossible, and a product that assembles AI context on a server cannot claim otherwise.

Longer: safety policy · what we can and cannot do.

Subprocessors

Every company that can process data on our behalf is listed individually, with what it receives, whether it is required, and where it runs. That list is not written by hand: each entry’s status is read from the same configuration the server uses, so it describes what is happening rather than what was intended, and a vendor appears on it only because there is code here that sends data to it.

The hosting provider and region are not published. If you need them for a due-diligence or data-protection assessment, ask at privacy@onbetterterms.com.

The list: subprocessors.

Incident response

Vulnerability reports go to security@onbetterterms.com, and there is a machine-readable pointer at /.well-known/security.txt. We aim to acknowledge a report within three working days and to say what we intend to do about it, including when we think it is not a problem and why.

If a flaw exposed member data, we will say so publicly — including when it would have been easier not to. Anything affecting the privacy of one member from another is treated as the most serious class of bug this product has.

There is no paid bounty programme. We would rather say that plainly than imply one.

Longer: security and vulnerability disclosure.

Data export

You can take an export of everything from your account at any time, including before you delete it. It contains everything you wrote at every level — the never shared entries included — and what other people deliberately shared into your spaces.

It is built from the same viewer-scoped reads the screens use, never from a fresh query that selects everything belonging to an account, so it cannot contain anything the screens would not show you. It is generated on demand, streamed to an authenticated request, and never written to storage, never queued, and never given a link that could be fetched by anybody who found it.

Legal requests

Marking something never shared means it is private from the other person in your space, and that does not change. It is not a claim of immunity from lawful process, and the product says so before you first choose the level rather than in a clause nobody reads.

What a demand served on us would reach is limited by the same thing everything else on this page is limited by: content is sealed under keys belonging to accounts and spaces, and an account that has been deleted no longer has a key to unwrap.

The legal entity behind this service, its postal address and the governing law are not yet published. They are real facts about a real business and we do not print a placeholder in their place, so the legal pages render without them until there is something true to write. If you need one of them for an assessment, ask at privacy@onbetterterms.com.

Related: terms · privacy policy.

AI training and data use

Your content is not used to train models — not ours, and not the provider’s. That is what we require of every provider on the subprocessors list, and it is stated in the AI disclosure as well as here.

The prompts assembled for a model call carry no names and no email addresses. Product analytics record that an action happened and never what it said, and the event schema is declared, so a careless caller cannot smuggle text into the analytics store. There is no advertising network, no analytics vendor that profiles you across the web, and no data broker.

A conversation with your guide is not written down at all: it lives only while it is open, nothing is extracted from it to carry into the next one, and there is no stored list of conclusions about you, because none is kept.

Longer: AI disclosure · how the privacy model works.