policy

We keep the minimum necessary data while respecting the life cycle you choose.

This policy explains what we store, how paste bodies are protected, and how expired or burned entries disappear.

What we record

To keep the service healthy we record the most basic metadata tied to every paste.

  • IP addresses are held briefly to enforce rate limits and detect abuse.
  • Titles, language, and expiration stay with the paste so the UI can display your settings without touching the content.
  • Passphrases are hashed before persisting so we never store the plain secret.

Content protection

Every paste body is encrypted before hitting disk, and only decrypted when the right link (and passphrase, if used) is provided.

  • The ciphertext lives in storage/{uid}.enc while the database only holds metadata.
  • Burn-after-read pastes, or any paste with a passphrase, stay unreadable until the correct secret is supplied.
  • We do not replicate paste contents outside this service; each file is considered ephemeral.

Expiration & cleanup

When the expiration timer trips we delete both the metadata row and its encrypted file, and expired data is purged on every boot/cron run.

  • Files are overwritten with random data before unlinking, making recovery infeasible.
  • Burn-after-read pastes delete themselves immediately after viewing.
  • No expired database rows remain—cleanups happen on boot and via the cron helper.

Access & privacy

Only holders of the unique paste link (and passphrase, if set) can decrypt content, and there is no secondary storage.

  • Every paste is discoverable solely by its uId—share the link only with trusted people.
  • Protected pastes require their passphrase before any content can be drawn.
  • Aside from the minimal metadata listed above, we do not retain personal identifiers.