threat model

the short version: everything you keep here (your notes, your files, the contents of your mail) is scrambled on your own device before it reaches us. we only hold the scrambled copy, and we don’t have the key. so if our servers get hacked, a court orders your data, or someone on our side goes rogue, what they walk away with is unreadable.

below is the longer, more technical version: what that protects, what it doesn’t, and the rules we hold ourselves to. last reviewed 2026-07-13 · alpha quality.

what we protect against

• 1.
  server compromise (RCE / supply chain)

  all user content is client-side encrypted with keys the server never possesses.
• 2.
  legal process against the company

  we cannot decrypt what we serve.
• 3.
  hosting-provider compromise / hypervisor access

  same defence as #1; disk encryption is just an extra layer on top.
• 4.
  malicious insider / rogue admin

  privilege separation; no plaintext access endpoints anywhere.
• 5.
  passive network surveillance

  TLS everywhere; minimised metadata; no IP retention.

what we don't pretend to defend against

• ▸ endpoint compromise. if your own device is already owned, nothing we do can protect what you type into it.
• ▸ traffic-analysis correlation across services. we keep metadata thin, but we’re not running a mixnet or onion routing.
• ▸ a quantum computer cracking traffic recorded today. out of scope for now; we’ll revisit when post-quantum TLS is standard.
• ▸ physical coercion. if someone can force you to hand over your password, no encryption stops that.
• ▸ a backdoored version of this site. we serve the code that does the encryption, so a compromised server could in theory ship your browser malicious javascript. that’s the built-in limit of any in-browser crypto; we shrink the risk with a strict CSP, no third-party scripts, and self-hosted everything — and you can watch the real primitives run in your own browser on the proof page.
• ▸ outbound /email sending. a message you compose to an outside inbox is plaintext by nature (the recipient holds no key), so the server sees it in transit. admin-only, relayed not stored, and never applied to received mail, which stays sealed.
• ▸ public profiles (/@handle). these opt-in pages are public on purpose, so the display name, bio, and links sit in the clear. they’re never built from your sealed data, and they stay private until you publish.
• ▸ known-CSAM scanning of public profile images. because /@handle avatars and banners are public, an upload’s perceptual fingerprint (a hash) may be checked against databases of known child-abuse imagery. only the hash is checked, the image itself never leaves our server, and this applies only to public profile images — your sealed notes, files, and mail can never be scanned by anyone, including us.
• ▸ message metadata (/messages). your messages themselves are sealed on your device — we relay ciphertext we can never read — but to route them we necessarily know who talks to whom, when, and how much. contents are zero-knowledge; the fact of a conversation is not.
• ▸ message key substitution. you fetch a contact’s public key from us, so a malicious server could hand you a key it controls. your client pins keys and warns loudly if a contact’s key ever changes, and both sides see a fingerprint to compare out-of-band — for anything sensitive, verify it. messages also have no forward secrecy yet: whoever learns your key can read your whole history with each contact.

invariants

these are the contracts. any PR that violates one is rejected.

• ▸the server never sees user plaintext for notes, file contents, or received mail (mask + mailbox inboxes).
• ▸the server never logs PII — no IPs, no emails, no user IDs in long-lived logs.
• ▸no third-party scripts, fonts, or analytics reach the browser. strict CSP, self-hosted everything.
• ▸no third-party CDNs for plaintext — ciphertext-only on any external edge.
• ▸the admin backend has no endpoint that decrypts user content.
• ▸backups encrypted with a separate key from runtime data.
• ▸cryptographic parameters are versioned so rotation is possible without re-encrypting everything.
• ▸anonymous features stay anonymous — never linked to an account even if you’re logged in.