Security overview

DRAFT — pending legal review. This page describes the design as built for the private alpha. The independent security assessment required by Google for Gmail API access is planned but not yet complete; the "unverified app" warning you see at sign-in will disappear once it is.

Principles

• Write-only Gmail access. The only Gmail permissions requested are the ones that add messages and create labels. The service cannot read, search, modify, send or delete existing Gmail data, by permission and by code.
• Mail is never stored. A message exists only in the memory of the single short-lived process that copies it from the source to Gmail. There is no queue, spool, cache, object store or database that holds mail, and the maximum message size (50 MB) is checked before a message is downloaded.
• Least privilege for secrets. Mailbox passwords and the Gmail token are encrypted with per-purpose keys in a hardware security module before being written. The process that talks to your mailbox cannot decrypt them itself: for each sync it must present a single-use, short-lived capability to a separate broker component, which releases the password for that one sync only and never releases the Gmail token at all (it hands out a short-lived access token instead).
• Nothing deletes at the source without consent. Delete-from-source is off by default, POP3-only, requires an explicit consent text, never runs during the verification pass, and only applies to messages Gmail has confirmed by id.

Transport

• All connections to source mailboxes use TLS 1.2 or later with certificate and host-name verification, either implicit TLS (ports 993/995) or STARTTLS (143/110) that fails closed if the upgrade is refused. Plaintext is never used and never falls back.
• Only mail ports are reachable from the sync component, and only public addresses: private networks, cloud metadata addresses and the service's own network are refused, including after DNS resolution.
• Google is reached only over HTTPS at Google's own API endpoints.
• The web app is served over HTTPS with HSTS, a strict Content Security Policy (no inline scripts or styles, no third-party resources), frame-ancestors none, and same-origin resource policies.

Accounts and sessions

• Sign-in is Google's OpenID Connect flow with PKCE, state and nonce checks, and a browser-bound transaction cookie. Sensitive actions (disconnecting Gmail, replacing a password, enabling delete-from-source, exporting or deleting your account) require a fresh re-authentication with Google.
• Sessions are HTTP-only, secure, host-locked cookies; only a hash of the session identifier is stored. Every change requires a CSRF token and an origin check. "Sign out everywhere" invalidates every session at once.
• Rate limits apply per user, per source and per network address.

Operations

• Everything runs on Amazon Web Services in the EU (Ireland). There are no long-running servers to patch: each component is an isolated function with its own narrowly scoped role.
• Logs never contain credentials, tokens, message content, or a host name together with a user name; e-mail addresses are masked by a data-protection policy on the log store. Logs are kept 90 days. Key usage is audited.
• Support staff do not have a tool that shows mailbox host names or user names.

Deleting your data

Deleting your account destroys the encrypted secrets first, then revokes the Gmail grant at Google, then removes every record. The deletion works even when Google cannot be reached (the grant can then be revoked from your Google account settings), and produces an anonymous receipt you can check afterwards. Mail already imported into Gmail is yours and stays in Gmail.

Reporting a vulnerability

Please report security issues privately to the security contact that will be published here after the legal review; until then, use the contact address given in your alpha invitation. Please do not test against other users' data. We aim to acknowledge reports within two working days.