How it works, in plain words

Fusenote is built so that we couldn't read your notes even if we wanted to. Here's exactly what happens.

1. Your browser locks the note

When you press Light the fuse, your browser creates a random 256-bit secret using its built-in cryptography (the Web Crypto API). From that secret it derives two things: an encryption key and a separate proof key. The note is encrypted with AES-256-GCM, a standard that also detects any tampering.

If you add a passphrase, the keys are derived from the passphrase and the secret together using PBKDF2 with 310,000 rounds, so guessing the passphrase is slow and useless without the link.

2. Only scrambled text is sent

The server receives the encrypted note, a random 12-byte nonce, your expiry choice, and a fingerprint (SHA-256 hash) of the proof key. It never receives the secret, the encryption key, the passphrase or the text.

3. The key rides in the link's fragment

Your link looks like /n/AbC123xyz#secret. Everything after the # is the fragment. Browsers keep fragments to themselves: they aren't sent to servers, proxies or in referrer headers. That's where the secret lives.

4. Opening burns it

Visiting the link only shows a Reveal button, so chat apps that preview links can't destroy the note by accident. When someone presses it, their browser sends the proof key. The server checks it against the fingerprint, hands back the encrypted note and, for burn-after-reading notes, deletes it in the same step. A wrong passphrase is refused before anything is deleted, so a typo doesn't destroy the note.

5. Time runs out

Every note has a fuse between 5 minutes and 7 days. A cleaner runs every minute and permanently deletes anything past its time, read or not. The sender also gets a one-time Destroy it now button.

6. Moving it to a phone

The result screen can show the link as a QR code. It is drawn by a small script in your browser, qr.js, so the link and its key never go to us or to any QR service. Because the code contains the whole key, treat it like the link itself: scan it, then close it, and don't screenshot it or show it on a video call.

7. Asking someone to send you a secret

A letterbox is the other direction: you want them to send you a password. Your browser creates an ECDH P-256 key pair. The public lock is stored with an empty letterbox; the private key stays in your pickup link after the #, like a note key. The reply link you send them has no key. Their browser generates a one-time key of its own, agrees a shared secret with your lock, and encrypts the text with AES-256-GCM. Someone who only has the reply link can fill the letterbox (or fill it with junk) but cannot decrypt what was written. Collecting proves you hold the private key, returns the ciphertext and deletes it. Before anything is posted, the reply page shows the sender exactly what will go in, flags stray spaces and invisible characters (all in their browser), and asks them to confirm, because once posted it cannot be read back from the reply link. Afterwards the reply link can only learn whether the secret is still waiting: the server records the minute it was posted, not when or whether a person read it, so Fusenote never shows a read receipt. Details are in crypto.js (requestCreate, requestSeal, requestOpen) and in the plain-words guide.

What we store, and what we don't

Stored until the note is gone: the encrypted note, its nonce, the proof fingerprint, the expiry time, whether it burns after reading, and a hashed deletion token.
Stored until a letterbox is gone: your public lock, a proof fingerprint, the expiry time, and — after they reply — the encrypted secret plus their one-time public key. Never the private key or the text.
Kept as running totals only: how many notes were created, burned, expired or deleted. No per-note history.
Never stored: your text, keys, passphrase, IP address, cookies, access logs or tracking analytics. We keep one anonymous daily tally of views per page, plus the domain of a site that linked here (for example a search engine). No cookies, IP addresses or browser details are stored, so no visitor can be told apart or followed. Note links are counted only as one combined "a note was opened" number, never by note; letterbox reply and pickup pages are counted the same way, as combined "/r/*" and "/c/*" totals. Rate limiting uses a short-lived, in-memory counter keyed on a hash of your IP that is never written to disk.

Limits

Text only, up to 64 KB per note. A handful of new notes per minute per visitor. These keep the service small and hard to misuse. There are no file uploads.

What it can't protect against

Encryption protects the note on its way and while it waits. It can't help if the device that opens it is compromised, if someone forwards the link before it's read, or if the reader copies the text. If a note says "already read" when you haven't opened it, assume someone else did and change whatever secret it held.

Check it yourself

All the cryptography is in one small, readable script, crypto.js, with no third-party code. There's also a public counter at /api/stats.