inboxy.net — Privacy Policy & Data Protection Notice

Last updated: 2026-07-31. Effective: at launch.

This is the privacy notice for inboxy.net, an email aliasing and AI inbox service. It is written to be read by a person, not skimmed by a lawyer.

inboxy is a Guernsey-incorporated controller. Our primary data-protection regime is The Data Protection (Bailiwick of Guernsey) Law, 2017 ("the Guernsey Law"), which is recognised by the European Commission as offering an adequate level of protection for personal data transferred from the EU. That adequacy decision means data can flow freely between EU-resident infrastructure and our Guernsey-based controller without further safeguards being required.

If you are in the European Union you also have rights under the GDPR. If you are in the United Kingdom you also have rights under the UK GDPR and the Data Protection Act 2018. We honour all three regimes — where they differ, the rule that gives you more protection applies.

If anything in this policy conflicts with the security and product guarantees on our homepage (e.g. "inboxy never sends mail from your personal email address"), the stricter guarantee wins. We will not silently relax a guarantee through a policy change.

1. Who we are

inboxy.net is operated by Polimimetic Limited (Registration Number 75584) ("inboxy", "we", "us"), a company incorporated in the Bailiwick of Guernsey.

We are the data controller for the personal data described below, registered with the Office of the Data Protection Authority (ODPA) under the Guernsey Law.

  • Privacy enquiries and data-subject requests: privacy@inboxy.net
  • Data Protection Officer (if appointed): dpo@inboxy.net
  • EU representative (Art. 27 GDPR, appointed once user base requires): {to be appointed}
  • UK representative (UK GDPR, appointed once user base requires): {to be appointed}

Our supervisory authority is the Office of the Data Protection Authority — see §6 for how to lodge a complaint, including how to complain to your local authority if you are in the EU or UK.

2. What we collect, and why

We hold as little of your data as the product allows. Everything below is collected for a defined purpose and kept only for as long as that purpose requires.

2.1 Account data

Data Purpose Legal basis (Guernsey Law Sch. 2 / GDPR Art. 6)
Personal email address (the one you sign up with) To deliver your daily digest, forward time-sensitive mail, contact you about your account, and recover access Contract performance
Timezone To deliver your daily digest in your local morning and render dates in your account UI Contract performance
Plan tier (Early Adopter / paid) To enforce plan limits Contract performance
Account status To suspend or close abusive accounts Legitimate interest (service integrity)

2.2 Authentication data

Data Purpose Legal basis
Passkey (WebAuthn) public keys To sign you in Contract performance
TOTP shared secret (encrypted at rest) For account recovery and high-risk action confirmation Contract performance
Recovery code hashes (one-way) Fallback for lost passkey + TOTP Contract performance
API key hashes (one-way) To authenticate API and MCP calls Contract performance
Session tokens (short-lived, HttpOnly cookie) To keep you signed in Contract performance

We never store passwords because we don't use them.

2.3 Sign-up context

Data Purpose Legal basis Retention
IP address at signup Fraud and abuse prevention Legitimate interest 90 days, then nulled
Autonomous System Number (ASN) Fraud / VPN-farm detection Legitimate interest 90 days, then nulled
User-agent string Fraud and debugging Legitimate interest 90 days, then nulled
Cloudflare colo (the Cloudflare edge data-centre that served the request — city-level granularity) Fraud signal at signup; anchor for out-of-band alerts on later sensitive changes Legitimate interest 90 days, then nulled

We do not ask for browser geolocation. Coarse-grained signup colo is enough — no JavaScript geolocation prompt, no GPS coordinates, no consent flow.

2.3a Device recognition and sign-in alerts

When you sign in, we set a long-lived cookie holding a random device identifier and no personal data, and we record the following against that identifier so we can tell a familiar browser from an unfamiliar one:

Data Purpose Legal basis Retention
Device identifier (random, set by us, meaningless on its own) To recognise a browser you have signed in from before Legitimate interest Deleted 180 days after the device was last used
Country of sign-in To notice when a familiar device signs in from somewhere new Legitimate interest Deleted 180 days after the device was last used
IP address, ASN, user-agent, city and Cloudflare colo at last sign-in To describe the sign-in to you in the alert email, so you can judge whether it was you Legitimate interest 90 days, then nulled

If we see a device we don't recognise, or a device we do recognise signing in from a different country, we email your sign-up address with the date, country, city, device type and IP address of that sign-in, and a link to sign the device out.

These alerts cannot be switched off. They are a security measure, not marketing: an option to disable them would be the first thing an intruder used. They are the reason the data above is retained beyond your session.

2.4 Your inboxy addresses

Data Purpose Legal basis
The @inboxy.net local-parts allocated to you, their labels, creation and retirement timestamps To route inbound mail and present your address inventory Contract performance
Per-site attribution (which alias you handed to which website, captured by the browser extension when you choose to use it) So you can see which sites have which alias, and burn an address when one starts attracting spam Contract performance — recorded only when you act in the extension

Attribution data (which alias you gave which site) is visible to you, to any AI agent you've authorised via API/MCP key, and to inboxy staff with audit access — never shared externally or with the sites themselves.

2.5 Mail received at your @inboxy.net addresses

Data Purpose Legal basis
Envelope, headers, sender, recipient, subject, date, Message-ID To process, classify, search, and present your mail Contract performance
Body text (and HTML, sandboxed at render time) To show you the message and produce the daily digest Contract performance
Attachments, stored in Cloudflare R2 To make them downloadable from your inbox Contract performance
AI-generated classification, summary, urgency, confidence To route OTP and login mail instantly and roll the rest into your digest Contract performance
Embedding vector for the message text To deduplicate, detect spam-similar mail, and power semantic search via MCP / API Contract performance
AI-generated description and transcribed text of image attachments So that mail whose content is an image — a receipt, a ticket, a scanned letter — can be found by searching for what is in it, rather than being invisible to search Contract performance

We do not use the content of your mail to train any model. Mail content is processed by Workers AI on Cloudflare's platform under their data-processing terms; it is not sent to any third-party AI provider.

Data Purpose Legal basis Retention
Click events on links rewritten through l.inboxy.net (which link, which user, when) To show you in your inbox UI which marketing links you actually opened Contract performance Bound to parent message (28 days on Early Adopter); user can opt out
Referrer is stripped when redirecting outbound. We never tell the original sender that you clicked. — — —

You can disable link rewriting per-account; the relevant setting is in Account → Privacy.

2.6a Remote images in your mail

Marketing mail almost always loads its images from the sender's own servers. If your mail client fetched them directly, the sender would learn your IP address, your rough location, and the moment you opened the message — which is exactly what a tracking pixel is for.

So we fetch them instead. When a message is forwarded or digested through inboxy, remote <img> sources are rewritten to l.inboxy.net/img/..., and inboxy fetches the image from the sender's server, caches it, and serves it to you. The sender sees a request from us, not from you. We send no Referer and a generic user-agent, and we never tell the sender that you opened anything.

Data Purpose Legal basis Retention
The image bytes themselves, in Cloudflare R2 (EU) So the image renders without your client ever contacting the sender Contract performance Deleted 7 days after the last time anyone viewed it
A hash of the image's original URL, mapped to a hash of its content, in Cloudflare KV (EU) So a repeat view is served from cache instead of re-fetching Contract performance 24 hours, then it expires by itself

Two details worth being explicit about, because they are the parts that could otherwise carry an identity:

  • Cached images are stored under a hash of their own bytes, and shared. Two people who receive the same newsletter share one stored copy. That record contains nothing about who received it — no account identifier, no address, no message link.
  • The URL-to-content map is the one piece that could be linked back to you, because a sender's image URL sometimes contains a per-recipient tracking token. That is why it is held separately, for 24 hours, and expires on its own rather than waiting for a deletion request.

2.7 Audit log

We keep an append-only record of account-affecting actions (sign-in, address create/retire, key create/retire, recovery initiation, account deletion). This is retained for 365 days to support security investigations and your right to know what happened to your account. On account deletion the row is retained but your user_id is nulled (see §7).

High-volume routine entries — the ones written every time a message is forwarded, kept or un-kept — are shorter-lived and are removed after 90 days.

When an entry reaches the end of its window it leaves our live database. A copy is kept in cold storage, because an audit ledger that can be quietly truncated is not much of an audit ledger. That copy carries no account identifier: your user_id is replaced with an irreversible pseudonym before the copy is written. The pseudonym is stable, so we can still see that a series of events belonged to one account, and we can still detect abuse patterns — but it can only be tied back to you by someone who already holds your user_id, and deleting your account destroys the only record of it. See §7.

Every sign-in writes one row. It records which method you used (sign-up, magic link, passkey, TOTP or recovery code) and whether we recognised the device, and — deliberately — nothing else: no IP address, no device identifier, no country. Those live only in the device record described in §2.3a, where the 90- and 180-day limits apply to them; copying them into a ledger we keep for a year would quietly outlast the promise we made about them.

2.8 Cookies and similar

We use essential cookies only: a session cookie (HttpOnly, Secure, SameSite=Lax), a CSRF token cookie on logged-in pages, a remembered-device cookie that lets a returning sign-in skip the second factor, and a device-recognition cookie holding a random identifier that lets us alert you when your account is used from a browser we have not seen before (§2.3a). None of them carries personal data, and none is used to track you between sites. We do not use analytics cookies, tracking pixels on our own marketing pages, third-party advertising cookies, or social-network share buttons. Because we use only strictly necessary cookies, no consent banner is shown.

3. What we do not collect or do

For clarity, because these are the questions our prospective users actually ask:

  • We do not connect to your Gmail, Outlook, Yahoo, or any other personal mailbox. inboxy is a separate inbox alongside yours, not a layer on top of it.
  • We do not send mail using your personal email address. Every outbound message we emit on your behalf is from one of your @inboxy.net aliases, never from the address you signed up with, and every externally-delivered message carries a visible — inboxy.net — agentic email footer.
  • We do not allow your @inboxy.net aliases to be used as an open relay. Outbound is capped per plan (20 emails per calendar month on Early Adopter) and recipient-locked at the server: replies go only to the original sender, forwards go only to your verified personal email, and agent-composed mail refuses self-loops and reserved local-parts. Mail from one @inboxy.net address to another stays in our network and does not count against the cap.
  • We do not sell, rent, or share your personal data with advertisers.
  • We do not share your click data with the senders whose links you click.
  • We do not use your mail to train any AI model, ours or anyone else's (this is a locked guarantee under Terms §2, not a policy we can silently change).
  • We do not silently scan unauthenticated mail. Inbound mail to unknown @inboxy.net addresses is dropped at the edge with no notification (this is intentional, to prevent enumeration of which addresses exist).
  • We do not allow registration with an @inboxy.net personal email; you must sign up with a third-party address you already control.

4. Where your data lives and who can see it

4.1 Hosting and sub-processors

Your data is held entirely on Cloudflare infrastructure (Workers, D1, R2, KV, Workers AI, Vectorize, Email Routing, Email Sending). Cloudflare is our only sub-processor. We have a Data Processing Agreement with Cloudflare under GDPR Art. 28.

If we add a sub-processor in future (e.g. a billing provider once we launch paid plans), we will list it here and notify existing users by email at least 30 days before any of their data flows to that sub-processor.

4.2 Data residency — EU only

All persistent stores are pinned to the European Union. There is no opt-in or opt-out: every inboxy account is EU-resident by design.

Specifically:

  • Database (Cloudflare D1) is created with a Western-Europe location hint. Writes are pinned to the EU.
  • Object storage (Cloudflare R2), which holds your attachments, is created as an EU jurisdictional bucket. Storage is constrained to the EU.
  • Vector index (Cloudflare Vectorize), which holds the embedding vectors used for semantic search and deduplication, is in an EU region.
  • AI inference (Cloudflare Workers AI) is routed through an AI gateway pinned to EU endpoints.

Two unavoidable caveats, in the interest of honesty:

  • Key-value store (Cloudflare KV) is globally replicated by design and cannot be pinned to a region. We therefore put only non-personal, short-lived values into KV: opaque session identifiers (meaningless without the EU-resident database), rate-limit counters, OAuth PKCE codes (5-minute lifetime), and DPoP replay-nonces (5-minute lifetime). No email address, mail content, alias, or attribution data is ever written to KV.
  • Inbound mail acceptance happens at Cloudflare's global edge — this is how internet email works; the receiving server has to be globally reachable. The moment your mail is parsed (within milliseconds of receipt), every piece of it lands in the EU-pinned database, R2 bucket, and Vectorize index. The mail body is never persisted outside the EU.

Two flows of personal data cross the EU border in the course of running inboxy: (a) the controller (inboxy itself) is based in Guernsey, and (b) the technical caveats above (KV, edge acceptance) involve Cloudflare's global platform. Both are lawful without additional safeguards:

  • EU → Guernsey transfers (to us, the controller) are covered by the European Commission's adequacy decision for Guernsey under the Bailiwick of Guernsey Data Protection Law 2017. No Standard Contractual Clauses are required for this flow.
  • EU → Cloudflare global edge transfers required to accept inbound mail and operate KV are covered by the European Commission's Standard Contractual Clauses (and the UK Addendum) as incorporated into the Cloudflare Data Processing Addendum. Data is moved back into EU-pinned stores within milliseconds of acceptance.

4.3 Who at inboxy can read your mail

Operator access is minimised and audited. For v1 there is no end-to-end encryption of mail bodies (encrypting at rest with platform keys but decryptable by our workers for classification and rendering). Operator access to mail content for classification and rendering is a technical necessity in v1 (no end-to-end encryption yet), not routine practice — every operator read is logged as an auditable event, and per-user envelope encryption is on our roadmap. We will update this notice when shipped.

4.4 Who you can grant access to

  • API keys you create grant scoped read or read-and-manage access to your inbox over HTTPS. You can revoke any key in Account → Keys.
  • Browser extension tokens are a narrow scope (extension) that can list and create addresses and record attributions, but cannot read message contents. Revocable in the same place.
  • MCP-connected AI agents receive whatever scope is on the key you give them. Treat your API keys like passwords.

5. How long we keep things

Class of data Retention
Account record (email, timezone, plan, status) Until you delete your account
Authentication credentials (passkey public keys, TOTP secret, recovery code hashes) Until you remove the credential or delete your account
Sign-up IP / ASN / UA / Cloudflare colo 90 days raw, then nulled
Device-recognition IP / ASN / UA / city / colo 90 days after last use, then nulled
Device identifier and country of sign-in Deleted 180 days after last use
@inboxy.net aliases Until you retire them; retired aliases are kept (so re-issuance can be avoided) for the lifetime of the account
Mail bodies, attachments, embeddings Early Adopter plan: 28 days rolling. Per-account override available on request; extended retention will be a paid-plan setting post-beta
Mail metadata (envelope, classification, summary) Same as bodies
Click events via l.inboxy.net Bound to parent message (28 days on Early Adopter)
Cached remote images from your mail (§2.6a) 7 days after the last view. Stored by content hash and shared between accounts; holds no identifier of who received the mail
The URL-to-content map for those images (§2.6a) 24 hours, then expires automatically
Audit log 365 days in the live database (routine mail-event entries: 90 days); on account deletion, user identifier nulled but row retained. After the window, a pseudonymised copy is kept in cold storage (§2.7)
Billing records (when paid plans launch) Retained as long as required by tax law in our jurisdiction (typically 7 years)

6. Your rights under the GDPR (and equivalent UK law)

If we hold personal data about you, you have the following rights. We honour them whether or not you live in the EU or UK.

Right How to use it
Access (Guernsey Law s. 11 / GDPR Art. 15) — a copy of your data Account → Export. We deliver a JSON file of all your data, by default within 24 hours and always within 30 days. Message bodies and attachments are not inlined into that file — it would routinely run to gigabytes — so each one carries a pointer you can fetch individually from the API, or ask us to bundle for you if that is impractical. Format detail: docs/help/data-export-format.md
Rectification (Guernsey Law s. 12 / GDPR Art. 16) — correct inaccurate data Most fields are self-serve in Account. For anything else, email privacy@inboxy.net
Erasure (Guernsey Law s. 13 / GDPR Art. 17) — "right to be forgotten" Account → Delete account. We hard-delete D1 rows, purge R2 attachments, remove embeddings from Vectorize. The audit log row is retained with your user_id nulled — this is necessary for abuse detection and is documented here as our justification under Guernsey Law s. 13(3) / GDPR Art. 17(3)(e)
Restriction (Guernsey Law s. 14 / GDPR Art. 18) Email privacy@inboxy.net. We will pause classification, digest delivery, and forwarding while we resolve your request
Portability (Guernsey Law s. 16 / GDPR Art. 20) Same as Access — the export is machine-readable JSON
Object (Guernsey Law s. 13 / GDPR Art. 21) — to processing based on legitimate interest Email privacy@inboxy.net. We process IP / ASN / UA for fraud prevention on a legitimate-interest basis; objecting will close the account because we cannot operate safely without this signal
Withdraw consent We do not rely on consent for the core service. The only consent-based mechanism is your browser's cookie/storage settings (essential cookies only — see §2.8)
Complain to a supervisory authority Our supervisory authority is the Office of the Data Protection Authority (ODPA) in Guernsey: info@odpa.gg, +44 (0)1481 742074, Block A, Lefebvre Court, Lefebvre Street, St Peter Port GY1 2JP, odpa.gg. If you are in the EU you may instead complain to the supervisory authority of your member state (e.g. the DPC in Ireland, CNIL in France, BfDI in Germany). If you are in the UK you may complain to the Information Commissioner's Office (ICO). We would rather hear from you first, but complaining is your right and we will not contest it

For any of the above, we will respond within 30 days (extendable by a further two months for complex requests, with notice — Guernsey Law s. 17 / GDPR Art. 12(3)). We never charge a fee unless a request is "manifestly unfounded or excessive" (Guernsey Law s. 17(5) / GDPR Art. 12(5)).

7. Account deletion in detail

When you delete your account:

  1. We immediately stop forwarding and digest delivery.
  2. Within 24 hours we hard-delete: users row, webauthn_credentials, totp_secrets, recovery_codes, api_keys, inboxy_addresses, address_attributions, messages, attachments blobs in R2 (including the AI-generated image descriptions held against them, per §2.5), and all entries in the Vectorize index that match your user_id.
  3. The audit log retains a single closure record (event=account_deleted, at=<timestamp>) with the user_id nulled. This is retained for 365 days as documented above.
  4. Within 7 days, any backups or replicas roll over so your data is gone from those too.
  5. Once the audit log row ages out at 365 days, nothing that identifies you remains on our systems. Three things do survive, and we would rather set them out plainly than let that sentence do more work than it can bear:
    • Pseudonymised audit entries in cold storage (§2.7). Deleting your account removes your user_id from every system we hold, and the pseudonym in those entries cannot be resolved without it — so what remains is a record that some account did something on some date, with no way back to you.
    • Correspondence you sent us. If you ever wrote to abuse@, security@, support@, privacy@ or dpo@, that ticket and the email address on it are kept. This is deliberate: for a privacy or data-protection request, the ticket is the evidence that we handled your request lawfully and on time, and destroying it would defeat the accountability obligation that made us answer you in the first place. We rely on Guernsey Law s. 13(3) / GDPR Art. 17(3)(b) and (e) here. If you want that correspondence removed as well, email privacy@inboxy.net and we will assess it separately — we can usually delete a support thread, but not the record of a rights request.
    • Cached copies of remote images that appeared in mail you received (§2.6a). These are stored under a hash of the image's own bytes and shared between accounts — a newsletter banner is one stored copy no matter how many people were sent it — so the cache holds no record of who received what, and there is nothing in it to link to you. It is not deleted per-account because there is no per-account thing in it to delete; unused images age out after 7 days regardless. The one part that could have been linked to you, the map from a sender's image URL to its content, expires on its own within 24 hours.

If you delete your account and a new user later signs up wanting one of your retired local-parts, the retired local-part will not be reissued (we keep retired local-parts permanently reserved to prevent address-takeover).

8. Security

Mandatory passkeys at signup. TOTP for recovery. All traffic over HTTPS with HSTS. Data at rest encrypted by Cloudflare's platform. Per-user data scoping enforced in every query path. OWASP-aligned code review on every release. Append-only audit ledger. Detailed security posture is on the engineering pages of our site.

If you find a vulnerability, please email security@inboxy.net. We will acknowledge within 48 hours.

9. Children

inboxy is not directed at children under 16 (or the equivalent age in your jurisdiction). We do not knowingly collect personal data from children. If you believe a child has signed up, email privacy@inboxy.net and we will close the account and delete the data.

10. AI agents and MCP

When you connect an AI agent — Claude, Codex, Copilot, or any other client of our MCP server — that agent reads your mail using a token you generated. The agent operates inside the inboxy inbox we created for it; it cannot reach any other mailbox you have, and it cannot send mail using your personal email address. It can send mail from your @inboxy.net aliases — replies to the original sender, forwards to your verified personal email, and agent-composed mail — within the per-plan cap and the recipient-locking described in §3 above. Every externally-delivered message carries the visible — inboxy.net — agentic email footer; mail from one @inboxy.net address to another stays in our network and does not count against the cap. The full list of MCP tools is documented on our /mcp page and our OpenAPI spec at /openapi.json.

If you revoke the token, the agent loses access immediately.

11. Browser extension

The optional inboxy browser extension is available for Chromium-based browsers (Chrome, Edge, Brave, Opera, Arc, Vivaldi) and Firefox at launch, with Safari following shortly after. It uses the activeTab permission only — it reads the page DOM only when you click its icon on that tab, and never in the background. When you choose an alias for a form, the extension records (alias, site origin) via our API. The site origin is read from the browser's privileged tab API, not from the page DOM, so a hostile page cannot trick it.

The extension never reads your messages and holds only a narrow extension-scoped token. That token is further cryptographically bound to the device using DPoP (RFC 9449): the extension generates a non-extractable signing key inside the browser's WebCrypto, and every API call from the extension carries a signature from that key. A token copied off your machine without the key is unusable.

The extension's source code is open from day one for independent review.

12. Changes to this notice

We will tell you about material changes by email to your personal address at least 30 days before they take effect. The version date at the top of this document always reflects the most recent change. Past versions are archived at /privacy/history.

13. Contact

Add Inboxy to your Home Screen

  1. Tap the Share button in Safari’s toolbar.
  2. Scroll and tap Add to Home Screen.
  3. Tap Add in the top-right corner.