What we can and cannot see
Hider is built so that trusting us is not the thing keeping your secret safe. Here is exactly how that works, and where it stops.
How a secret travels
In your browser
A fresh AES-256-GCM key is generated for this one secret, with a random 96-bit nonce. Your text is encrypted before any request is made. What you typed never leaves the tab.
On the way out
Only the ciphertext, the nonce and how long it should live are sent to the API. The kind of secret and any username are sealed inside the ciphertext, so the server cannot even tell a password from a note.
In the link
The key is put in the part of the URL after the #. Browsers never send that part to a server, so it reaches the person you share the link with and no one in between.
On the way back
The first request for a secret deletes it from storage before the response body is sent. A crash mid-response therefore loses the secret rather than serving it twice.
What the server holds
It can see
- The ciphertext and its nonce
- How large the secret is, up to the 64 KB ceiling
- When it should expire
- The random id in the link
It never sees
- The key — it stays in the URL fragment
- Your secret, in any readable form
- Whether it is a password, a key or a note
- Any username sealed alongside it
This describes a link made in a browser, which is every link made at hider.sh. A link made for you by an AI assistant through our connector is the exception: it is encrypted on our server, because a remote assistant cannot do it. That is set out in full below.
The specifics
- Cipher
- AES-256-GCM, via the Web Crypto API
- Nonce
- 96-bit, random per secret
- Key handling
- Generated in the browser, never transmitted
- Link id
- 10 characters, ~58 bits of entropy
- Storage
- Cloudflare R2, ciphertext only
- Maximum size
- 64 KB of ciphertext
- Maximum lifetime
- 7 days
Where it stops
Things a security page usually leaves out. They are trade-offs we chose on purpose, not oversights.
The link is the secret
Anyone holding the full link can open it, because the key is part of it. Send it through a channel you trust, and treat a forwarded link as a spent one.
We cannot recover anything
There is no copy to recover from and no reset. If the link is lost before it is opened, the secret is gone, and if it is opened by the wrong person there is nothing to revoke.
A wrong key still spends the link
The object is deleted as soon as it is fetched, before decryption is attempted. That is deliberate — it keeps a single read single — but it means a mangled link burns the secret.
It needs https
Web Crypto only exists in a secure context. Rather than fall back to something weaker, creating a secret refuses outright over a plain connection.
A link made by an assistant is encrypted on our server
Everything above describes a link made in your browser. When ChatGPT or Claude makes one through our MCP connector, the text is sent to us and encrypted there, because a remote assistant cannot run that step itself. It is never written to storage unencrypted and the key is returned only inside the link — but for those links, and only those, the browser is no longer the only place that saw the secret. Your assistant provider has also seen it, as it would anything you type into a chat.
Emailing a link hands it to us
Copying a link keeps the key in your browser. Asking us to email it cannot: the message has to be written somewhere, so the whole link, key included, is sent to our server and on to our mail provider. It is used to build one message and kept nowhere afterwards — but it is the one moment we could read the secret, and it only happens when you choose to send rather than copy.
A scanned QR is a copy the link cannot expire
Wi-Fi and calendar links offer a code that the camera acts on directly, so the network or the event lands on the phone rather than travelling anywhere. Once scanned, that copy belongs to the phone: expiring the link deletes our stored secret, not the network the device has already joined.