briefkist
briefkist
Get startedSource on GitHub
free to self-host · AGPL-3.0

Security & the data path

This page describes exactly where your documents travel, who could see them and when, and the claims we deliberately refuse to make. If you read one page before trusting us with your mail, read this one.

the data path, stage by stage

1 · Capture

You photograph the letter in the app. Pages stay on the phone until your server is reachable — nothing is queued through anyone else's machine.

device storage only · no intermediary

2 · Transit

The phone talks only to your server — directly, authenticated with the device token minted when you paired it. There is no relay, no queue, no CDN in between. On a hosted server the connection is TLS; self-hosted, traffic stays on your own network or inside an encrypted WireGuard/Tailscale tunnel and never crosses the open internet.

per-device token · direct connection · TLS on hosted

3 · Processing — the honest moment

For the seconds a letter is being read and understood, it exists unencrypted in your private server's memory. That is the only moment. On your own hardware, that memory is yours; on hosted, it is a single-tenant machine we operate for you — purpose-limited, never retained, never trained on.

RAM only · seconds · the one moment we name out loud

4 · At rest

On a hosted server, everything stored — scans, text, summaries, the search index — is encrypted with a key derived from a passphrase only you hold. We keep only ciphertext; the key never exists on our side. Self-hosted, the archive lives on your own disk like the rest of your files — pair it with full-disk encryption (FileVault, LUKS); at-rest encryption inside the app is on the roadmap, not shipped.

hosted: your passphrase → your key · we store only ciphertext

5 · Search

Queries run on your server and go nowhere else — never a third-party API. On hosted, search runs while the archive is unlocked with your passphrase; locking it returns everything to ciphertext.

on your server · never a third-party API

Threats, named concretely

Both paths protect against different adversaries. Neither protects against everything, and we would rather you know which is which. The hosted column describes the hosted service as it opens — it is how those servers are built, not a property of self-hosting.

adversary
self-host
hosted
Provider with access to the server's disks
protectedThere is no provider. The disks are in your house.
protectedDisks hold ciphertext; the key never leaves you.
Our own staff
protectedWe are not in your data path at all.
protectedOperations happen on ciphertext; plaintext exists only in RAM during processing, unattended by design.
Subpoena of the provider's disks
protectedA warrant for our disks yields nothing of yours.
protectedYields ciphertext. What it cannot yield is your passphrase.
Network observer between phone and server
protectedTraffic stays on your LAN or inside an encrypted overlay tunnel — an observer would have to already be inside your home network.
protectedTLS with the same per-device tokens, direct to your single-tenant server.
Malware on your own phone or computer
not protectedIt sees whatever you see. Keep devices updated.
not protectedSame. No server design can fix a compromised endpoint.
Someone who has your passphrase
not protectedThe passphrase is the key. Anyone holding it is, cryptographically, you.
not protectedSame — and we cannot revoke or reset what we never had.

The exact claims

Quote us on the left column. Hold us to the right one.

what we say
On a hosted server, everything stored is encrypted with a key derived from a passphrase only you hold — we keep only ciphertext.
While a letter is being read and understood, it exists unencrypted in your private server's memory — and that is the only moment.
No third party is ever in the data path.
what we deliberately never say
"zero-knowledge"

During processing, the server your instance runs on holds the plaintext in memory. A zero-knowledge claim would be false for those seconds, so we don't make it.

"end-to-end encrypted"

E2EE means no server ever sees plaintext. Ours must, briefly, to read your mail for you. The honest description is: processed in RAM on your private server; on hosted, TLS in transit and encrypted at rest with your key.

Marketing that rounds these words up is how trust in this category got spent. We'd rather be precise than impressive.

Read the source codeSecurity policy & disclosuresub-processor list — one entryThe EU datacenter provider (Falkenstein, Germany) — racks and power, never data access.