How Secret Link encryption works

When you create a secret, your browser generates a random 256-bit key and encrypts the text locally with @shieldfive/crypto (XChaCha20-Poly1305). Only the ciphertext is sent to ShieldFive. The key is placed in the link after the “#” — the URL fragment — which browsers do not send in HTTP requests. So the key reaches the recipient through the link, never through our servers.

We are honest about the limits of any hosted, browser-delivered tool. The server can see: the size of the ciphertext, the time a secret was created and read, and the IP address that connected (which we hash for abuse-prevention, never storing it raw). The server also delivers the JavaScript that runs the encryption.

What the server cannot see: the plaintext, or the key. Both stay on the devices of the sender and the recipient.

Because the encryption code is served by us each time the page loads, a compromise of ShieldFive could in principle serve malicious code. We reduce that risk with a strict Content-Security-Policy and no third-party scripts on the create and view pages, and the crypto core is open source so it can be reviewed independently. This is the honest ceiling of any web-delivered end-to-end tool; we do not claim to defeat it entirely.

The first time a link is opened, the server returns the ciphertext and immediately deletes it. A second visit finds nothing. There is one honest trade-off: if the network drops after the delete commits but before the reader receives the response, a one-view secret can be lost. If a recipient says the link is already spent, create and send another.

Ciphertext is stored in the EU and deleted on read or expiry. There is no analytics or third-party tracking on the create or view pages. For the full company security posture, see /security.