The security model.

Cryptography

• Encryption: every note is sealed on your iPhone with AES-256-GCM (a 12-byte nonce and a 16-byte authentication tag) before anything is uploaded. Tampered ciphertext fails authentication instead of decrypting to garbage.
• Key derivation: the key comes from HKDF-SHA256 over 32 fresh random bytes — the fragment key — plus a random 16-byte salt. Those 32 bytes go into the link's #fragment and into nothing else.
• Passphrase (optional): if you set one, it's stretched with PBKDF2-HMAC-SHA256 at 600,000 iterations and mixed into the derivation, so the link alone is no longer sufficient. Wrong guesses fail locally in the recipient's browser and never consume views.
• Verified twice over: the Swift implementation in the app and the WebCrypto implementation in the viewer are checked against each other with independently generated test vectors, so a note sealed by one always opens in the other.

The fragment-key link

A note link looks like burnpony.app/n/<id>#<key>. Everything after the # is a URL fragment, and browsers do not send fragments in HTTP requests — to this server or any other. The server learns the random note ID; the key exists only in the link itself and in the recipient's browser while they read. This is why "the server can't read your note" is a property of how the web works, not a promise.

What the server stores — and can't read

While a note is live, the server holds: the random note ID, the sealed ciphertext blob, created and expiry timestamps, the view allowance and count, whether a read receipt was requested, and a hash of the management token that lets your app burn the note early. If receipts are on, opened-at timestamps are recorded. That's the inventory. It never has the key, the note text, or even the auto-hide setting — that travels encrypted inside the note. Creation rate-limiting uses IP hashes with a server secret that expire after about two hours, not raw address logs.

Burning, and what's left

When the last allowed view is fetched, the ciphertext is deleted in the same database transaction that served it. Expired notes are removed by a sweep that runs every five minutes. And crucially, a burned note, an expired note, and a note that never existed all return exactly the same response — the server cannot be used as an oracle to confirm that a given link was ever real.

The viewer

Recipients open a single self-contained page: no frameworks, no cookies, no analytics, no requests to anywhere except this server for the sealed note itself. It carries a strict Content-Security-Policy (default-src 'none'), a noindex directive, and a no-referrer policy so the link never leaks through referrer headers. Decryption happens in the browser's built-in WebCrypto. The page is short enough to audit with View Source — that's a design goal, not an accident.

Read receipts, honestly

Receipts are opt-in per note. The recipient sees "The sender will be notified when this note is opened" before they reveal it. The push you receive is deliberately generic — "A note was opened." with only the note ID attached — so nothing about the note's content transits Apple's servers.

Threat model

BurnPony protects the confidentiality and integrity of a note against the server, network observers, and anyone who later finds the URL without its fragment — and it limits how long and how many times a note is readable at all. It assumes your iPhone and the recipient's browser behave as documented. It does not defend against malware on either endpoint, or against a recipient who copies, screenshots, or photographs the note while it's visible — no burn-after-reading tool can. Self-destruction limits future access; it cannot police the moment of reading.

Honest limits

• The link is the key. Anyone who obtains the full link (and the passphrase, if set) before it burns can read the note. Send it over a channel you'd trust with the secret itself, or add a passphrase and share that separately.
• Screens can be captured. The auto-hide countdown reduces shoulder-surfing time; it is not screenshot protection.
• Lost phone, lost management. Notes you've sent keep burning and expiring on their own schedule, but without the app's Sent tab you lose the ability to burn them early or check status.
• Network-level metadata exists. Like any web server, this one sees connecting IP addresses at the network level while serving requests. The web server in front of the relay is configured with access logging disabled, and the application keeps only the short-lived salted IP hashes described above.

The exact specification

Every claim on this page is stated precisely, constant by constant, on the v1 protocol page, written against the frozen code in the public repository and checkable against the shared test vectors.

Open to inspection

The viewer is auditable on every note link today, and the crypto core, viewer, and relay server are planned for public release — see the open source page for where that stands.

Reporting a vulnerability

Found something? Email NorseHorse@norsehor.se — encrypted with this PGP key if you prefer. Reports go straight to the developer, and fixes ship fast because there is no committee in the way.