Privacy

// request mode (trust note)

Request links let someone else send a secret to the link owner. The submitter's browser encrypts locally — the server still never sees plaintext — but the AES key has to reach the owner somehow. We do that by emailing them a one-time inbox URL with the key in the URL fragment:

https://share.izzy.agency/app/inbox/<id>#k=<keyB64u>&iv=<ivB64u>

The server holds the key in worker memory only for the duration of the submission request (long enough to call the email provider) and then forgets it. It is never persisted in our databases or logs.

The trust boundary moves to your inbox. If your email is compromised (or your provider is asked nicely), the submission is compromised too. The same applies to forwarded inbox URLs. Treat the email like a one-time key — open it from a secure device, then let it expire or delete it. Defense-in-depth options (passphrase, Turnstile) are coming in a future release.

// share URL email delivery

When creating a share, the sender can tick "email the URL directly to recipient". With that opt-in, the sender's browser hands the full URL — fragment included — to the worker, which immediately passes it to Resend:

https://share.izzy.agency/en/s/<id>#k=<keyB64u>&iv=<ivB64u>

The worker holds the URL in memory for a single HTTP call and then drops it. It is never written to D1, KV, R2, or logs. The only audit fact recorded is that a share_url_emailed event happened for this share id — no URL, no plaintext address.

Same trust boundary as request mode: the recipient's inbox becomes the vault. If you'd rather deliver the link out-of-band (Signal, in person, your own encrypted channel), just leave the checkbox unticked and the URL never leaves your browser.

You can also add an optional passphrase on the create form — it is hashed in your browser (PBKDF2) and acts as a second factor the recipient must enter before the ciphertext is released.