seal
threat model · open spec

The receipts.

“We can't read your secrets” is a claim. This page is where it becomes legible: what actually happens, what the server stores, what it doesn't, and what you still have to trust.

the encryption flow
what the server sees
  • An opaque ciphertext blob
  • A nonce, a random ID, an expiry timestamp
  • An opening counter (decremented per fetch)
  • A flag for “passphrase used”, but never the passphrase or its parameters
  • Standard request metadata (IP, user agent, log entry); IP is used in-memory for rate limiting and never persisted
what the server cannot see
  • The plaintext message
  • The decryption key (it lives in the URL fragment)
  • The passphrase you typed
  • The sender or recipient identity
  • Whether two secrets came from the same person
01chapter

How encryption works

When you submit, your browser generates a random 256-bit key, encrypts your message with AES-256-GCM, and POSTs the ciphertext (plus a nonce and metadata) to the server. The key is appended to the URL after #, which browsers never send to servers.

When the recipient opens the link, their browser reads the key from the fragment, fetches the ciphertext, decrypts it, and renders the plaintext. The server then decrements the opening counter and, at zero, deletes the row.

02chapter

What you still trust

  • That the JavaScript served to you is the same code published in the open-source repo
  • That a browser extension or compromised device isn't reading your screen
  • That the channel you used to send the URL isn't archived (chat backups, email)
  • That your recipient won't screenshot the plaintext to somewhere insecure
03chapter

Limitations to know

  • An attacker with the full URL has the secret. It is a bearer token.
  • An adversarial server could ship malicious JS to a single user; the audit trail is npm + git
  • Timing of insert and delete events is visible to anyone watching the network
  • PBKDF2 iteration count is fixed (600,000); very weak passphrases are bruteforceable offline if the ciphertext leaks
04chapter

Reporting a vulnerability

Open an issue on the GitHub repository for non-sensitive issues. For sensitive vulnerabilities, please email the maintainer privately first. We aim to acknowledge within 72 hours.

last reviewed · 2026-05-23
read the source on GitHub