Your browser encrypts what you share

Passwords, usernames and notes are encrypted on your device before they reach us. We add a second layer of encryption before storing them. Each layer uses a separate key, so our storage key cannot unlock your secrets.

The key needed to read a share is included in the link, after the # sign. Your browser keeps that part of the link out of the requests it sends to our servers. Anyone with the full link can open the share, unless you also add a passphrase. Treat the link like the password itself.

A link works once

Opening the page leaves the share untouched. The recipient must press Reveal with a valid link and any required passphrase. We then send the encrypted contents to their browser and delete them from active storage. Their browser decrypts them for viewing.

The same link cannot retrieve those contents again, even if two people try at the same time. Ordinary messaging-app link previews do not use up a share. If a connection fails during a reveal, however, the link may already have been used. The sender will need to create a new one.

Recipients can copy, download or take a screenshot of what they receive. Deleting a share cannot remove those copies.

Add a passphrase for extra protection

With a passphrase, the recipient needs both the link and the phrase to read the contents. The phrase stays in their browser; we receive a value derived from it to check whether it is correct. Choose a strong, unique phrase, or use the one we suggest, and send it separately from the link.

You choose how many incorrect attempts are allowed. Once that limit is reached, the share is deleted. Someone needs the full link to use up those attempts. These limits protect attempts through our service.

Shares have an expiry date

You choose how long a link stays available. Even “Until revealed” links expire after 30 days if unused. Expired shares stop being available immediately. Cleanup runs every minute to remove their encrypted contents, though an outage or backlog can delay that removal.

Deletion removes the share from our active database. The privacy policy explains what we store and how long it is kept.

Your account and sharing history

You can share without an account. If you create one, we store a one-way hash of your login password, rather than the password itself. Every login also requires a six-digit email code, including on a device you have used before. Codes expire after ten minutes and allow five attempts. We limit authentication requests to make automated guessing harder.

Password-reset links work once and expire after 30 minutes. A successful reset signs out all devices. Recovery resets are limited to once every seven days; you can still change your password in Settings while signed in. Settings also lets you review and sign out other devices.

Your sharing history shows what happened to a link, such as whether it was opened or expired. It cannot recover the shared contents or recreate the full link. Any label you add to that history is stored without encryption, so keep passwords and other secrets out of labels.

Requesting information with Two-way

Two-way lets you ask someone to send you passwords or other sensitive information. Your request link accepts one response and requires a separate passphrase, with a five-attempt limit. That link lets someone submit information; it does not let them read the response.

Their browser encrypts the response for your vault. To read it, you must sign in and unlock the vault with its own password. We receive neither that password nor the unlocked encryption keys. A response can be revealed once and expires seven days after submission. Viewing your dashboard does not use it up. As with a share, an interrupted reveal may require a new request and response.

Your vault password is separate from your account password. Resetting your account password will not unlock the vault. Set up a recovery key in Settings and keep it somewhere safe outside the vault. It can help you regain access if you forget the vault password, but it cannot restore responses that were already revealed or expired.

If you lose both the vault password and its recovery key, you can reset the vault to start again. Doing so cancels outstanding requests and deletes stored responses.

A few things you can do

Send links only to the intended recipient. Send any passphrase through a separate channel.
Choose the shortest expiry that gives the recipient enough time.
Keep your browser and device up to date. Encryption cannot protect information displayed on a compromised device or read by a malicious browser extension.
Change a shared password when the recipient no longer needs access.

Encryption and authentication details

Share encryption: AES-256-GCM in the browser and again in storage, with separate keys. Links use a random 128-bit identifier and a random 256-bit key. The identifier alone cannot retrieve or delete a share.
Passphrases and vault passwords: Argon2id with 64 MiB of memory, three passes and one lane. The server checks a hash of a derived verifier for share passphrases.
Two-way responses: ephemeral P-256 key agreement, HKDF-SHA256 and AES-256-GCM. The sender's browser checks the request's public-key fingerprint before encrypting the response. Private keys are encrypted under the vault key, which is itself protected by the vault password.
Account passwords: salted scrypt hashes. Session tokens are stored as hashes and sent in Secure, HTTP-only cookies over HTTPS.