Protocol version 1
What gets encrypted, and where.
The useful claim is not “military grade.” It is a small, inspectable protocol built from browser standards and narrow server responsibilities.
Encryption
Secrets are encoded as UTF-8 and encrypted in the creator's browser with AES-256-GCM and a fresh 96-bit initialization vector. GCM provides confidentiality and detects modified ciphertext.
Optional passphrases
A blank passphrase creates a fresh 256-bit AES key with crypto.getRandomValues(). That key is placed in the URL fragment, which
browsers do not send to the server, so the full link is enough to open the secret. When
a passphrase is added, it is converted into an encryption key using PBKDF2-HMAC-SHA-256
with 600,000 iterations and a fresh 128-bit salt. It is not uploaded or included in the
link.
One-time retrieval
Opening the link does not consume anything. Only the Reveal and copy action sends a POST request. Redis retrieves and deletes the ciphertext in one atomic operation, preventing two recipients from successfully revealing the same stored secret.
After retrieval
Decryption occurs in the receiver's browser. Plaintext is held only in JavaScript memory for the selected copy window and is never rendered into the page. When the timer ends or the page is left, the application drops its reference to the plaintext.
Threat boundaries
Anyone with a link-only URL can consume its secret. When a passphrase is added, anyone with both the link and passphrase can consume it, so the extra protection depends on sending those two pieces through genuinely separate channels. The design cannot defend against malicious browser extensions, device malware, clipboard history, or a recipient who keeps what they copied.