Why Ethyx isn't end-to-end encrypted

When I first sketched Ethyx, end-to-end encryption felt like the default. Of course chat would be E2EE. Why wouldn't it be? It is the gold standard for messaging apps, it sounds right on a marketing page, and it matches how a lot of us want to feel about our data. Reality got in the way.

The model has to read your prompt

End-to-end encryption means only the endpoints can read the content. For Signal, that works: you and the person you are talking to hold the keys. For an AI chat client, the "other end" is not a person with a keyring. It is a third-party language model that only speaks plaintext.

If we encrypt your messages on your device, something still has to decrypt them before they reach OpenAI, Anthropic, Google, or xAI. That something is our server. The moment we hold plaintext to assemble context and call the provider, the end-to-end promise is already broken. Calling that E2EE would be dishonest.

Encryption at rest on Ethyx protects stored history. It does nothing to the live request. We said this plainly in How honest is your AI chat app about your data?, and it is still the central constraint.

Could the browser talk to the provider directly?

Yes. Some products keep the API key in the browser (or ask you to bring your own) and send prompts straight from your device to the provider. That is a valid architecture. It also comes with trade-offs we did not want for Ethyx.

Keys and billing live in the client. A key in the browser is exposed to XSS, extensions, and device malware in a way a server-held operator key is not. Billing and rate limits become harder to operate fairly across a multi-provider catalog.

History is per-device unless you sync it. Syncing encrypted history still needs a place that can decrypt for the next turn—or you give up cross-device chat. You recreate the same server-decrypt problem under a different name.

Nothing useful can happen on the server. Background turns, queued workflows, server-side web search and research tools, title refresh, suggested replies, and continuing a thread on another device all require the server to see (or temporarily hold) message content. A pure client-direct design gives those up, or reintroduces a decrypting middle.

You lose the identity separation Ethyx is built around. When the browser calls the provider directly, the provider sees your IP and, typically, your account or key. Ethyx sends turns on operator credentials with pseudonymized identity—not your personal ChatGPT or Gemini login. Client-direct traffic undoes that layer.

We chose a server-mediated client: one place to encrypt history, run tools, and keep provider identity at arm's length—without pretending the live prompt is invisible.

What we built instead

Chat content is encrypted at rest. Messages, conversation titles and summaries, project notes, search queries, image prompts, uploaded files, and related workflow state are encrypted in our database. We use application-layer AES-256-CBC with an HMAC, on a dedicated encryption key stored separately from database backups. Connections to Ethyx use HTTPS.

Our servers decrypt that history when a turn runs—to assemble context, call tools, and stream a reply. That is intentional. It is also why we will not call it end-to-end encryption.

On top of storage encryption we still:

• Pseudonymize name, email, and attachment filenames before provider requests (or withhold them entirely if pseudonymization is off—fail closed).
• Request no-retention where the provider API supports it (store: false on OpenAI, xAI, and Gemini chat by default). That is a request, not a guarantee, and we do not claim zero data retention.

The full list of protections and caveats lives in the honesty post. The identity story is in the pseudonymization post.

What this protects—and what it does not

It protects stored history. A stolen database dump of encrypted message bodies is not a readable transcript. Keys are not sitting next to the rows they unlock.

It does not hide the live request. The upstream model receives your prompt text over HTTPS and processes it on provider infrastructure. Encryption at rest cannot change that. Neither can a slogan.

It is not a substitute for judgment. Regulated health data, privileged legal material, and other high-sensitivity content may not belong in any cloud AI client—ours included. We would rather say that out loud than sell a privacy guarantee we cannot keep.

E2EE was the first design I wanted. Encryption at rest, honest about the provider boundary, is the design that survives contact with how language models actually work. If that trade-off matches how you want to use AI, we built Ethyx for you.

---

Ethyx is in closed testing with an access code today. Subscriptions will launch after closed beta.