What we do with your data.

Last reviewed: 11 October 2026.

The short version

The apps work without an account. Most working data stays in your browser; the network features described below send the information needed to provide their service. Signing in is optional and does exactly one thing: it copies a specific, listed set of your data between your devices.

Network features are the exceptions described here: The Trip Planner assistant and the venue-ratings lookup send trip contents to Google when you use them; the FPL Planner sends the Fantasy Premier League team ID you type to the official FPL API, because that is how it loads your team; and Arena is a multiplayer game, so what you do there is visible to the people you play with. These are covered in detail below.

What stays on your device

Each app stores its working data in your browser's localStorage, under keys scoped to that app. This includes your Mario Kart races and player names, your Football H2H games, your FPL Planner team ID, settings and saved gameweek plans, your Gym Tracker programs, sessions, settings and body measurements, your Rising Shows watched list and comparison selection, your MapTap Rivals rivals, games and per-day puzzle cities, and your Trip Planner trips and items.

The Trip Planner also stores files you attach to a trip (booking confirmations, tickets, vouchers) as blobs in an IndexedDB database named trip-planner-docs. Those files never leave your device: they aren't included in exports, share links, or sync.

Clearing your browser's site data for shevato.com removes all of it. If you're not signed in, there is no other copy.

Accounts and sync

You can create an account with an email address and a password. Authentication is handled by Firebase Authentication, a Google service, which is what stores your email address and password credential.

While you're signed in on an app page, that app's data is copied to Google Cloud Firestore at the path users/<your account id>/apps/<app namespace>, and changes flow both ways so your devices stay in step. The security rules restrict every document under users/<your account id> to that account alone.

Sync isn't a blanket upload. Each app has an explicit list of storage keys allowed to sync, and only those are copied:

One shared value syncs across apps: a single marker recording that the dark theme is in use. The apps are dark only, so there is no light or dark choice to carry, and nothing about you is in it. Arena is not part of this system at all; it is covered separately below.

What never syncs

Some things stay on your device on purpose, even when you're signed in. In the Trip Planner these are: any AI provider API key you supply, your passport nationality and passport expiry date for the visa checker, your assistant conversation history, the geocoding cache, the cached exchange rates, weather and visa data, the per-browser identifier described below, and the venue-lookup owner token. Attached documents, as noted, are also excluded.

The FPL Planner's copy of the Fantasy Premier League data (players, fixtures, and the projections it computes from them) stays on your device for the same reason. It is identical for every user and cheap to fetch again, so there is nothing to gain from syncing it.

Arena is more public

Arena is a real-time multiplayer game, so it writes to shared locations rather than to your private area. If you play it, here's what that means in practice.

1. Your display name is published, and you choose it first

   Arena asks you to choose a display name before your first multiplayer or daily game, and suggests a neutral default such as "Player 7KQD". Whatever you choose is written to shared records that any signed-in visitor can read. Your email address is never used to build that name.

   It didn't always work this way. Earlier versions defaulted your display name to the part of your sign-in email before the @, and published it the first time you played. If you played before this change and your email is name-based, your real name may already be on those shared records. Changing your name now updates the main leaderboard, but head-to-head and daily-challenge entries keep the old one until you play those modes again.

2. The leaderboard is shared

   Playing a multiplayer or daily-challenge game writes your display name, XP, games played, wins, best round score and last-played time to a leaderboard that any signed-in visitor can read. Solo games are not written to it.

3. Private-room passwords are never stored readably

   Since August 2026, creating a private room stores only a salted hash of its password, in a record no player can read; the database's own security rules check a joiner's entry against it, and the record is deleted with the room. The password you type is never written anywhere. Rooms created before this change kept their password readable to signed-in visitors until the room was deleted.

4. Chat is readable only by the room's players, and is deleted within about two days

   Room chat messages are stored with your display name and account id, and while the room exists only its players can read them. The security rules allow no edits, and no deletions at all while the room is open, so nothing can be recalled mid-game. When the last player leaves, the room is deleted and its chat goes with it. Every message is also given an expiry of a day when it is sent, after which the database deletes it, usually within another day, so a room nobody closes does not keep its chat. In the gap between a room expiring and its chat expiring, a signed-in visitor who has the room code could read what is left.

5. Chat is filtered on your device only

   Before a chat message is posted it is checked against a word list built into the app, in your browser. The text is not sent to any outside moderation service.

6. Head-to-head records and rooms are shared too

   Multiplayer results create per-pair win/loss records carrying both players' display names, readable by any signed-in visitor. A game room itself, with its players and its chat, is readable only by the players in it; a signed-in visitor who has the room code can see only that the room exists, which game it is, and whether it needs a password.

7. Guest play uses an anonymous account

   Playing as a guest signs you in anonymously to Firebase. Guest sessions cannot write to the leaderboard, head-to-head records or the daily board.

The MapTap Rivals rival network is opt-in, and partly shared

MapTap Rivals works without it. Only if you are signed in and press "Join rival network" does the app publish anything outside your private area, and your scores and games are never part of what it publishes. Joining writes three kinds of record.

1. A claim on your MapTap.gg username, which an account holder can look up by that username

   A record named after your MapTap.gg username, holding your account id and the username as you entered it. It is how the app turns a rival's MapTap username into someone on the network, so anyone signed in with an account can look it up by that exact username. Nobody can list the claims, and a guest sign-in, including Arena guest play, cannot read them at all. It records that you claimed the username, not that you own that maptap.gg account: the first claim wins, and only the person who made it can release it.

2. Your published profile, readable only by you and the rivals you are connected with

   Your MapTap.gg username, your display name and icon, and, for up to 60 of the rivals you track, their MapTap.gg username, the name you gave them and the icon you picked for them. It is what lets a connected rival discover the people you play. A rival can read it only once you are connected, meaning both of you have accepted; nobody else can.

3. A link for each rival you connect with, readable only by the two of you

   When you add a rival who is also on the network, a link record is created holding both account ids, both MapTap.gg usernames, the display name of whoever sent the invitation, and which of you has accepted. It grants nothing until the other person accepts, only the two of you can read it, and either of you can delete it.

"Leave network" deletes your profile, your username claim and every link you are part of, and deleting your account does the same (see below). What neither can remove is the other person's own data: a rival who tracks you keeps you in their rival list, and if they are on the network too, the profile they publish can carry your MapTap.gg username, the name they gave you and the icon they picked for you.

The Trip Planner assistant

The assistant has three modes and you choose which one to use. The mode selected for you on a fresh browser is the free shared assistant, which is the third one below: it sends the trip through a function we host to Google Gemini. Nothing is sent when the panel opens, or while you fill in the request. It is sent when you press Send, and the panel names the mode above that button so you can change it first. Copy and paste, which sends nothing anywhere, is always one click away.

1. Copy and paste

   The app builds a block of text and puts it on your clipboard. You take it to whichever AI tool you prefer. No network request is made by us, and whatever happens next is between you and that tool.

2. Your own API key

   You paste in an OpenAI or Google Gemini API key. It is stored in your browser only, is never synced, and never reaches our servers. Requests go straight from your browser to that provider, so the trip contents and your key are covered by your agreement with them, not by ours.

3. The site's own key (the mode selected by default)

   Requests go to a function we host, which forwards them to Google Gemini using our API key. In this mode the trip contents pass through our server on the way to Google.

In the second and third modes, what is sent is a trimmed copy of the current trip: its name, currency and budget, the names of the travellers you have added to it, any extra countries you added in the visa checker, and for each item the type (and, for a food & drink item, its meal slot), title, location, dates, times, status, costs, estimated costs and cost notes, the map query, which of the travellers the item's cost is shared between, and the free-text details field. If you keep confirmation numbers, seat assignments or personal notes in an item's details, they are part of what is sent. What is deliberately held back: the confirmation-number field itself, who paid, the custom amounts of an uneven cost split, the payment tag, the booking deadline and the resolved Google place saved with an item, along with attached documents, your packing list, your trip essentials and your passport setting. The copy-and-paste package holds back the same fields.

Other services that receive data

These are the outside services the site contacts, and what reaches each one.

Analytics and cookies

Our own code sets no cookies. Every page on this site, including the apps, loads Google Analytics 4, which stores its own identifier cookie in your browser and reports page views to Google.

This changed in August 2026. Until then the app pages carried no analytics at all, which meant we could see that people arrived but not whether anything we built was worth using. The apps now report a small, fixed set of events. What follows is the complete list of what they send.

Alongside page views, we record: that an app was opened; which section or tab within an app you moved to; that a search ran, with how many characters you typed and how many results came back; which item you picked from a search result list; which filters or sorting you chose; that you opened a detail view, and which catalogue entry it was; that you paged through a list; that you followed a link to another website, and to which domain; which link on this site you followed, recorded as the path it leads to and which part of the page it sat in; that you clicked an email or phone link, without the address or number; the path of a page that was not found, and the domain of the site that linked to it; a handful of started and completed actions specific to each app (a workout started and a workout finished; a Mario Kart race form opened and a race logged; a MapTap rival added, and MapTap games logged with how they were entered and how many; a trip created and a trip shared; the Trip Planner assistant opened; an Arena room created or joined and an Arena game started, with which of its games it was; an FPL Planner team connected, with only whether that team had a previous season behind it, and a gameweek plan calculated with how long the optimizer took and which model version produced it; a Football H2H match form opened and a match saved, with only whether it was decided on penalties; and a Rising Shows chart image shared, comparison link copied or comparison exported, with how many shows it covered); and JavaScript errors, as a short classification (the standard error type, such as typeerror, or a Firebase error code, such as permission-denied) and, for an error thrown by a script, the path of that script on this site, or just external when it came from another site or a browser extension. The error message, its stack trace and full web addresses are never sent. Every event also carries a short identifier of the site release that sent it, so a problem can be tied to a deploy.

The "started" half of that list was added in September 2026 for one reason: without it we could see that almost nobody finished anything, but not whether that was because nobody began or because something got in the way. A start event carries no more about you than the matching finish event does, and several carry nothing at all.

What we deliberately do not send matters more than the list above. We never send anything you type. Search boxes report how long your query was and whether it matched anything, never the query itself. We never send your trip contents, destinations, item details or confirmation numbers; your workout notes, exercise names, weights, heart rate or calorie figures; your rivals' or players' names; custom team names; Arena room codes or display names; your FPL team ID, squad or recommended transfers; your email address, account id, or any Firestore path. Filter and sort values are sent as text, but only because every one of them is picked from a fixed list the app defines rather than typed by you.

The generated show pages under Rising Shows and the exercise pages under Gym Tracker report page views, the links you follow on them and JavaScript errors, as described above, and nothing else.

Analytics is loaded so that it cannot interfere with the apps: every tracking call is wrapped so that a failure is silently discarded, and if you block Google Analytics with an extension or a content blocker, every app continues to work exactly as it does otherwise. Nothing on this site is gated on analytics loading.

There's no contact form on this site; the contact page is a set of links, so nothing you type is collected there. Clicking its email or phone link is counted as a link click, as described above, without the address or number.

Logs and server-side records

Two of the functions we host, for the AI assistant and for venue ratings, log HTTP status codes and truncated error responses from the service upstream when something fails. They do not log your trip, your prompt or the assistant's reply.

The venue-ratings function has one diagnostic mode, off unless we deliberately switch it on to investigate a wrong result. While it is on, that function's log records the venue search text it was given, the city it was told to search in, and the name, address, coordinates and place type of the place Google returned, so we can see why a venue resolved the way it did. It never records who asked: no account, no per-browser identifier, and nothing else from your trip. It is off by default and is not on in normal operation.

A third function is the Fantasy Premier League proxy behind the FPL Planner. It keeps a server-side cache of what it fetches, so that many people asking for the same public data cause roughly one request upstream. Everything in that cache is a copy of a public Fantasy Premier League response, including, where a team was looked up, that team's own public FPL entry. Nothing is stored against your account, and these requests carry no per-browser identifier. It does apply one usage limit: when a request cannot be answered from that cache and has to go upstream, it is counted against a per-network counter of exactly the kind described below. A request the cache can answer is not counted at all.

A fourth function receives Content Security Policy violation reports. Your browser sends one on its own, without asking you, when a page on this site tries to load something our security policy does not expect. For each report the function logs which policy rule was involved, the origin (scheme and host only) of whatever was blocked, the path of the page it happened on with any query or fragment removed, and whether the policy was blocking or only reporting. It does not log the page's full address, the referrer, any code sample, your IP address or anything else that identifies you, and it stores nothing: that log line is the whole record.

Those first two functions apply usage limits, and to do that they count requests against two identifiers. There are two because the first one alone could not do the job.

The first is a random identifier that the Trip Planner generates once per browser and stores locally. It isn't derived from you or your account, and isn't linked to either. There's no control in the app to view, reset or clear it; clearing your browser's site data for shevato.com discards it and the app generates a fresh one.

The second exists because that first identifier is generated by your own browser, which means anyone willing to keep generating new ones could use up a whole day's capacity on their own. So the two functions also count requests per network, and the Fantasy Premier League proxy uses that same network counter as its only limit. They do that without keeping your address: each request's address is combined with the current day number and run through a one-way hash, and only the first 16 characters of the result are kept, as the name of a counter. Your address is never written down, and the hash cannot be turned back into it. Because the day number goes into the hash, the same network produces a completely different value tomorrow, so these counters cannot be used to follow anyone from one day to the next, and they are not a ban list: using up a network's share costs the rest of that window and nothing else. When a request arrives without a usable address, the network limit is simply skipped rather than applied.

The counters both identifiers key are kept in server-side storage and are discarded automatically when their hourly, daily or monthly window rolls over.

The venue-ratings function also keeps a small server-side record of what each venue search resolved to, so the same search is not paid for twice. Against the search text and the city token it was given, it stores the Google place identifier that text resolved to - or, when we looked at a place and rejected it, the fact that we did and in one word why, such as that it turned out to be a branch in another city or a booking desk rather than the venue itself. That record holds no ratings, no review counts, no names, no addresses and no opening hours. A resolved identifier is kept for thirty days and a rejection for seven, after which the search is made afresh.

The venue-ratings function also keeps a small server-side configuration holding our own Google Places API key and a secret token that lets the site owner's browsers use a higher rate limit than the public one. Neither value is ever sent to your browser, and neither has anything to do with your data. If you are not the owner, your requests simply count against the public limits.

Separately from anything we write, this site is hosted on Netlify, and Netlify processes ordinary request metadata such as IP addresses in the course of serving, securing and diagnosing the site. That is the hosting provider's own activity rather than something the apps do, and we do not read those records. The one exception is the network counter described just above: the two Trip Planner functions and the Fantasy Premier League proxy read the address Netlify reports for the request that is in front of them, hash it with the day as described, and keep only that hash. They do not read Netlify's stored logs, and no app does anything else with this metadata. Separately, every page request passes a check that reads two pieces of that metadata, the browser identification string and the country Netlify works out from the address, for one purpose only: turning away an automated scraper that identifies itself as one specific 2022 build of Chrome on Windows 10 from China. That check logs and stores nothing, and every other request goes on to the page unchanged. How long Netlify keeps them is governed by its own service terms and the plan the site runs on. For the functions described above, Netlify's documentation states that function logs are retained for at least 24 hours of activity, extending to 7 days on certain of its pricing plans.

Share links

The Trip Planner can turn a trip into a link you can send to someone. The trip is compressed and placed after the # in the URL, which means it never travels to our server: everything needed to rebuild the trip is inside the link itself.

One thing to keep in mind: the link is compressed and encoded, not encrypted. Anyone who has it can read the whole trip, including every item's details field. There's no password on it and it can't be revoked once sent. Attached documents aren't included.

Getting your data out, and deleting it

Every app keeps your data in your browser, so you can remove all local data at any time by clearing site data for shevato.com in your browser settings. The Trip Planner can also export a single trip or your whole planner as a JSON file, plus calendar and spreadsheet exports for a trip.

Deleting your whole account

Signed in, click your name in the header, then "Sign Out", then "Delete account and all data" at the bottom of that window. Deleting is deliberately awkward: you have to enter your current password and type the word DELETE before the button becomes active. The password is checked before anything is removed, so a wrong one leaves everything untouched.

It removes, in this order: the synced Firestore document belonging to every app listed earlier on this page, together with the overflow documents that hold any part of that app's data too large for one document, plus the shared theme preference document; the users/<your account id> document itself, which is where Arena keeps your trivia profile (XP, wins, games played and any custom pack); your MapTap Rivals network entry, handle claim and the pair links to rivals you connected with, if you ever joined that network; your Arena global XP leaderboard row and every Globe Drop daily-challenge score you set; every synced key in this browser's localStorage; and finally the Firebase Authentication user, so the email address and password credential are gone too.

Your head-to-head records against other players are treated differently, on purpose. Each one is a record of games two people played, so deleting it would take the other player's history with it. Your name on those records is replaced with "Former player" instead, and the win, loss and draw counts stay. The security rules let each side rewrite only its own name, so nobody can do this to you.

If any one of those deletions fails, the process stops, names what failed, and leaves your account active on purpose so you can try again. It never reports success it didn't achieve, and it never deletes the credential before the data, because an account that can't sign in again could never come back to finish the job.

Two things survive, and we would rather say so than imply otherwise:

• Anything you typed in Arena room chat, in any room that is still open. Chat cannot be edited or recalled while a room is live; it is deleted along with the room when the last player leaves, and every room and every chat message is also given an expiry of a day, after which the database deletes it, usually within another day, so a room whose players all closed their browsers does not sit there.
• Other devices you're signed in on keep their own local copy of your app data until it's cleared there. They lose access to the cloud copy immediately, because the account no longer exists.

Two smaller notes. Device-local caches aren't touched by account deletion: the FPL Planner's fixture, projection and team-data cache and the Trip Planner's geocode cache all stay on the device. The FPL Planner's own "Disconnect your FPL team" and "Delete all FPL Planner data" buttons clear its cached copy of your team; clearing site data removes the rest. And guest play in Arena signs you in anonymously without creating an account, so there is nothing to delete there either, only browser storage to clear.

Per-app controls still exist for people who want to remove one app's data without closing their account:

• Gym Tracker and FPL Planner can erase their own synced data: each has a control in its settings that deletes its Firestore copy. The FPL Planner offers two, kept separate on purpose: "Disconnect your FPL team" removes only the team ID and the cached squad snapshot, on the device and in the cloud, leaving your saved plans and settings alone; "Delete all FPL Planner data" removes all four of its keys locally and deletes the whole fplPlannerApp document from your account. Both actions also remove the cached copy of your team data (squad, bank and history, stored under your team ID) from this device; the bulk public fixture and projection cache remains. Signed out, both remove the local copy only, and the app says which of the two happened.
• Mario Kart, Football H2H, Rising Shows, MapTap Rivals and the Trip Planner have no equivalent per-app control. Their synced copies stay in Firestore until you delete your account or ask us to remove them.
• MapTap Rivals has a "Leave network" control that removes your published profile, your handle claim and every connection to a rival, without touching the rest of your account.
• Password reset is self-service too: the sign-in window has a "Forgot password?" link that emails you a reset link.

If you'd rather not do it yourself, email nikita@shevato.com and we'll take care of it manually.

One scope note: this is an informational page, not a formal legal policy. It makes no statement about legal basis, statutory rights, where data is transferred, use by children, or how changes to this page are announced.

Questions

If something here doesn't match what the site actually does, we want to know. Email nikita@shevato.com.