Everything we hold, and everything we do not.

This is the complete and binding description of what BlueAI holds about you. The short, plain-language version lives on our privacy page; it exists to be readable, not to be exhaustive. Where the two ever disagree, this document is the one that governs.

It is written to be checkable. Every retention period and every category below matches what the running code actually does, and where something is uncomfortable to admit, it is admitted rather than left out.

To have an account you choose a username. That is the only identifying thing we ask for. There is no email address, no phone number, no real name, and no card on file.

Your password never reaches us. What we store is a random salt, a verifier derived from your password with Argon2id, and your encryption key wrapped twice over: once by your password and once by your recovery key. Both wrappings are useless without something only you have.

Alongside that we keep which plan you are on, when the account was created, and when it was last used.

We also record that you accepted the Terms, the moment you did, and which version you saw. That record exists so that neither of us has to rely on memory.

Everything you type, and every file you attach, is encrypted inside your browser before it is uploaded. We receive ciphertext. The key is derived from your password, and we never receive the key.

What we can see is the shape of the data and not its content: how many threads exist, how large each stored row is, and when it was written.

You can delete a thread or your whole account at any time. You can also set conversations to delete themselves automatically after 24 hours, 7 days, or 30 days, which is off unless you turn it on.

The web server writes one line per request. That line contains a deliberately coarse address, the time, the request line, the response code, the number of bytes, how long the request took, and the page you came from. The address has its last IPv4 section removed, and an IPv6 address is cut back to its leading groups, so the log never contains an address that points at one household or device.

Those files are rotated and deleted after 14 days.

The service also writes ordinary operational output to the system journal, which is capped and kept for 30 days.

Rate limiting and abuse blocking do need the real address, so they hold it in memory only. It is never written to disk and it disappears when the service restarts.

A session cookie keeps you signed in for as long as you keep using the service, or until you sign out.

A draft you have typed but not sent is kept in your own browser's storage so it survives a reload. It is not sent anywhere.

We run no advertising networks and no third-party trackers. There is no external analytics script on this site.

We sell subscriptions. That is the entire business model. We do not sell, share, rent or licence your personal information, your conversations, your usage, or any statistic derived from them, to anyone, in any form, aggregated or otherwise.

Until 11 August 2026 this section described an opt-in programme that turned usage into aggregate statistics for business buyers. That programme has been removed rather than paused: the code that labelled and collected usage is deleted, the endpoints that served buyers are deleted, the background job that built the aggregates is stopped and its unit removed from the server, and every row those tables ever held has been dropped from the database.

There is nothing to opt into and nothing to opt out of, because the collection no longer exists.

Account record: until you delete the account, at which point it is removed rather than flagged.

Encrypted conversations and files: until you delete them, or automatically after 24 hours, 7 days, or 30 days if you have chosen that.

Session: up to a year, pushed forward by each visit, or until you sign out.

Web server access logs, holding the coarse address described above: 14 days.

System journal: 30 days.

Encrypted database backups: 14 days, then overwritten.

Terms acceptance records: kept while the account exists, because they are the evidence of what you chose.

A model provider. To answer you, the text of that one request has to be readable by the model that answers it. This is the single point where encryption stops, and it is the most important sentence in this document. Today no provider is connected and chat is unavailable for that reason; before the first live request we will name the provider on our subprocessors page and require in writing that it neither retains nor trains on what is sent.

A hosting provider, which runs the server and the network it sits on. It can see encrypted traffic and disk, not your keys.

Nobody else. We do not share your information with advertisers, data brokers, or partners.

This section applies to California residents and is written to the categories used by the CCPA as amended by the CPRA.

Categories collected in the last 12 months: identifiers, being the username you chose and a coarse address in server logs; commercial information, being your plan and payment history; and internet or network activity, being page paths and request metadata. We draw no inferences about you.

Categories we do not collect at all: government identifiers, driver's licence or passport numbers, financial account numbers, precise geolocation, biometric information, race, religion, health, sexual orientation, union membership, and the contents of mail or messages sent through other services.

Business and commercial purposes: providing the service, keeping accounts secure, taking payment, and meeting legal obligations.

Recipients: the categories listed in section 8. Retention: the periods listed in section 7.

We do not sell or share personal information, and we do not use or disclose sensitive personal information for inferring characteristics about you. We sell nothing derived from you at all: not personal information, not deidentified information, not aggregates.

Your rights: to know what we hold and to receive a copy, to have it deleted, to have it corrected, to opt out of any sale or sharing, to limit the use of sensitive personal information, and not to be treated worse for exercising any of them. We offer no financial incentive for your data, so using the service costs the same either way.

How to exercise them: use data settings inside the app, which needs no email address and no request form, or write to [email protected]. Both channels work equally. Because a username is the only identifier we hold, verifying a request usually means signing in.

An authorised agent may act for you with your written permission.

Global Privacy Control is honoured automatically. Because we neither sell nor share personal information, the signal has nothing to switch off, and we answer it with a header confirming that rather than quietly ignoring it.

The law makes any sale of personal information opt-in only for anyone under 16. We do not sell personal information about anyone, at any age.

We are far below the thresholds that trigger the Virginia, Colorado, Connecticut and similar statutes, and we honour the same rights anyway, through the same two channels, because building two standards of treatment would be worse than pointless.

Nevada residents may direct us not to sell covered information. We sell none, so that direction is already satisfied.

Washington's My Health My Data Act has no size threshold. We do not infer health information, and we have no buyers of any kind.

Encryption is the strongest thing we do, and it is not everything. Being honest about the gaps is worth more than a stronger-sounding promise.

The fact that you have an account and use it is visible to us. Encryption hides content, not existence.

The coarse address, the timestamps, the sizes, and the timing of your requests are visible in server logs for the periods in section 7. Someone watching those could tell that a particular device was active at a particular time.

The text of a request is readable by the model provider at the moment it is answered, as described in section 8. It is not readable by us, and it is not stored by us, but it is not secret from the provider.

The code that does the encrypting is served by our servers. A dishonest operator, or anyone who compromised them, could serve modified code to one person. We publish a warrant canary and we are working towards builds you can verify independently, because the honest answer today is that you are trusting us not to do that.

If you lose both your password and your recovery key, your conversations are unrecoverable. That is the cost of us not holding the key, and there is no support process that can undo it.

Passwords are stretched with Argon2id before they are ever used, and your encryption key is stored only in wrapped form.

Traffic is TLS-only with strict transport security, and the browser is given a restrictive content security policy.

Sign-in, recovery, and the API are rate limited, the service runs with a hardened, restricted system profile, and the database is backed up daily in encrypted form with a restore drill that has to pass.

If we are compelled to hand something over, this is the complete list of what exists on our side: the account row described in section 2, ciphertext we cannot decrypt, coarse logs for up to 14 days, and payment records.

We cannot produce the plaintext of your conversations, because we do not have the key. That is a design decision, not a policy we could quietly change without changing the code you can inspect.

Our warrant canary is published and updated on its own page.

This document is versioned and dated. If we change something that materially affects you, we will say so in the app rather than editing the page quietly and hoping nobody reads it.