Who is responsible

Inbox Labeler is operated by a private individual, not a company. The controller within the meaning of the GDPR is:

Georg Schmidl Amberger Str. 20 81679 München Germany

For any question about this policy or your data, including a request to delete it, write to info@inboxlabeler.com.

What this policy covers

Inbox Labeler is currently a free, invitation-only closed beta. Access is limited to a list of e-mail addresses configured by the operator; any other Google account is refused after signing in, and receives nothing from us. If no list is configured, the hosted service admits nobody rather than everybody — it refuses every sign-in until the operator has named the invited addresses.

This policy covers the hosted service at inboxlabeler.com — its web pages including the signed-in view of your labels at /, the website’s own sign-in endpoints under /auth, the endpoints an MCP client is authorized through under /oauth, and the MCP endpoint at /mcp.

It does not cover the Inbox Labeler skills that read your mailbox. Those run in your own environment and talk to Google directly. What they may submit to the hosted service is the names of the labels an e-mail matched and that e-mail’s own timestamp, which is what the match counts are aggregated from. No e-mail content, sender, recipient, subject, message or thread identifier and no attachment passes through the hosted service.

Signing in with Google

Signing in redirects you to Google. We request exactly two scopes, openid and email. We do not request profile, so we receive no name and no picture.

Received, and only for the moment of signing in. Google’s token response, the identity token inside it, and a Google access token that comes with that response. The Google access token is not used and not stored — the hosted service holds no Gmail or Drive permission that it could be used for. The identity token is validated and then discarded; it is not stored either.

Used. The identity token’s signature, issuer, audience and expiry are checked against Google’s published keys, and a value we generated for this one sign-in (a nonce) must match, so that a token issued for a different session cannot be replayed into yours. From its contents we use three things: the subject, Google’s stable and opaque identifier for your account; your e-mail address; and whether Google verified that address — if it has not, the sign-in is refused.

Stored. The subject, as your user key, prefixed to record which provider it came from. It survives you changing your e-mail address, which is exactly why it is used instead of the address. If you signed in on this website rather than from an MCP client, your e-mail address is stored as well, on that browser session and only there — see Your browser session below.

Where your e-mail address goes. It is used to check whether you are on the invitation list. It is never contained in any token we issue and never visible to an MCP client. When an MCP client is authorized, that is all that happens to it: it is checked and discarded, and not written to the database. When you sign in to this website, it is additionally written to the row that represents your browser session, because the site shows you which Google account its labels belong to and because the invitation list is re-checked against it on every page you load. It is held for as long as that session is, and goes when the session does — but losing access and the row being deleted are two different moments, and only the first is immediate. Signing out deletes it there and then. An expired session stops working the instant it expires and its row is removed later; being removed from the invitation list blocks the session on its next request, and where the list has been emptied or misconfigured altogether the refusal happens before any deletion does. How long we keep things, below, sets out which case is which.

One thing follows from this and is worth stating plainly — the invitation list itself is a list of addresses the operator entered deliberately, and it remains stored in the hosting provider’s environment configuration for as long as the beta uses it. Your address is not kept there because you signed in; it is kept because the operator invited you.

Google itself learns that your account signed in to Inbox Labeler, when, and from which IP address — your browser contacts Google directly. That processing is Google’s own and is described in Google’s privacy policy.

Legal basis: the operator relies on Art. 6(1)(b) GDPR — providing the service you asked to use.

What we store

Your labels. The label text, its type and attention level, the free-text instruction in which you describe how it should decide, the references between labels, and the times a label was created and last changed. The instruction is stored as you wrote it apart from surrounding whitespace, which is removed.

Match statistics. For each label, a count per calendar day and the timestamp of the newest e-mail it matched. Nothing per message: no subject, sender, recipient, body, message or thread identifier, and no attachment. There is no table with one row per e-mail, and the database has nowhere to put any of it.

Sign-in and connection data. For each MCP client that registers itself: its identifier, the redirect addresses it names, the name it gives for itself, when it registered, and when an authorization was last started for it. For a sign-in in progress: the client it belongs to, the scope and resource requested, an expiry time, and hashed values that bind the flow to the browser it started in. For an issued grant: the user it belongs to, its scope and resource, an expiry time, and — for refresh tokens — which family it belongs to, whether an individual token has been spent, and whether the family has been revoked.

Your browser session. If you sign in on this website, one row per signed-in browser: your user key, the e-mail address Google verified, when the session began and when it expires. Nothing else — no name, no picture, no Google token, no record of which pages you looked at. While a sign-in is in progress there is also a short-lived row holding only the values that tie it together: a one-time value we require in Google’s reply, a proof key for the exchange with Google, an expiry time, and a hash of the cookie that ties the sign-in to the browser that started it. An MCP client’s authorization in progress holds the same kind of values, and a hash of the cookie tying the trip to Google to the browser that gave the approval.

Authorization codes, refresh tokens, session cookies and the browser bindings are stored only as hashes; the values themselves are held by your client or your browser, not by us. Inbox Labeler’s own access tokens, which only MCP clients get, are signed and not stored on the server at all — which is also why a browser session is stored: so that signing out can end it, rather than only asking your browser to forget it.

Rate-limit counters. The three endpoints that anyone can call — client registration, an MCP client’s authorization request, and this website’s sign-in — are counted per caller, so that a stranger cannot fill the database with requests. Where the hosting platform has established the caller’s IP address, the caller is identified by a keyed one-way hash of it; the address itself is not written to our database. Where it has not, the request is counted in a single shared counter and no address is involved at all.

Legal basis: the operator relies on Art. 6(1)(b) GDPR for labels, statistics and sign-in data, and on Art. 6(1)(f) GDPR for the rate-limit counters, the legitimate interest being to keep the service available and to prevent abuse.

What we do not do

• No analytics, no tracking, no profiling, no advertising, no newsletter.
• No third-party scripts. The fonts are served from this domain, so your browser makes no request to Google Fonts.
• The hosted service does not read your Gmail and does not write to Google Drive. It holds no Gmail or Drive scope, and no code that could call either API.
• No payments, and therefore no payment data.
• We do not sell your data and do not pass it on for anyone else’s purposes.

Cookies

Four kinds of cookie, and every one of them holds a random value and nothing else. There is no information inside a cookie — no address, no name, no identifier of yours — only a value that has to match a stored record for the request to mean anything. We consider all four strictly necessary within the meaning of § 25(2) TDDDG, being required to provide the sign-in and the signed-in pages you asked for, and accordingly no consent banner is shown.

On the hosted service all four are HttpOnly (no script can read them), Secure (sent only over HTTPS), Path=/, carry no Domain, and are named with the __Host- prefix — which is what tells your browser to refuse a cookie of the same name set by anything but this exact site. On a developer’s own machine the prefix and Secure are dropped, because a browser rejects a Secure cookie over plain http; nothing else about them differs.

• __Host-il_consent_… — one per authorization attempt by an MCP client. Set when the approval page is shown and removed as soon as you answer it. It ties your approval to the browser the page was shown in, which is what stops someone else’s website from submitting an approval on your behalf. SameSite=Strict, ten minutes.
• __Host-il_provider_… — one per approved authorization, for the trip to Google. Set when you approve an MCP client and removed when you come back from Google. It ties the rest of that authorization to the same browser, so an approval given in your browser cannot be completed in someone else’s. SameSite=Lax, ten minutes.
• __Host-il_login_… — one per sign-in to this website. Set when you press sign in and removed when you come back from Google. It ties the sign-in to the browser that started it. SameSite=Lax, ten minutes.
• __Host-il_session — your signed-in session. Set when a sign-in completes and removed when you sign out. It is what the site reads to know whose labels to show. SameSite=Lax, seven days.

The first three carry, in their name, a short one-way digest of a value belonging to the flow they are part of. That is only so two of them can be in progress at once without interfering; the digest identifies the flow, never you, and it is not what makes a request authentic — the value inside the cookie is, and it is compared against a stored hash.

We set no other cookies, and we use no local storage, session storage or IndexedDB in your browser. None of these cookies is used for analytics, tracking or profiling — see below.

Service providers

We use two providers, and treat both as processors under Art. 28 GDPR on the data processing terms they provide:

• Vercel — hosting. As the hosting layer it receives the connection and request data of every visit, including your IP address, and keeps platform logs of its own. The operator has configured the application’s server functions to run in Frankfurt, Germany. Static files such as stylesheets and fonts are delivered through Vercel’s content delivery network, which serves them from locations worldwide — they are not restricted to Frankfurt.
• Neon — the PostgreSQL database, which the operator has configured in Frankfurt, Germany. Neon receives database connections from the application and stores the records described above. It does not receive your browser’s connection, and therefore not your IP address by that route.

These regions are deployment settings the operator has verified in the providers’ dashboards; they are not established by the published source code. Both providers belong to groups with entities outside the EU and use subprocessors of their own; their documentation describes this and the safeguards they apply.

Our own application writes no request logs and stores no IP address in clear text. That is not the same as saying no IP address is processed. As with any hosted service, the hosting layer necessarily sees it.

How long we keep things

The periods below are validity periods — how long a record can still be used. They are not a promise that it has been physically removed at that moment:

• a sign-in in progress, either kind, is valid for ten minutes
• a signed-in browser session is valid for seven days from the moment you signed in. Two different things can end it, and they are worth telling apart. Access stops the moment the session is no longer valid: when you sign out, when you sign in again in that browser, when the seven days pass, or when the invitation list no longer admits your address — which is re-checked on every request the session makes, so a change by the operator reaches you on your next page load. The stored row is a separate question. Signing out, signing in again, and a request that finds your address removed from a list that still names other people each delete it there and then. But a session whose browser simply never comes back, and a session refused because the list has been emptied or misconfigured altogether, are refused without the row necessarily being removed at that moment — it stops working immediately either way, and is deleted later, in the opportunistic way described below
• an authorization code is valid for sixty seconds, and is deleted when it is used
• an Inbox Labeler access token is valid for one hour, and is not stored on the server at all
• a refresh token, and the family it belongs to, is valid for thirty days
• rate-limit counters are kept in windows — ten minutes for sign-ins, an hour for client registrations — and a counter row becomes eligible for removal about a day after it was last written

Expired rows are cleaned up opportunistically, as a side effect of later requests, rather than by a scheduled job. An expired record is unusable from the moment it expires, but may remain physically present in the database for some time after that.

A client registration also records when it was last used. It is set to the moment of registration when the client registers, and refreshed each time an authorization is started for it — starting one is the only thing counted as use; a client being looked up is not. So a client that registered and was never authorized still carries a time, its registration time, and its clock runs from there. That timestamp exists so a registration nobody ever came back for can be cleaned up rather than kept for ever.

A registration becomes eligible for deletion once ninety days have passed since it was last used. Deletion itself is opportunistic rather than scheduled: eligible registrations are removed the next time any client registers, so a row may remain for some time after it became eligible. A client that is still in use never becomes eligible, and one that has lapsed registers itself again the next time it is used.

Your labels and your match statistics are subject to a policy of the operator rather than a rule in the software: they are intended to be kept until the closed beta ends, and the operator will delete them then, or earlier on a valid request. The application does not delete them by itself, and performs no automatic deletion at the end of the beta.

Our providers operate backups and point-in-time recovery of their own, on terms they document and we do not set. Deleting data here therefore does not necessarily remove it from a provider’s backups at the same moment. For how long a copy may persist there, their own documentation is the authority; we make no promise of our own about it.

Deleting your data

Write to info@inboxlabeler.com. During this beta, deletion is carried out by hand rather than by a button in the product. We act without undue delay and, as a rule, within one month.

Your rights

Where applicable and subject to the statutory conditions, you have the right to access your data (Art. 15 GDPR), to have it corrected (Art. 16) or erased (Art. 17), to have its processing restricted (Art. 18), to receive it in a portable form (Art. 20), and to object to processing based on legitimate interests (Art. 21).

You may also lodge a complaint with a supervisory authority (Art. 77 GDPR), in particular in the Member State of your habitual residence, your place of work, or the place of the alleged infringement.

Changes to this policy

Inbox Labeler is a beta and changes while it runs. If what we process changes, this page changes with it, and the date at the top says when it last did.