Security FAQ

No — and it's not a policy promise, it's how the system is built.

Secrets are encrypted in the browser before they leave your or your client's device. The encryption keys are never sent to the server unencrypted. Only someone with the PIN and/or recovery phrase can decrypt the keys.

Even if we wanted to, we couldn't.

Yes. Files work exactly like text secrets. A unique key is derived in your browser for each file. The file is encrypted client-side before upload.

The file and filename we store are ciphertext. We only store the MIME type for validation purposes.

When a recipient opens a protected share link, they're asked to enter their email address. We send a one-time code to that address. They enter it, we verify it, and then their browser proceeds to decrypt the secret locally.

The secret is only revealed after the OTP is verified. If someone intercepts the link but doesn't have access to the target inbox, they can't get in.

We store metadata about events — not the content of events. Specifically:

• When a share or request was created
• When it was opened and by whom (email, if verified; IP address when available)
• How many times it was accessed
• When it expired or was revoked

We do not store the plaintext contents of secrets, files, or intake submissions.

No. Recipients open a link — they don't need to sign up for anything. Email OTP verification (if enabled) confirms their identity, but no account is required.

For intake requests, clients submit through a branded form with no login or registration.

• Secrets and files: XChaCha20-Poly1305 authenticated encryption
• Request key exchange: X25519 sealed boxes
• Key generation: cryptographically random 256-bit keys
• PIN / passcode derivation: Argon2id (memory-hard, moderate cost parameters)
• Transport: TLS 1.2+

When you rotate your workspace keys, each member's access is re-established with the new key, and new activity uses it. Previously shared links keep working — they carry their own keys — and items already stored in your workspace stay readable under the key version they were created with. Nothing you've shared is lost by rotating.

Key rotation is a good practice after a team member leaves.

The audit log is append-only. When you delete a submission or revoke a share, the audit log records a deletion event — but the original event record stays. The log grows; it doesn't change.

This means you can use the audit trail as evidence: it reflects what actually happened, not what someone later wished had happened.

We can produce the metadata and audit events we store. We cannot produce plaintext secrets or file contents — we don't have them. The encrypted blobs we hold are useless without the keys, which we've never seen.

This is an architectural property, not a legal one.