Witbitz · trust

Don't trust us. Check us.

Every privacy page on the internet asks you to believe it. This one gives you checks. Below is what Witbitz claims, how to check each claim yourself, and what no setting hides — including the part that doesn't flatter us.

Prove it yourself — live → Run the checks Read the code that touches your plaintext

The chain: each side checks the other

The page you load is a release anyone can rebuild. Each release is rebuilt from its source in a separate build enclave and logged in a public transparency log; a page that is not the logged bytes is not served as a release.

Your device checks the server. Before a confidential room's key leaves your device, the app checks the enclave's hardware attestation against its published, audited measurement — and seals the key to that enclave alone.

The server checks your device. In a room that requires it, every read and turn must come from a release in the public log; a modified app is refused.

So neither Witbitz nor the app's own builder can read a room — and each link of that is a check, not a promise. The whole chain: the trust model.

The scoreboard

Witbitz can't read your rooms. A room is sealed to a key made on your device; the store holds only ciphertext addressed to the room — `recipients: ["room"]` — and there is no operator key. How to check →	Production
The gate enforces. On a gated room, reads and writes are refused without an allow-listed sign-in — even if you hold the room key. How to check →	Production
Egress is locked. The app you loaded can reach only a published list of hosts. The browser enforces it, not us. How to check →	Production
Every release is a reproducible, logged build. Rebuild the published source and get the hash that runs — the web app's releases and the server's render alike. How to check →	Production
The server checks the client. A room can require that every member runs a release from the public log. In a browser this proves the release, not the device; hardware-attested phone apps are designed, not released. How to check →	Production
A confidential room is unreadable even in use. Its turns run inside an attested AWS Nitro enclave that your device verifies first; the model runs on confidential compute. How to check →	Production
Every confidential answer carries its proof. Each reply is signed inside the enclave with the build that ran it, the model's verified receipts and the tools it called — checked on your device. How to check →	Production
Your credentials are spent, never seen. A key or login you connect is sealed to an always-on attested enclave; an assistant spends it through calls a member approves (or, for an MCP tool granted to run on its own, by itself, still through the enclave), and neither the model nor Witbitz can read it back. How to check →	Production
Your account is yours alone. Its keys are made on your device, and its backup opens only with your recovery code and an email check, or your backup passkey. We cannot recover it for anyone. How to check →	Production
A voice note is sealed before it leaves the enclave. The Siri endpoint's TLS key was made inside the enclave, and its fingerprint rides every attestation — check the served certificate against the attestation yourself. How to check →	Production

The confidential tier, in plain terms

A room's key is made on your device. In a confidential room the app first checks the enclave — its hardware signature, the certificate chain to a pinned AWS root, a nonce for liveness — in your browser, against the enclave's published measurement (/enclave-claim.json), which is reproducible from published source and audited before it ships. Only then is the key sealed to the enclave, and the room's turns run inside it. The enclave is always on, so a first message never waits for it.

The model, too. Inside the enclave, a turn leaves the measured image only through an attested no-log gateway into confidential-compute inference on an open-weights model — and fails closed if the gateway does not attest. The tier is chosen per room by the app's builder: a standard room keeps a frontier model, whose vendor does see the turn (next section).

What is never hidden

Sealing content does not seal its shape, and no amount of cryptography changes that:

Metadata. That a room exists, when it changes, and roughly how large each write is.
The model provider. A standard room's turns reach the model that answers them. A confidential room's go only to attested confidential inference.
The device. Plaintext has to exist on a device for a person to read it. A compromised device — a keylogger, malware — is outside every software guarantee.
Availability. We can refuse to serve you. We can't read you.
Reproducibility isn't behaviour. It proves the running code is the code you can rebuild. Whether that code does what we say is what reading it is for — which is why the code that touches your plaintext is small and published.

If you'd rather not trust us at all

Run it yourself. The runtime runs in your own boundary: your cloud, your model endpoint, your object store, your identity provider. Same reproducible build — so you can confirm the image you run is the one we published. Deployment options →

Two routes to the same property. One asks you to check our infrastructure; the other removes it from the question. Neither asks for the benefit of the doubt.