How Chat encryption works

Every conversation is saved only in encrypted form: its title, your messages, the replies, the model's reasoning, its web searches and the pages it read, the code it ran and the output, your attachments, and the files Chat creates. Our database, file storage, and backups hold only that encrypted data, and Abliterant can't read it.

Some information about your conversations isn't encrypted, because Chat needs it to work. We can see:

• When you chat
• How many conversations, messages, and files you have, and their approximate sizes
• The kind of each file: an upload, its extracted text, an image, or a file Chat made
• Which messages are edits or regenerations of others
• Whether a conversation is pinned, archived, or shared, when its share link was created or updated, and whether its title has been made
• Whether a reply failed (blocked, rate-limited, unavailable, or interrupted) or hit the output limit
• Which model answered and how many tokens it used

We keep a record of each reply's model and token use after a conversation is deleted, without any of its content.

Your conversations are locked with a key your browser creates, called the account key. Our servers store it only in a locked form that we can't open. You open it with one of these:

• Your sign-in password, if your account has one. It never leaves your browser. Your browser turns it into two keys: a sign-in key that our server checks when you sign in, and the key that opens your chats, which never reaches us. When you choose the password, only the first 5 characters of its SHA-1 hash leave your browser, to check it against a list of breached passwords. An account made before this design sends, once, at its next sign-in, a slow one-way hash of the password, so our server can switch it over.
• An unlock password, if you sign in only with Google or GitHub. You choose it the first time you open Chat. It needs at least 10 characters, must be hard to guess, and must not appear in a list of breached passwords. For that check, only the first 5 characters of its SHA-1 hash leave your browser. We never receive the unlock password.
• A backup phrase, if you save one. It is optional: 12 words that open your chats if you lose or reset your password. You can create one, or replace it, in Chat's settings. We never receive it.

A new password or backup phrase replaces the old one, but the account key stays the same. For 29 days our backups keep a copy of your account from before the change, and the old password or phrase, together with that copy, still opens the account key and all your chats.

Once your chats are unlocked, the device stays unlocked until you sign out, choose Lock now, or your keys change elsewhere: a new password, a new backup phrase, or Start over. Your browser keeps the account key in its own storage, locked with a key the browser won't let any page export. If you set an unlock password, you can untick “Keep this device unlocked” instead.

To answer you, Chat has to read the conversation. When you send a message, your browser sends our server the key to that one conversation, for that one request. Requests pass through our network provider, Cloudflare, which decrypts TLS at its edge, so it handles your message and the conversation key in transit. Our server uses the key in memory to read the conversation and its files, sends the conversation to the model that answers, saves your message and the reply encrypted, and then forgets the key. Readable copies are never written to our disks, logs, or backups.

When one of our model providers answers, it receives the conversation. Our model providers state that they don't keep prompts or replies. When Chat runs on our own model, our computing provider runs it. Titles are always made by our main model provider, from a conversation's first message and reply. Search queries the model writes go to our search provider, which may keep them for up to 90 days, and pages it opens are fetched from the web. Code the model writes runs, with the files it needs, in an isolated sandbox at our computing provider without internet access. Our computing provider may keep sandbox inputs for up to 7 days.

Depending on which model answers, the model provider or our moderation service may also check prompts and replies for sexual content involving minors.

Staff can't read your conversations, titles, or attachments. There is no staff tool, spare key, or back door that opens them, and we can't reset or recover your keys.

Staff can see the information listed above that isn't encrypted: for example, how many conversations you have, when you were last active, how much storage you use, and when a message was blocked, without its text. Staff can remove a share link without seeing what it shares.

When you create or update a share link, your browser makes a snapshot of the conversation as it is then: its title and messages, the web searches and their sources, the addresses and titles of pages read, the code that ran with its output and the names and sizes of the files it made, and the names of attached files. The snapshot doesn't include the reasoning, file contents, images, or blocked messages, and later messages are added only when you update the link.

Your browser encrypts the snapshot with a new key and puts that key in the link, after the # sign. Browsers don't send that part of a link to a server, so we store only the encrypted copy and can't read what you share. Anyone with the link can read it, and removing the link deletes the copy.

Deleting a conversation permanently deletes it, its files, and its share links from our servers, and you can't undo it. Closing your account deletes all your conversations, and so does Start over in Chat. Attached files and files Chat creates are deleted 30 days after they are stored. Images and the beginning of each file's text stay with the conversation.

Backups are kept for 29 days and hold conversations only in encrypted form. If we ever restore a backup, deletions made since it was taken are applied again before Chat comes back, so a deleted conversation stays deleted.

• If you reset your sign-in password, your chats stay locked with the old one. On a device where Chat stayed unlocked, they switch to your new password the next time you sign in there with that password. Elsewhere, your backup phrase opens them.
• If you forget your unlock password, your backup phrase opens your chats, and you choose a new unlock password.
• Without an unlocked device or a backup phrase, your chats can't be recovered, by you or by us. Start over deletes them so you can use Chat again.

This is not end-to-end encryption in the strict sense. Our server reads a conversation in memory while it answers, the model that answers receives the conversation, and our network provider, Cloudflare, handles your messages, the conversation key, and your sign-in key in transit.

Someone in control of our server while it answers could read that conversation and take its key. Keys don't change, so that key would keep opening the conversation's stored messages later. Someone in control of our server when you sign in would get only your sign-in key, which doesn't open your chats.

Someone with your sign-in key, or with a copy of our database or backups, could try to guess weak passwords offline, so a long, unusual password matters.

Chat's encryption runs in code we serve to your browser, so you rely on us to serve it unchanged. Encryption protects what is stored, not the information listed above that we can still see.

Read our Privacy Policy for how we handle your information, or email support@abliterant.ai with questions.

• Everything is encrypted with AES-256-GCM: in your browser with WebCrypto, and on our server with Node.js.
• Keys: a random 256-bit account key; a random 256-bit key for each conversation, stored wrapped (encrypted) by the account key; a random 256-bit key for each file, kept only inside the encrypted message that uses it; and a random 256-bit key for each share link. The link holds the share key itself; our server stores only a copy wrapped by the conversation key.
• Passwords: the sign-in or unlock password, normalized to NFKC, goes through Argon2id with 64 MiB of memory, 3 passes, 1 lane, and a random 16-byte salt, giving the 32-byte key that wraps the account key.
• Sign-in key: the sign-in password, normalized to NFKC, goes through Argon2id with the same settings and a 16-byte salt made from your email address (the first 16 bytes of SHA-256 of abl/v1/login-salt, a zero byte, and the address). HKDF-SHA256 of the result, with abl/v1/login-key as info, is the sign-in key. Our server stores only an Argon2id hash of it. An account made before this design sends, once, the Argon2id hash of its old sign-in (19 MiB of memory, 2 passes, the stored salt), which our server checks against a SHA-256 of the stored hash and then replaces with the sign-in key's hash.
• Backup phrase: 12 BIP-39 English words (128 bits). The key that wraps the account key is HKDF-SHA256 of those 128 bits, with the account ID as salt and abl/v1/vault-recovery as info.
• This device: the account key, wrapped by a non-extractable AES-GCM key kept in the browser's IndexedDB.
• Records: 0x01 ‖ 12-byte random nonce ‖ ciphertext ‖ 16-byte tag. The plaintext is a 4-byte big-endian length, the data, and zeros up to its Padmé length (at least 256 bytes), so stored sizes are approximate. The additional data, abl/v1/<purpose>/<account>/<conversation>/<record>, binds each record to its place.
• Files: 0x01 ‖ 8-byte random prefix, then 64 KiB chunks, each sealed with the nonce prefix ‖ 4-byte chunk index and the additional data abl/v1/file/<file>/<index>/<final>. The plaintext is an 8-byte size, the data, and zeros up to its Padmé length.
• A conversation key travels only inside a request over TLS, and our server uses it only for that request. Our network provider, Cloudflare, decrypts TLS at its edge, so the key passes through it in transit. A wrong key is refused without detail.