End-to-end encryption

Most of the web already encrypts in two ways that differ from this. Encryption in transit (TLS, the padlock) protects data between your device and a server, but the server then reads it. Encryption at rest protects a disk, yet the company holding the disk usually holds the key as well. End-to-end encryption moves the key out of the company's hands: even a breach of the server, a court order to the operator or a curious employee yields only scrambled bytes. Messaging apps made the idea familiar: a message is sealed on one phone and opened on another, so even the company carrying it between them cannot tell what it says, only that something was sent. Open designs such as the Signal protocol show that the approach scales from pairs of friends to large groups.

In practice, a device makes a key, uses it to encrypt each item before it is sent, and gives the key only to devices you approve. The hard part is not the cipher, which is standard (AES-256-GCM is widely used), but the keys: how a new device receives one, and what happens when you lose them all. Real end-to-end systems answer with a passkey, a recovery key or an already trusted device, and they accept a trade-off. Because nobody else can open your data, nobody else can rescue it either. Compare it to a letter in a locked box: the courier handles the box all along the route, yet only the person with the matching key can read what is inside.

Know the limits too. It protects the data from the server, not from a compromised device, a stolen unlocked phone or malware. And an AI chat cannot be end-to-end all the way to the model: the model must read your text to answer it. So the term fits storage, sync, backups and sharing, and not the live exchange with the model. A useful test is to ask who holds the key. If the answer is the operator, the service may still be encrypted, but it is not end-to-end, and the operator can be compelled or breached.

On first use, your browser creates a non-extractable AES-256-GCM key: the page can use it to encrypt and decrypt, but no script can read it as bytes, not even ours. Your conversations, images, characters and memory are encrypted with it before they are written to your browser's database. If you turn on sync in Settings, each item is encrypted in your browser under a data key our servers never have, and its id is made opaque. That key is wrapped by your passkey and your recovery key, and sealed for each approved device; every sync request must be signed by an approved device. Without a passkey, a recovery key or another approved device, our copy can no longer be opened.

Share links and your backup are encrypted as well, the backup with your passphrase. The part that is not end-to-end is the answer itself: your message passes through our servers to the model and back, and the transparency page states that it is written neither in the database nor in the logs. That also explains why we store only sealed items: a database leak would expose scrambled bytes, plus sizes rounded up and timestamps, and none of the words you wrote.