Who is responsible

Tonight 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@tonight.movie.

What this policy covers

Tonight 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 tonight.movie — its web pages including the signed-in view of your taste model at /, the endpoints that page writes through under /api, 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 assistant you connect Tonight to. Tonight is a store for your taste model and a small set of operations on it; it does not choose films. That happens in whatever MCP client you use — Claude, ChatGPT or another — which brings its own knowledge of films and whatever other tools it has. That assistant is a separate service with its own privacy policy, and what you type into it is governed by that policy rather than this one. Tonight does not send your taste model anywhere on its own initiative. What it does is answer: an assistant you have authorized may request your taste model through the MCP endpoint, and Tonight returns all of it — every genre and vibe with its instruction, every film you have saved with its year, its IMDb id if it has one, and whether you have said you watched it, and everything you have said about particular films. What that assistant then does with what it receives happens in that service, not here, and the operator has no control over it.

This website shows you less than that, and is a view of your data rather than the same answer rearranged. The signed-in page is built for reading a collection: it groups your films under the vibes they are in, lists the rest under “Other movies”, and keeps each instruction one click away rather than on the page. What you said about a film is shown against the film it is about, so three things stored about you are not on it: a verdict about a film you never saved, because there is no film there to show it against; a not tonight, because that belongs to an evening rather than to the film; and a verdict you replaced or took back, because the page shows what stands. The evenings Tonight recorded are not on it either. None of that is deleted, hidden from you, or outside this policy — it is stored, it is covered by the retention and deletion terms below, and an assistant you authorize can read all of it back to you.

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 Google 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 What we store 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 the taste model belongs 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.

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 Tonight, 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 taste model. This is the product, and it is all of it. For each genre: its name, the free-text instruction in which you say what that genre means to you, and the times it was created and last changed. For each vibe: the same three, plus which of your genres it is built from and the order you gave them in. Instructions are stored as you wrote them, apart from surrounding whitespace. Names have surrounding whitespace removed too, and runs of spaces inside them collapsed to one, so that the name you see is the name a vibe refers to.

Films you tell it about. A film is in Tonight only because you or an assistant acting for you put it there. For each one: the title and release year you gave, an optional IMDb title id, which of your vibes it is in, and whether you have watched it. That last one is a fact and not an opinion, and it has three answers: seen, not seen, and nothing at all. Nothing at all is what a film starts as and means you have not said either way — it is different from not seen, which is something you said. Neither is guessed from anything: being recommended a film never says you watched it, and neither does saving one.

What you thought of a film. Kept separately from the film itself, because it is a different kind of thing. A verdict is something you said about one film: that you liked, loved or disliked it, or that you turned it down — not tonight for one evening, or not ever. Each one records your own words for why if you gave them, whether you volunteered it or answered a question, and when you said it. Nothing else is stored as an opinion: a saved film carries no rating, and being recommended something writes no verdict.

Verdicts keep their history, and you can take one back. Changing your mind records the new verdict and keeps the old one as something you used to say. Withdrawing one takes that verdict out of what currently applies rather than leaving a weaker one — and it reaches exactly as far as the verdict did: taking back a not tonight given for one evening leaves anything you said about the film in general still standing. It does not unsay it either: that you said it, and then took it back, is still part of what Tonight remembers, and both are shown to you. Neither reaches the film itself: taking back an opinion does not change whether you said you watched it, and does not remove the film from your collection. Forgetting is the stronger of the two and is the one that removes: that one thing you said is gone, and nothing remembers it afterwards.

What is stored about an evening. Tonight records the evenings it took part in: what you asked for in your own words, the films it put forward, and — only if you say so — which one you went with, whether you watched it, and whether you finished it. Anything you do not say stays unknown, permanently and on purpose: unknown is not a quiet no, and Tonight will not fill it in from what seemed likely. Being offered a film is not choosing it, choosing is not watching, watching is not finishing, and finishing is not liking — none of those is ever concluded from the one before.

That record is not a taste profile. Nothing about what you like is learned from it. An evening may record that you watched something, because you said so — that is the evening’s own account of what happened. What it never does is become an opinion: it is not a verdict, it does not create a genre or a vibe, it never changes the film’s own record of whether you have seen it, and it never becomes a preference. Those only change when you say so, where they live. You can correct any part of an evening, and you can delete one outright — deleting removes it and the films it listed, rather than hiding it from view.

What Tonight thinks is not stored at all. It may ask you something, it may notice that two films you loved are alike, it may suggest a genre for them. None of that is written down. A question it meant to come back to, a reading of its own, a change it was about to offer — all of it lives in the conversation you are having and ends with it, and it is not here the next time you talk to it.

Which means nothing enters your data unless you say so. If Tonight suggests a genre and you say yes, the genre is created and it is yours like any other — indistinguishable from one you asked for outright, because that is what it is. If you say nothing, or say no, nothing is written: there is no pending suggestion left behind, no record that it was offered, and no note of your refusal. The five things above — your genres, your vibes, your films, your verdicts, your evenings — are the whole of what is kept about you.

What is still deliberately not stored. Tonight keeps no scored or star ratings, and no profile built from how you use it: nothing is recorded from what you click, when you visit or how often, and nothing Tonight works out on its own becomes part of what it recommends without your say-so. Nor does it keep a film catalogue: no film exists here until you name one, and nothing about it — not a poster, not a runtime, not a cast — is ever looked up from a movie database. The IMDb id you may give a film is stored as a pointer and never followed.

Whether, never when. A film in Tonight says whether you have watched it, not when, how often, or in what order. An evening Tonight recorded carries the moment Tonight wrote it down, which is not the moment you watched anything — nobody asked you that, so it is not recorded. A verdict carries the moment you said it, which is when you spoke rather than when you watched. Liked, loved and disliked are things you said about a film, not a rating scale: there is no score, no stars and no average of anything.

Nothing you do changes your taste model except changing it. Tonight draws no conclusions from how you use it and writes nothing back from a recommendation: your genres and vibes change only through the operations that change them — by you on this website, or by an assistant you have asked to make a change. What a recommendation itself looks like is not ours to promise: it is produced by the assistant you connect, from your taste model together with its own knowledge, its own context and whatever other tools it has.

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.

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. Tonight’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 the taste model and the 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 your instructions may reveal

A genre and a vibe each carry an instruction — free text in which you describe what that part of your taste means to you. It is the heart of the product and it is stored as you wrote it.

What somebody likes in films can say more about them than they intend. A description of the kind of film you mean is enough, and it does not need to be about you. Please do not put special categories of personal data in it — anything about health, religious or political beliefs, sexual orientation or the like — and do not put other people’s personal details in it. The operator has no way to prevent what you type, which is why it is asked for here.

What we do not do

• No analytics, no tracking, no profiling, no advertising, no newsletter.
• No AI provider. Tonight contains no language model and calls no model provider’s API. Interpreting what you like, naming a vibe and choosing films all happen in the assistant you connect, not here — which reaches your genres, vibes and films by asking for them, as described above.
• No movie database. Tonight queries no film catalogue or search service and has no integration with one. The films it holds are the ones you told it about, in the words you used; nothing is fetched about any of them, including from IMDb.
• No third-party scripts. The fonts are served from this domain, so your browser makes no request to Google Fonts.
• No payments, and therefore no payment data.
• We do not sell your data and do not pass it on for anyone else’s purposes.

The only outbound requests the hosted service makes are to Google, while you are signing in: exchanging the authorization code, and fetching the public keys an identity token is verified against.

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-tn_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-tn_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-tn_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-tn_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 taste model 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.

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.
• Neon — the PostgreSQL database. 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.

Which regions these run in are deployment settings the operator configures in the providers’ dashboards; they are not established by the published source code. Processing may take place outside the European Union, in particular in the United States. 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, including standard contractual clauses.

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. 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
• a Tonight 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
• a client registration becomes eligible for deletion ninety days after it was last used — see below, which sets out what “last used” means and when the deletion actually happens
• rate-limit counters are kept in windows — ten minutes for sign-ins, ten minutes for an MCP client’s authorization requests, 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.

Everything Tonight holds about you — your genres, your vibes, the films you saved, everything you have said about a film whether or not that film is one you saved, and the evenings Tonight recorded — is subject to a policy of the operator rather than a rule in the software: it is intended to be kept until the closed beta ends, and the operator will delete it then, or earlier on a valid request. The application does not delete it 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

You can delete any vibe yourself at any time, on this website or through your assistant, and any genre no vibe is built from. A genre a vibe does refer to stays until that vibe does not: take it out of the vibe, or delete the vibe, and the genre can go. For a film, the signed-in page lets you say whether you have seen a film and what you thought of it; adding one, changing its title or year, and removing it are done through your assistant, which does each there and then. To have your account and everything belonging to it removed, write to info@tonight.movie. During this beta, deleting an account 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

Tonight 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.