What CrowdInbox does with data

This is the plain description the other privacy documents build on, and the one to keep honest: if the app changes, this file changes first. Nothing here is a promise about the future: it is a description of the code in this repository.

The short version

For mail, the app talks to your mail provider and to nobody else. No CrowdInbox server is in that picture: no account is needed, no sign-up, no analytics, no crash reporting, no telemetry. Mail is fetched from your own IMAP server and sent through your own SMTP server, both directly from the device in front of you.

ServerCrowd’s relay comes into it for three things, each of which somebody has to reach for: the two relay features described below, and CrowdInbox Plus with its optional account.

Where things are kept

Everything the app “syncs” therefore lives either on the device or in the user’s own mailbox. ServerCrowd operates none of it.

What leaves the device

• To the mail provider the user configured: IMAP and SMTP traffic. That is the product. Connections are TLS or STARTTLS; an unencrypted connection is refused except to localhost (for the test servers in test/docker-compose.yml).
• To servers a mail author chose, and only on request: remote images, styles and fonts inside an HTML mail. They are blocked by a Content-Security-Policy until the user loads them once or trusts that source (ADR 0007). This is what stops a sender learning that a mail was opened.
• To a newsletter’s sender, and only when the user presses Unsubscribe: one request to the address the message’s own List-Unsubscribe header names, or one short mail from the user’s own address to the address it names (ADR 0021). The request carries nothing but what RFC 8058 prescribes; no page is loaded and no script runs. It does tell that sender the address is read, which is what leaving a list means, and it happens only on that press.
• Nothing else. No usage statistics, no error reports, no “check for updates” call in the current builds, no advertising or tracking libraries in either app.

What the app never does

• It never sends mail, addresses or attachments to ServerCrowd.
• It never reads mail for advertising, model training, or any purpose other than showing it.
• It never uploads the address book; the “people” it knows come from mail already on the device.
• It never fetches remote content to make a decision about a mail (the Smart Inbox reads only what is already downloaded).

Sorting mail (the “Smart Inbox”)

Mail is sorted into People, Notifications and Newsletters by rules that run on the device and can be explained: headers (List-Unsubscribe, Auto-Submitted, Precedence, …), the sender’s address, whether the user has written to them, and words in the text. The reason for every decision is stored with the message and shown in the app (“Why is this in People?”). No profile is built, and nothing about it leaves the device.

On the iPhone, a future version may ask Apple’s on-device Foundation Models to decide the rare ambiguous case (M8). That runs on the phone; nothing is sent anywhere. It is not in the app yet.

Notifications

New-mail notifications are produced on the device from mail it already has: the desktop keeps an IMAP IDLE connection while it runs, and the iPhone checks when iOS grants it background time. On the iPhone, an account can also have instant notifications through the relay (opt-in, described below), whose push says only that mail came; the phone fetches sender, subject and the first lines of the text itself.

Pictures in notifications (iPhone)

A notification about new mail shows a picture of its sender. For a company or a service it is the icon of their website (github.com for GitHub’s mail), which the iPhone fetches from that website itself (at most once a month per website, without cookies) and keeps on the phone, so no sender learns when a mail arrives or is read. It reads the website’s front page to find out which icon the website names for itself, and then fetches that icon; no other service is asked, and nothing about the mail is sent. For an address at a mail provider (gmail.com, web.de, …) the picture is drawn from the sender’s initials, and nothing is fetched.

Contacts (iPhone)

Only if the user taps “Find People in Contacts” while writing, and allows it, the app searches the iPhone’s Contacts by name for addresses to write to. It reads nothing else from them, keeps nothing, and sends nothing anywhere.

Verification codes

A code a website mails to sign the user in is found on the device, when the message is stored or when a push brings it: a word that says “code” near a number standing on its own. It is shown with a Copy button (the clipboard lets go of it after ten minutes) and, on the iPhone, written to a small file in the app’s own App Group container together with the sender’s domain. If the user turns CrowdInbox on under Settings → General → AutoFill & Passwords, iOS is told which websites the codes are for, and the app’s AutoFill extension hands one to Safari when the user picks it. A code is kept a quarter of an hour, then removed from the file and from iOS’s list. Nothing about it leaves the device.

Summaries and reply suggestions (iPhone)

On request, the iPhone summarises a conversation or suggests replies with Apple’s on-device model (Foundation Models, part of Apple Intelligence). The core hands it each message’s own words (quoted history and signatures removed, the oldest messages left out when it is too long), and the model runs on the phone. Nothing is sent to ServerCrowd or to Apple for it, and nothing is kept: the summary lives as long as the screen shows it.

They are part of CrowdInbox Plus on an iPhone to which the App Store has offered Plus (the app remembers that it has, in its own preferences); where Plus cannot be bought, they are not locked. Whether the iPhone has Plus is StoreKit’s answer, on the device. Only an iPhone that is signed in to an account and has no subscription of its own asks the relay, and goes by its last answer for a week (see “CrowdInbox Plus” below).

The relay: instant notifications, opt-in (ADR 0020)

The relay runs on ServerCrowd’s own machines in Germany (Hetzner, Nuremberg/Falkenstein) and does one thing for the iPhone that it cannot do itself while CrowdInbox is closed: notice new mail.

Nothing reaches it unless the user turns on “Instant Notifications” for an account, one account at a time, after reading in the app (at that moment, not in a policy) what it means. Until then the phone keeps Apple’s push token to itself, and no device record exists at the relay at all.

For an account with it turned on, the relay holds:

• The account’s IMAP server, address and password. The password is tested, then sealed (AES-256-GCM, for that one row) with a key that lives only on the relay machines, never on the database machine, never in a backup. It technically allows the relay to read that mailbox; the relay is built to read nothing but the inbox’s message numbers, to notice that a new one arrived.
• The device: an Ed25519 public key (the private half stays in the phone’s Keychain and signs every request), whether it is an iPhone, Apple’s push token, and when the device was last heard from.

What it sends: to Apple, for the phone, “new mail” and a count, with no sender, subject or address. The phone’s notification extension then fetches the newest message’s header and first 24 KB itself, from the user’s own mail server, to show sender, subject and the first lines of the text and to find a verification code; none of it passes through ServerCrowd.

What it forgets: turning the switch off deletes the password at once, and turning off the last account deletes the device, unless it is signed in to an account (below), and then its push token is removed and the device record stays. A device silent for thirty days is deleted with everything it gave; a signed-in one loses its watches and their passwords after thirty silent days all the same, and the record that it is signed in (with the subscription it carries, which its account has through it) after four hundred. Logs are kept seven days. A password changed in the app is handed to the relay again, so it does not keep trying the old one.

Once the relay asks for Plus, a watch whose device has none is paused: the connection is closed and the password leaves the relay’s memory, while its sealed copy stays in the database. It runs again when the device has Plus again. Paused for thirty days, the watch and its password are deleted.

A device with a scheduled message still waiting at the relay (below) is kept until that message went, and the relay’s record that it went a month longer, so the phone can learn of it.

The relay: sending later, opt-in (ADR 0020)

A scheduled message goes out at its time only if a device of the user’s is awake then, unless the user turns on “Send Later Without the App” (on the iPhone under Settings → Mail, on the computer under Settings → Plus), after reading in the app what it means. Accounts that sign in with Google or Microsoft keep sending from the device. A computer that turns it on registers with the relay as an iPhone does, without a push token.

With it on, each scheduled message is handed to the relay when it is scheduled:

• The message itself, built as it will go out: recipients (Bcc included, as the envelope needs them), subject, text, attachments; and the account’s SMTP server, address and password. Message and password are each sealed (AES-256-GCM, for that one row) with the same key as above. The relay does not test the password when the message is handed over; it uses it once, at the time, to send the message through the user’s own mail server.
• The time to send it, and afterwards whether it went, failed (with a reason code) or waits for the mail server to be reachable again.

What it forgets: the message and the password are overwritten the moment the message went, or failed for good, after about a day of trying. What stays is that it went and when, until the phone has asked, filed its own copy in Sent and cleared the row, and at most a month after that. Changing, rescheduling or deleting the message before its time takes it back; turning the switch off takes back every message the relay holds. Nothing is passed to anyone but the user’s own mail server.

CrowdInbox Plus (ADR 0023, ADR 0025)

Plus is the two relay features above and, on the iPhone, the summaries. The relay does not ask for it yet: it has one setting for that, off until there is a price in force.

On the iPhone the purchase is Apple’s. StoreKit sells an auto-renewable subscription on the user’s Apple Account; ServerCrowd receives no name, no Apple ID, no address and no payment details.

• The proof is a transaction Apple signed. The app shows it to the relay when the relay asks for Plus, when somebody asks for a sign-in code (a code goes only from an iPhone the relay knows to have Plus), or when the iPhone is signed in to an account; the relay checks Apple’s certificate chain and signature itself, offline. Otherwise an iPhone shows the relay nothing.
• Apple tells the relay too. App Store Server Notifications (version 2) go to the relay for every purchase of the app. Each is signed down Apple’s chain and checked the same way. The relay acts only on a subscription a device has shown it (a renewal, an end, a refund) and reads and drops every other one without writing anything down. A notification names the subscription’s original transaction id; no name, no Apple ID.
• What the relay keeps: the subscription’s original transaction id (the same through every renewal), the product, when the transaction it last saw was bought and when it runs out, whether Apple revoked it and until when what was refunded would have run, and whether it was bought in the sandbox TestFlight uses. All of it is tied to the device’s public key and, when that device is signed in, to its account. Showing a proof registers the device if it was not registered, so from then on a device record exists without a watched account.
• When it goes: with the device (turned off or thirty silent days, as above), or when the device asks to stop carrying it; a subscription no device carries and no account holds is deleted within the hour. One that Apple refunded is kept until the refunded period and three days are over, whatever was bought since: the transaction from before the refund is still validly signed, and shown to a relay that had forgotten the refund it would be Plus again.

On the website the purchase is Paddle’s. crowdinbox.com/plus asks for one thing, the address the purchase is for, and loads Paddle’s script only when the visitor asks for the checkout; the website policy describes that. Paddle is the seller and its own controller.

• What Paddle tells the relay: its subscription.* and adjustment.* events, signed with a secret only Paddle and the relay hold. They carry Paddle’s ids for the subscription, the customer and the price, the state, the paid period, whether money went back, and the address from the purchase page, as custom_data. No name and no payment detail.
• What the relay keeps of it: Paddle’s id for the subscription, the price id, the state, how far it is paid, when money went back, production or sandbox, and the fingerprint of the address. The address itself is turned into the fingerprint and dropped; it is not logged.
• When it goes: thirty days after the purchase ended. One that was given to another address by hand (crowdinbox-relay claim) stays until Paddle reports it cancelled, since Paddle’s next word about it would otherwise hand it back to the address it was bought for.
• What ServerCrowd can see at Paddle: the buyer’s name, address of purchase (email), country and in some countries the postal code, in Paddle’s dashboard. That is Paddle’s record, kept by Paddle’s rules.

The account (ADR 0025)

Optional, and for one thing: Plus bought on one device holds on the person’s others. It is an email address proved with a code; no password, no name.

• Asking for a code sends the address to the relay, signed by the device, which registers for it if it was not registered. The relay mails a code only to an address that already has an account or a purchase on the website, or from a device that carries Plus; it answers the same either way. The mail goes through ServerCrowd’s own mail server (web01, in Germany), whose log records recipient and time like for any mail.
• What the relay keeps: the address’s fingerprint, an HMAC-SHA256 under a key that is its own file on the relay nodes, never on the database machine and never in a dump; which devices are signed in; the fingerprint of the code and the tries spent on it (good for ten minutes; a code nobody typed is removed by the hourly round, within an hour after that); and per fingerprint and day, how many codes went. The address is in no table and no log of the relay.
• What that does not hide: the mailbox a device asked the relay to watch, or to send from, is named in clear as it always was, and a signed-in device ties it to the account. For somebody who uses a relay feature the database usually says whose account it is. The fingerprint protects those who sign in only to carry Plus.
• What the device keeps: the address it is signed in with (the only place it is written down) and what the relay last said about Plus, with when.
• When the relay is asked: by a device that is not signed in, only when somebody opens the Plus page or turns on something the relay does, never at launch. A signed-in iPhone also shows the relay a renewal or a refund when the App Store reports it, which can be at launch, and asks about Plus again when what it knows is a week old and somebody uses something that needs Plus while the iPhone has no subscription of its own. The request arrives from the device’s IP address like any other. The relay writes it to no table and no log; its limits count requests per network in memory (for a code, together with the fingerprint of the address asked for) for an hour, one of them for a day, and drop what they counted within a minute of that.
• What it forgets: signing out takes the device out; an account no device is signed in to is deleted within the hour. Deleting the account, in the app, signs every device out and removes the fingerprint at once. A signed-in device that falls silent is kept four hundred days. What deleting does not reach: the mail server’s log, and Paddle’s record of a purchase.

Cancelling on the website

crowdinbox.com/cancel sends its form (the address the purchase was for, the kind of cancellation and a reason if there is one, the day wanted) to the relay. The relay stores none of it: it mails the declaration to ServerCrowd, mails a confirmation to that address and no other if a purchase is known for it, and answers the page with when it arrived, and with nothing that says whether anything was bought: not in what it answers, not in whether it refuses, and not in how long it takes, which is why no answer that says a declaration arrived comes sooner than three seconds. A declaration is dealt with to the end even when the page has been closed meanwhile. It counts, by a fingerprint of the address and for the day, how often a cancellation was declared for it, and takes three. When more than thirty declarations in an hour are about addresses nothing was bought for, further ones of that kind are answered and not passed on; the page asks whoever sent one to write if no confirmation comes. The mail to ServerCrowd is kept there as the proof of the cancellation.

Children

The app is a mail client for the account its user already has; it is not directed at children and collects nothing about anyone.

Who to ask

ServerCrowd GmbH, Riehestraße 34a, 31535 Neustadt am Rübenberge, Germany. Questions and requests about personal data: Moritz Witte, data-protection@servercrowd.de. Everything else: services@servercrowd.de.