About Flashpaper

Flashpaper is a one-time secret sharing tool. We store ciphertext only, burn secrets on first view if you choose, and set strict no-cache headers on pages that reveal secrets.

How it works

IDs
Each secret is given a random UUID which is not guessable and which reveals nothing about the secret.
Text secrets
Your text is encrypted server-side and stored as ciphertext in the database (max 4 KB). The plaintext is never written to disk.
File secrets
Your file is encrypted server-side and the ciphertext is written atomically to disk. The plaintext file is encrypted in-memory and is never written to disk. We store only the path and metadata in the database (max 25 MB).
Passphrase (optional)
Add a passphrase to require “link + passphrase” to decrypt. The passphrase is never stored; it’s used in memory to derive the encryption key when encrypting/decrypting.
Server-managed key (no passphrase)
If no passphrase is provided, we encrypt with a server-managed symmetric key.

Burn after reading

When “Burn after reading” is on, Flashpaper enforces a single view using a database transaction: we atomically mark the secret as burned, fetch the payload, then hard-delete the row (and subtype rows via CASCADE). For files, we delete the ciphertext on disk before decrypting and sending the response.

Technical Details

Expiration & deletion

  • Every secret has a TTL. Expired secrets are purged and cannot be recovered.
  • Burned or expired text secrets: ciphertext is deleted from the database.
  • Burned or expired file secrets: ciphertext files are deleted from disk; DB rows are removed.

Transport & caching

  • All secret-revealing endpoints send Cache-Control: no-store, Pragma: no-cache, and Referrer-Policy: no-referrer.
  • Secret URLs are unguessable (UUIDs) and aren’t listed anywhere.

Encryption details

  • We use the tempel library for authenticated encryption with secure defaults.
  • Text and files share the same encryption path (files are encrypted as bytes).
  • Atomic file writes use ATOMIC_MOVE to prevent partial files on disk.

Policy

What we store

  • Never the plaintext secret.
  • For text: encrypted bytes (ciphertext) ≤ 4KB.
  • For files: path to the ciphertext on disk, original filename, size.
  • Operational metadata needed to run the service (timestamps, IDs, TTL, and burn flag).

What we don’t do

  • No indexing or previewing your files.
  • No embedding third-party trackers on secret pages.
  • No storing passphrases.

Threat model & limitations

  • Flashpaper is not end-to-end encrypted between browser peers: encryption/decryption happens on the server. Using a passphrase adds a second factor the link alone does not reveal.
  • Plaintext exists briefly in memory during encrypt/decrypt. It is never stored to disk.
  • As with any link-based sharing, treat the URL as sensitive. Anyone with the link (and passphrase if set) can open it until it’s burned or expired.

Responsible use

Do not use Flashpaper for contraband or content prohibited by law or by our Terms.

Questions about security or looking for a deeper review? Feel free to reach out and we’ll be happy to walk through the design, configuration, and trade-offs.

Send a secret