Passband is an email client for Mac and iOS. Behind it runs squelchd, a daemon that syncs your Gmail mailbox, triages it, and lets you act on it. This policy explains what data the software touches, where that data lives, and what reaches infrastructure we operate.
Two tiers, two very different answers
Passband is offered in two forms, and the honest answer to "where does my mail live" is completely different in each. Read the one you use.
Self-host
You run squelchd on hardware you control. Your mail, your search index, and your Google OAuth tokens are stored on your machine and never transit or rest on our infrastructure. We could not read your mail if we wanted to; we hold no copy and no key. The only things that ever reach us are the optional relay services described below, which carry timing and opaque identifiers and never message content.
Hosted (Passband accounts at signup.passband.app)
We run squelchd for you, one isolated instance per account, on infrastructure we operate. Your mail content and your Google refresh token are stored on our servers. Holding them is what the hosted tier is; always-on triage and mobile push are not possible otherwise. The rest of this policy sets out exactly what we hold, how it is protected, who can reach it, and how to get rid of it.
Google user data
Passband accesses Gmail, and optionally Google Calendar, through Google APIs with your consent, using OAuth. It requests exactly these scopes and nothing else:
| Scope | What it is used for |
|---|---|
gmail.modify |
The one Gmail permission. Read: sync message headers and bodies so the daemon can triage them, render threads, search them, and extract deadlines, shipment tracking, and calendar details. Change: apply the outcome of a triage or an explicit user action (archive, label, mark read or unread, park a thread for later). Send: mail you compose in Passband, such as replies, forwards, new messages, and invitations you choose to share from your own address. It cannot permanently delete mail. |
userinfo.profile |
Read the name and profile photo on your Google account, to greet you by name and show your photo on the account switcher. Optional: you can untick it on Google's consent screen and everything else works. The photo is copied once to your daemon and served to your own devices from there. |
calendar.events |
Optional. Read the events on your calendars, and create, change, or delete an event only when you do it in Passband (adding guests sends Google's own invitation). Asked for at signup so it never needs a second consent; until calendar is available on your account, nothing reads or writes your calendar with it. You can untick it on Google's consent screen and everything else works. |
calendar.calendarlist.readonly |
Optional. List your calendars and their colours, so events show on the right calendar. Read only. |
userinfo.email, openid |
Confirm which mailbox a token belongs to, and identify your account at sign-in. The daemon refuses to store a credential whose mailbox does not match the configured account. |
Passband asks Google for one Gmail permission, granted in a single
consent at signup (or at squelchd auth on self-host); a
consent without it sets nothing up. That permission can read and write;
see Security below for how Passband keeps sync away from writing.
Every write action is user-initiated or the direct result of a rule you configured, and is recorded in an audit log on your own daemon.
Limited Use disclosure
Passband's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. In particular:
- Google user data is used only to provide and improve the user-facing features of Passband: triaging, displaying, searching, and acting on your mail at your direction.
- It is never sold, never used for advertising or ad targeting, and never transferred to third parties except as explicitly described in this policy.
- No human reads it except with your explicit consent, for a support request you have made, or where required for security investigation or legal compliance.
- Google user data is never used to develop, improve, or train generalized or non-personalized artificial intelligence or machine learning models. Where message content is sent to a model provider (see below), it is sent for inference on your own mail only, under terms that prohibit training on it.
Where your data is stored
Self-host
Message content and metadata are stored in a local SQLite database on your machine. OAuth tokens are stored in your operating system keychain (macOS) or a credentials file with restrictive permissions in a location you designate (Linux). Neither ever transits or rests on our infrastructure.
Hosted
Each hosted account gets its own isolated daemon instance and its own SQLite database on a dedicated volume, on a server we operate at Hetzner Cloud in the United States. Specifically, we hold:
- Your synced mail. Message headers, bodies, attachments, labels, and derived triage data, in your account's own database.
- Your Google refresh token, encrypted to a per-account key that exists only as an encrypted-at-rest secret in our cluster. Our signup and control-plane services do not retain the plaintext token after provisioning.
- Your account record: the email address you signed up with, your account label, timestamps, and the invite you used. This is stored in a managed PostgreSQL database (Amazon RDS) at AWS.
- Encrypted backups. Your database is continuously replicated to Cloudflare R2 object storage, encrypted before it leaves our server with a key held outside that storage, as a rolling 24-hour window. Hetzner keeps 7 days of snapshots of our server's system disk, which holds the encrypted per-account keys but no mail.
We do not have per-account access controls that would prevent our own operators from reaching a hosted account's data: as with any hosted service, whoever administers the servers can in principle read what is on them. Access is limited to Passband operators, is used only for the reasons listed in the Limited Use disclosure above, and if you would rather not extend that trust to anyone, the self-host tier exists exactly for you and is free.
Automated processing by language models
Passband uses large language models to score importance, summarize threads, extract deadlines and shipment details, and power the built-in assistant. Where the request goes depends on your tier, and this is the most consequential difference between them.
Self-host: your own key, or nothing
These features are off until you supply your own Anthropic or OpenAI API key. With a key configured, the daemon sends message excerpts directly to that provider under your own account and their terms. With no key, triage runs on local heuristics only and no message content leaves your machine.
Hosted: our gateway, our provider account
Hosted accounts do not bring a key. Your daemon sends message content to
an LLM gateway we operate at bifrost.passband.app, which
forwards it to Anthropic under a Passband account, using
a per-account credential with a spending limit. Message content therefore
passes through our infrastructure and reaches Anthropic as a subprocessor.
Anthropic does not train models on this content. The gateway records
per-account token counts and spend so budgets can be enforced; message
content is not used for any purpose other than serving your request.
Login codes and password resets, on either tier
Security-sensitive mail (verification codes, one-time passcodes, sign-in links, password resets, and similar) is sealed as soon as it is recognized. Recognizing it is the triage model's job, so the triage model reads each such message once, as it reads every other message, under the same no-training terms as the rest of your mail. Sealed mail is never exposed to the assistant and never crosses the agent-facing interface.
Services we operate
| Service | What it sees |
|---|---|
| Push relay | Device tokens, opaque event identifiers, and the Gmail thread identifier used to collapse repeat alerts, forwarded to Apple Push Notification service with a fixed alert text. It retains nothing and never sees message content, senders, or subjects. |
| Read receipts (opt-in) | If you enable open tracking on mail you send, the pixel records an opaque token, a timestamp, and a user agent string. On a hosted account the pixel is served by your own daemon at your account's address, so these never pass through the relay; the recipient's mail client fetches it from that address, which therefore appears in the tracked email. On a self-hosted daemon that uses our relay, the relay briefly buffers them until your daemon collects them. Only your daemon can map a token back to a message. Collected entries are deleted from the relay, and uncollected ones after 90 days. |
| LLM gateway (hosted only) | Message content in transit to Anthropic, plus per-account token and spend accounting. Request and response bodies are not retained. |
| Signup and control plane (hosted only) | Your email address, account label, invite code, and provisioning state. Also the waitlist form: an email address and whatever you type into it. |
Relay logs contain request timing and status codes only. Device tokens, open tokens, and payloads are never logged.
Subprocessors
These third parties process data on our behalf for the hosted tier. Only Anthropic and our own hosting providers ever handle the content of your mail. Browserbase receives one thing taken from a message, the sender's unsubscribe link, and only when you ask to unsubscribe from that sender.
| Provider | Purpose | Handles mail content |
|---|---|---|
| Hetzner Cloud | Servers running hosted daemons | Yes (at rest and in memory) |
| Cloudflare | Encrypted database backups (R2), DNS | Encrypted only |
| Anthropic | Language model inference | Yes (in transit, no training) |
| Amazon Web Services | Signup, control plane, relays, gateway hosting | Gateway transit only |
| Resend | Sending invite email | No |
| PostHog | Product analytics (see below) | No |
| Browserbase | A remote browser that finishes an unsubscribe on the sender's page, when you ask to unsubscribe and that page needs one | No message text. The sender's unsubscribe link, the page it opens, and your email address if the form asks for it. Not recorded |
| Apple | Push notification delivery | No |
| WorkOS | Sign-in for AI agents you connect to your mailbox (AuthKit) | No. Your email address, and the grants you approve for each agent |
Third parties you direct us to, on either tier
- Shipment carriers. If you configure your own carrier API credentials (UPS, FedEx, DHL, USPS), your daemon sends tracking numbers it found in your mail directly to that carrier to fetch delivery status. We never proxy a carrier call. With no credentials configured, no carrier is ever contacted.
- Your own model provider. On self-host, the API key you supply determines who receives message excerpts, under your account and their terms. We are not a party to that flow.
- People you write to. Mail you send, forward, or share an invitation to goes from your own Gmail address to the recipient you chose. Invitation recipients are never disclosed to us.
What the apps fetch directly
Two kinds of request go from the Passband apps straight to a third party, not through us, on either tier:
- Remote images in email. By default the apps load images in a message directly from the sender's servers, with cookies and referrers off and known tracking pixels removed. The sender's server sees your IP address and that the image was requested. Set images to On demand in Settings to load none until you ask.
- Sender icons. For automated senders (newsletters, receipts, notifications), the apps fetch the sender domain's icon from DuckDuckGo's icon service. It receives the domain, not the message or your address.
App telemetry
The Passband apps report anonymous usage events (for example, "an email was archived") to PostHog to help us understand which features are used. Event names and property values come from a fixed allowlist enforced in code: message content, subjects, senders, recipients, labels, and search queries are structurally unable to leave the app through this channel. At the default level the Mac app also records the layout of each session: the window as plain grey boxes with the app's own icons, and where you clicked. Text, pictures, colors, what you type, and anything inside an email are never recorded; a line of text becomes a blank bar of roughly its length, and an email's body is one empty box. The layout does show which kinds of cards and icons were on screen, such as a bill or a package. This helps us see where the app is confusing. For self-hosted installs, events are keyed to a random per-install identifier and PostHog is never told who you are. For hosted accounts, events are keyed to an account identifier, and we also give PostHog the email address and name you signed up with, so we can tell which account a session belongs to when we support you. Deleting a hosted account deletes this record in PostHog too. You can reduce or disable telemetry in Settings under Privacy; any level below Full turns recording off.
Retention and deletion
Self-host: your data is retained on your machine for as long as you keep it. To delete everything, delete the local database and credentials (or keychain entries) and revoke Passband's access at myaccount.google.com/permissions. We hold no copy, so there is nothing for us to delete.
Hosted: your mail is retained for as long as your account exists. To delete it, email us at the address below. Within 30 days we destroy the account's database and volume, its encryption key and stored refresh token, every backup of it in object storage, its LLM gateway key, and its account record, and confirm to you in writing. The encrypted per-account key survives only in Hetzner's snapshots of our system disk, which hold no mail and age out within 7 days. Revoking Passband at myaccount.google.com/permissions immediately ends our access to your mailbox on either tier, and is effective whether or not you have asked us to delete anything.
Security
Passband's one Gmail permission can read and write, so the separation is kept in Passband's own code: the sync pipeline loads its own credential slot and has no code that archives, labels, or sends. Agent-facing interfaces never expose security-sensitive mail; agents can leave drafts for you to review, and can send only if you turn sending on, with your approval for each message. Self-hosted daemons bind to loopback by default. Hosted accounts are isolated from one another at the container, network, and storage layers, and each has its own encryption identity. Secrets are encrypted at rest. A summary of these controls, our subprocessors, and retention is at passband.app/trust; the full threat model is public at passband.app/security.
To report a vulnerability, email the address below. We will acknowledge within 72 hours.
Children
Passband is not directed to children under 13 and we do not knowingly collect data from them.
Changes
Changes to this policy will be posted on this page with an updated effective date. Material changes to what we collect or who receives it will also be announced to hosted account holders by email.
Contact
Questions about privacy, deletion requests, and vulnerability reports: braelyn@passband.app.