Share a secret. Once. Then destroy it.
Encrypt a sensitive message in your browser and share it with a one-time link. BAOI never receives the decryption key.
The key is in the URL fragment (#k=…) and is never sent to BAOI.
Why not send a password by email?
Email, chat and ticket histories are designed to retain messages. A password copied into them can remain accessible in archives, backups and forwarded conversations long after the original need has disappeared. BAOI Secret replaces the sensitive value with a short-lived one-time link.
How browser-side encryption works
Your browser generates a random 256-bit key and encrypts the message locally with AES-256-GCM before any secret payload is sent. The key stays after the # character in the shared URL. URL fragments are not included in the HTTP request, so BAOI receives the encrypted payload but not the decryption key.
What BAOI stores
Only encrypted data, an IV, expiry metadata, a hash of the public token and an unlock verifier are stored. The plaintext, random AES key and optional passphrase are never stored by BAOI.
Why link previews do not consume the secret
Opening the URL with GET only displays a secure shell. Outlook, Teams, antivirus scanners and social previews therefore cannot consume the encrypted record. Destruction requires an explicit unlock POST carrying a verifier derived from the fragment key.
What happens after reading?
Consumption is transactional: BAOI locks the row, validates the request, deletes the encrypted record and commits before returning it to the browser for local decryption. A second request receives an unavailable response. Expired secrets are also unavailable even if cleanup has not run yet.