threat model

the short version: notes, file contents, and ordinary direct-message bodies are encrypted on your device before they reach us. stored inbox mail is also sealed to your public key, but our SMTP service first receives it as ordinary plaintext. public profiles, necessary metadata, and outbound email are server-visible as described below.

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

what we protect against

• 1.
  server compromise (RCE / supply chain)

  browser-sealed payloads remain ciphertext without the user-held keys, while public data, metadata, and email delivery keep their disclosed boundaries.
• 2.
  legal process against the company

  we cannot decrypt browser-sealed payloads or stored inbox messages, but can produce server-visible data and metadata we hold.
• 3.
  hosting-provider compromise / hypervisor access

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

  admin endpoints do not decrypt sealed content; mail services still process plaintext during their disclosed delivery windows.
• 5.
  passive network surveillance

  HTTPS protects web traffic. SMTP transport can be opportunistic, and ordinary long-lived logs are designed not to retain raw IPs.

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.
• ▸ internet email transport. our SMTP service receives inbound mail as plaintext before sealing it to the recipient’s public key. outbound mail is plaintext through our application and relay. the application does not intentionally persist either plaintext delivery copy. queues, temporary files, logs, and crash behavior still require operational verification. SMTP may use opportunistic TLS, which is not end-to-end encryption or a guarantee against downgrade.
• ▸ 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 sent to the configured matching provider; the image bytes are not sent to that provider. this scanner is not applied to browser-sealed content or stored sealed inbox messages.
• ▸ 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 receives plaintext note contents, file contents, or ordinary direct-message bodies.
• ▸the SMTP service seals received mail to the recipient’s public key; the application intentionally stores the sealed copy, and only the browser-held private key decrypts it.
• ▸ordinary long-lived logs must contain no raw IPs, emails, user IDs, tokens, or plaintext. whether deployed logs, queues, temporary files, and crash behavior meet that rule remains unverified.
• ▸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.
• ▸production readiness requires encrypted backups with a separate key and verified restoration behavior.
• ▸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.