What is a one-time secret link?
It is a way to send access to a sensitive value instead of placing the value directly in a message. The service enforces an expiry and a reveal limit. With SecretBridge.app's public browser flow, the browser encrypts the value before upload and decrypts it in the recipient's browser.
The default is ten minutes and one reveal. If you select two reveals, it is a limited-use link rather than a strictly one-time link. Choose the smallest limit that fits the actual handoff.
Why the part after # matters
The complete SecretBridge browser link includes a fragment after #. That value derives distinct access and decryption material on the device. Browsers do not put the fragment into the ordinary HTTP page request; the application uses the derived access capability when it requests the encrypted envelope.
This keeps the content key out of SecretBridge's public-link storage path. It does not make the fragment harmless: a copied full link can give another person what they need to open the secret. Browsers, clipboard tools, extensions, screenshots and messaging clients may still handle the full string.
Protect the complete link like a temporary password. The From and Recipient fields are display labels in this flow, not an identity check. SecretBridge cannot recover a lost fragment for you.
Burn-after-reading and expiry solve different problems
A reveal limit ends further access after the selected number of authorised reveals. Expiry ends access after a deadline, even if nobody opens the secret. Together, they reduce the opportunity for an abandoned message to remain useful indefinitely.
Neither rule can erase an already revealed value from someone's memory, clipboard, screenshot or another system. A successful response can also be lost after a reveal was committed; distributed systems cannot guarantee that a recipient actually saw bytes merely because an operation completed. Do not use a last remaining reveal as your only recovery plan.
What does an extra passphrase add?
The optional passphrase adds a separate access requirement. It is not embedded in the generated reveal link. Send it through a different channel, and use a value that is not easy to guess. It is an access control, not a replacement for keeping the fragment secret or verifying who receives the link.
Do not send a passphrase, full link or secret value to customer support. A safe report includes an error message and approximate time, without the access material.
How are Slack and Teams different?
The Slack integration and Teams integration can bind a protected reveal to platform identity. That is useful when a display label is not enough. Some protected platform flows decrypt on the server; an enrolled-device flow can use recipient-held keys instead. The browser's choice of handoff determines that boundary.
Read the security overview rather than assuming that every mode is server-blind. The browser-link mode described here is separate from native or protected platform reveals.
Does burn mean every backup is unrecoverable?
No blanket claim is appropriate. For server-readable modes, an encrypted backup and access to the separate wrapping key can leave a bounded recovery window. In server-blind browser-link mode, a database backup alone lacks the content key. The current retention disclosure and security model explain the distinction.
A simple rule for choosing the tool
Use a one-time link for a necessary, short-lived handoff. Use a shared password manager or a provider's own access controls for continuing collaboration. Where possible, send a scoped, temporary credential rather than a master password. Rotate it after use when the consequences justify the extra step.
Ready for a practical workflow? Read how to share passwords in Slack without leaving them in chat, or create a free encrypted link.