relay // legal

Security Overview

last updated

Tento dokument je v angličtině a závazná je anglická verze. Překlad neposkytujeme, aby nevznikly rozdíly ve významu.

A short, factual account of how Relay protects your mail and data. We are a small team and we do not hold security certifications; what follows is what the product actually does.

1. On your Mac and iPhone #

  • The apps talk directly to your mail provider. Your mail is stored on the device, not on Relay's server.
  • Mailbox passwords and Google tokens are kept on the device: on the Mac encrypted with a key held by the macOS Keychain, on the iPhone in the iOS Keychain, available only on that device after first unlock. They are never stored on Relay's server.
  • Connections to Gmail and the providers Relay sets up use TLS by default. For a server you set up yourself, Relay uses the security that server offers.
  • Tracking pixels in the mail you receive are blocked by default, and email is shown in a sandbox where no script in it can run.

2. On Relay's server #

  • In transit: everything goes over HTTPS, behind Cloudflare's network and DDoS protection.
  • At rest: the database and file storage are encrypted by Cloudflare. On top of that, the personal content Relay's server keeps (synced settings and notes, assistant cards, contact photos, descriptions of tracked messages, feedback notes) and every stored secret are sealed with AES-256-GCM, using keys derived from a master key kept as a secret outside the database. This is encryption at rest, not end-to-end encryption: the server can decrypt it to provide the service.
  • Hashed, not stored: the IP addresses of people who open tracked mail, and of people signing in, are stored only as salted, truncated SHA-256 hashes. Refresh tokens and web session identifiers are stored only as hashes.
  • AI requests pass through without their content being stored; only what they were for and what they cost is recorded.
  • Sessions: access tokens are signed and last an hour; refresh tokens rotate on every use, and reusing an old one signs the device out. A device, or every device, can be signed out at once.
  • Large-file links are 24 random characters (about 143 bits), expire after 30 days, and are always served as downloads that cannot run as a page on our domain.
  • Rate limits protect sign-in, codes and the API.

3. Relay on the web #

  • Each person's mail is handled by a separate process with access only to that person's own folder (Node's permission model), memory limits, and no access to the server's secrets.
  • Mailbox passwords and tokens are sealed with AES-256-GCM under a key derived for that person alone. The disk is encrypted at rest by Fly.io, in Amsterdam.
  • Every call from the browser is checked: known methods only, typed and size-limited arguments, and files only inside the person's own folder.
  • Mail server addresses are checked before every connection, so Relay cannot be used to reach internal networks.
  • The session cookie is HttpOnly, Secure and SameSite, limited to /app. The pages have a strict content security policy with no inline scripts, and send HSTS.

4. Who can access what #

Administrative access is limited to named administrators, who sign in with Google; their actions are recorded in an audit log. The admin tools show accounts, devices, usage and costs; they do not show your mail. On Relay on the web, administrators with access to the hosting could in principle access the server's disk; we access it only to keep the service running, on your request, or when the law requires it.

5. Reporting a vulnerability #

If you find a security issue in Relay, please tell us at marek@diferentlabs.com with "Security" in the subject. Include what you found, how to reproduce it and its impact. We will acknowledge your report within three business days, keep you updated, and credit you if you wish once it is fixed.

  • Please give us reasonable time to fix an issue before you disclose it.
  • Test only with accounts and data that are yours; do not access, change or delete other people's data, and stop as soon as you reach any.
  • No denial-of-service, spam, social engineering or physical attacks.

We will not pursue legal action against good-faith research that follows these rules. We do not currently run a paid bug bounty.

6. Incidents #

If a security incident affects your personal data, we will tell you without undue delay, and notify the authorities where the law requires.