Skip to main content
Home Creations Blog About Contact
Dr

DropNote — Encrypted Notes That Delete Themselves

Write it, lock it, drop it. Notes encrypted in the browser with AES-256-GCM, shared by link, and destroyed on a schedule you set — the server never holds a key.

Launch Date Sep 2026
Status Live

Technologies Used

Web Crypto API AES-256-GCM Zero-knowledge PHP
Screenshot of DropNote — Encrypted Notes That Delete Themselves

Screenshots

The composer. Expiry, view limits and burn-after-reading are set before the note is encrypted, so the destruction rules travel with the ciphertext.
The composer. Expiry, view limits and burn-after-reading are set before the note is encrypted, so the destruction rules travel with the ciphertext.

Project Overview

Most "private note" services are private in the sense that they promise not to look. DropNote is private in the sense that it cannot — the note is encrypted in your browser before anything is transmitted, and the key never leaves your machine.

Share the link, the recipient decrypts locally, and the note destroys itself on whatever terms you set.

What it does

  • Zero-knowledge client-side encryption with AES-256-GCM via the Web Crypto API. The server stores ciphertext and nothing that can decrypt it.
  • The key travels in the URL fragment, which browsers never send to the server — so the one piece needed to read the note is the one piece the server is architecturally incapable of receiving.
  • Destruction rules you choose: expire on a date, cap the number of views, or burn after a single read.
  • Optional password on top of the link, for when the link itself may be seen by the wrong person.
  • Markdown and raw code blocks, because most things worth sending privately are configuration, credentials or code.
  • No account required to write or read one.

Architecture & Technical Implementation

The whole design turns on one detail of how URLs work: the fragment after # is never sent to the server. The encryption key lives there. The server receives the ciphertext and the note ID; it never receives, and cannot log, request-log or subpoena, the key.

Encryption is AES-256-GCM through the Web Crypto API — the browser's own audited primitives rather than a hand-rolled or bundled crypto library. GCM is authenticated, so a tampered ciphertext fails to decrypt rather than quietly returning corrupted text.

Destruction is enforced server-side rather than client-side. A burn-after-reading note that relied on the client to report a read would be trivially bypassed by not reporting it.

Engineering Challenges & Solutions

"Trust us" is not a security model, and proving you don't need to be trusted is harder than being trustworthy. Anyone can claim client-side encryption. The work is in making the claim checkable: the security page documents exactly what crosses the wire and in which direction, so the architecture can be verified from outside rather than believed.

The genuinely hard trade-off is key placement. Put the key in the query string and it lands in server logs, referrer headers and browser history sync. Put it in the fragment and it stays client-side, but you inherit every quirk of fragment handling — redirects drop it, some clients strip it, and it must survive the whole navigation to the decryption step.

The second is that encrypted data cannot be recovered. There is no reset link, no support override, no admin who can help. That is the point, but it means every failure mode has to be prevented at write time, because nothing can be repaired afterwards.

What Was Learned

Zero-knowledge is mostly an exercise in removing capabilities from yourself. Every convenience — search, previews, recovery, moderation, "just check what the note said" — requires the ability to read the data, and the moment you keep that ability the guarantee is gone.

Building it clarified how much ordinary software quietly depends on the operator being able to see everything, and how much has to be redesigned once that is off the table.