How Burndrop works

Deep dive: E2EE for corporate workflows

1 · The owner generates a form

In your dashboard you drag text, number, and file fields onto a canvas. When you publish, Burndrop binds the form link to your RSA-2048 public key. The server never learns your private key — only the public half, which is designed to be shared.

2 · The client fills it in, encrypted locally

Your client opens the public link in a normal browser. As they type and attach a file, their browser derives a one-time AES-256 session key, encrypts every field and every 1 MiB file block with it (AES-GCM, authenticated encryption), and locks the session key to your RSA public key. The consent checkbox is captured and logged as GDPR evidence before anything is sent.

3 · The server only ever sees ciphertext

The encrypted stream is piped straight into PostgreSQL with a binary COPY — no intermediate files, no plaintext at rest, no server-side key material. Retention is enforced by plan: the 3-day free trial ends with a full auto-purge one day later (unless you upgrade); paid plans delete on first download and keep 30-day leftovers.

4 · Only the owner can read it

In your submissions viewer, the browser unlocks the session key with the private key stored in your device's IndexedDB, decrypts the fields instantly, and streams the file back in 1 MiB blocks — decrypted just-in-time, never written to our servers.

One-time secrets for anything else

Not everything is a form. Burndrop's self-destructing secrets let you share a note, an OTP, or a file pointer through a link whose decryption key lives only in the URL fragment (#…). The fragment is never sent to the server. The first read triggers a hard SQL delete.

Create your account