Privacy Policy

Effective date: October 8, 2026

Summary

There are no accounts here, and nothing you do is tied to an identity. What reaches our server depends on which of the three Spick Me products you use, and the difference is worth stating plainly rather than averaging out:

  • The phone app is designed to work offline. Journey planning, saved journeys, favourite stations, recent searches, and downloaded timetable files stay on your device unless you choose to sync relevant data to a paired watch or create an optional short link. The app otherwise connects to the server only to check for and download timetable data, for optional live-data and train-formation features, and — only when you choose to send it — to deliver feedback. It also sends a crash report after a crash, which is the one thing it sends without being asked each time and which you can switch off; "Crash Reports" below says exactly what is in one. The watch app sends none.
  • The desktop app (macOS, Windows, Linux) works the same way and asks for even less: it has no access to your location at all.
  • The web planner at /plan and /m has no timetable of its own by default, so the searches themselves are sent to our server to be answered, and if you ask it to find stops near you, the position your browser reports is sent too. Your settings and recent searches are kept by your own browser and are not sent anywhere.
  • AI assistants connected to Spick Me's MCP server at /mcp send it the questions they ask on your behalf — places, times, the stops of a day out — so it can answer them. They are answered and not stored; "AI Assistants" below says exactly what is counted instead, and what a key tells us.
  • The web planner with the timetable on your device. If you have added the planner to your phone's home screen, it may offer to keep the whole timetable on the device; you can also choose this, update it or remove it in the planner's settings. Choosing it downloads the timetable file from our server once, like any download, and stores it in your browser's storage for this site. From then on your searches are answered on your device and are not sent to our server, and the planner works without a connection. The address index is downloaded and stored the same way, so typing an address or place name stays on the device as well. The files stay until you remove them in the settings or clear site data for this site.
  • The national map in the web planner. Off by default. If you switch it on in the planner's settings, the parts of the national map you look at under a journey are fetched from our server as you look at them, which tells our server which map areas you viewed and nothing else; they are not stored as a history. If you also keep the map on your device — an option offered once the timetable is stored — the map is read from the device and nothing is fetched.
  • Catch Me, the game at /catch/ and in the phone app, keeps each game on our server while it is played — the names players give themselves and the stops they choose to send, never a phone's position — and deletes it a week after it ends. "Catch Me" below says exactly what.

The server keeps standard operational logs for all of these requests.

Who Is Responsible

Spick Me is a private, non-commercial project operated jointly by Gian Calgeer and Jörg Schenker from Zurich, Switzerland, who are together the controllers for the data processing described in this policy. The Swiss Federal Act on Data Protection (FADP) applies, as does the EU General Data Protection Regulation (GDPR) where its territorial scope is met. For any privacy matter, contact unfreqapp@gmail.com.

The Spick Me server is hosted in Germany by netcup. Server data is therefore stored in Germany. The controllers operate from Switzerland; both Switzerland and the European Economic Area are recognised as providing adequate protection for transfers in the relevant direction. Privacy email is handled through Google, and optional watch synchronisation uses Google Play services. Google may process information in other countries under the safeguards described in its privacy documentation.

Information The Phone App Uses

  • Location, optional: if you grant location permission, the app uses your device's last known location to suggest nearby public transport stops. Location is processed on your device against the downloaded timetable. The app does not send your location to the Spick Me server.
  • Journey and station data: searches, saved journeys, favourite stations, recent searches, and downloaded timetable files are stored locally in the app's private storage. Travel data and short-link revocation credentials are excluded from Android cloud backup and device-transfer backup. Under Settings → Keep a copy you can export them yourself as a file, saved wherever you choose, and import it on another device; the app sends it nowhere.
  • Watch sync data, optional: when a paired Wear OS watch is used, the phone app can send saved journeys and nearby departure details to the watch using Google Play services Wearable Data Layer.
  • Timetable download requests: when the app checks for updates or downloads a timetable, the server receives the network request needed to provide `index.json` and `.unfreq` timetable files.

The Desktop App

The desktop app for macOS, Windows and Linux downloads a timetable and then does the work on your own computer. It asks for no permissions, and it has no access to your location by any means — not the operating system's, and not an estimate from your IP address. Its "nearby departures" view centres on a station you pick yourself, and the coordinates it uses to find neighbouring stops come out of the timetable file you downloaded.

Searches are computed on your computer and are never sent anywhere. What the desktop app does send:

  • A list of available timetables, requested from our server when the app starts, so it can tell you whether a newer one exists. This is a plain request for a file listing; it carries nothing about you beyond the request itself. Downloading a timetable is then your choice.
  • The directory of Swiss addresses, only if you ask for it. A one-off download, offered alongside the timetable, that lets you plan from a street rather than a stop. Like the timetable it is a file you fetch and then use offline; the addresses you go on to type are never sent.
  • A check for a newer version, only when you press the button in Settings. It fetches the same public list of downloads the website serves and compares the version numbers on your own computer. Your version number is not sent, and nothing checks on its own. If a newer version exists and you choose to download it, the app fetches that release file from our server, the same file the website offers, and tells the server that the download is an update, so that it is not counted as a new download. That request is logged like any other download of the app, as described under "Server Logs" below; the marker adds only the fact that it was an update. The copy installed from the Microsoft Store does not use any of this; the Store updates it.
  • Live delays, only if you switch them on. This is off by default. With it on, the app asks the server about the specific services shown on screen — not about you, and not about your search.
  • Train formation, only when you open the coach view for a service, and only while live data is switched on. That request names the train and the day.
  • A short link, only when you create one. Sharing a journey normally puts it after the # in a long link, which never reaches our server. If you ask for the short form instead, that one encoded journey is stored as described under Optional Short Links below. This is off unless you turn it on.
  • Feedback, only when you send it: your message, an optional subject and email address, and — so a report can be acted on — which part of the app it came from, the app version, the platform (macOS, Windows or Linux), the operating system, and the time. Any screenshots you attach yourself go with it. Nothing is sent automatically, and the desktop app has no crash or usage reporting of any kind — unlike the phone app, which sends the optional crash report described below.

Everything else stays on your computer: downloaded timetables, your settings, saved journeys, favourites and recent searches. They live in a folder in your user profile — %APPDATA%\spickme on Windows, ~/.local/share/spickme on Linux and macOS — and deleting that folder removes all of it. There are no accounts, no analytics, and no tracking.

The Web Planner

The planner in your browser holds no timetable, so it asks the server the questions the app answers on your phone. It is served at /plan and, for phones, at /m — the same planner, with the app download underneath it; everything in this section applies to both. While you use it, the following is sent to our server:

  • Your search: the departure and destination stop, the date and time you asked about, and whether you asked to depart or to arrive by then. This is what the server needs in order to compute a connection at all.
  • What you type into a stop field, as you type it, so the server can suggest matching stops.
  • Your position, only if you ask for it. Selecting "near me" makes your browser ask for permission; if you grant it, the coordinates it returns are sent to the server to find the closest stops. Decline and everything else keeps working. Your browser is what asks, and you can withdraw the permission there at any time.
  • The station you open a departure board for, to fill that board.
  • A day out, when you plan one: every stop you put along it, in order, and how long you want at each. A trip is a longer question than a single search, so it is a longer thing to send; it is answered the same way and kept no longer.
  • "How far can I get?", when you use it (/reach): the station, stop or address you start from, the day and time, and the most changes you allow. The server works out every stop you can reach and sends the list back; the time slider and the filters then work in your browser without asking again, unless you widen the time past what was fetched. It is answered the same way as a journey search and kept no longer. Each search adds one to a count for that page and day — a date and a number, with nothing about the search in it. Exporting the list or the map makes the file in your browser; nothing is sent.
  • "Where should we meet?", when you use it (/meet): the two stations, stops or addresses, the day and time, and the most changes you allow. The server works out the stations in between and sends a short list back; switching between "fairest" and "least travel" happens in your browser. It is answered and kept like a journey search, and each search adds one to that page's count for the day, in the same way.
  • Live delays and train formation: the identifiers of the specific services shown, so the server can look up their current delays and, if you open the panel, which coaches are running.

No search, position, suggestion query or departure board is written to a database or associated with an account. Planner journey answers may remain temporarily in a bounded 256-entry in-memory performance cache until eviction or server restart. Request bodies are not logged. Planner state in the browser URL is stored after the # fragment and is therefore not sent in the HTTP request. The ordinary server log records the IP address, time, method, status, response size and user agent, but omits the request target and referrer.

AI Assistants (The MCP Server)

An AI assistant you connect to https://spickme.ch/mcp — Claude, ChatGPT, Gemini, an editor, a script — sends our server the tool calls it makes for you: the places, addresses or coordinates, the date and time, the stops and stays of a day out, the origins and destinations of a comparison. Your conversation with the assistant is not sent to us; only these calls are. The assistant's provider processes your conversation under its own privacy policy.

  • Your questions are answered and not stored. The places, times and stops in them are not written to a database and not logged. Answers may sit briefly in the same bounded in-memory cache the web planner uses, until eviction or a restart.
  • The MCP server is not given your IP address. The web server in front of it records every request in its ordinary access log, as described under "Server Logs", but it does not pass the address on, so the service that answers the questions never sees it.
  • What is counted, per day: how many calls were made, of which tool, how each ended (answered, refused, busy), how long answers took, how many came without a key and with one, the name the connecting software gives itself (such as claude-ai), and the protocol version it used. With a key, the number of calls made with that key is counted too, per day. None of these counts contains an address, a place, a time asked about, or anything you typed. The daily totals are kept for at most 400 days, the counts per key for 35.
  • Keys, and what they tell us. Using a key is optional. A key — whether you take one from the page at /ai or your assistant receives one when you press "Allow" — is an identifier signed by our server. Calls made with a key are not anonymous to us: each is recognised as that key's, so we can see how much each key is used, day by day, and tell its calls apart from everyone else's; a key connected through an assistant also carries the name that software gives itself. We ask for no name, email address or account, but treat a key as belonging to you and do not share it. We may switch off a key that is misused or that places an unreasonable load on the service. No list of keys is kept: the server recognises one by checking its signature.
  • Alerts. When the number of calls in a day passes a threshold, the maintainers receive a notice in their Matrix chat room. It contains daily totals only.

What The Web Planner Keeps In Your Browser

To be useful on a second visit the site stores a small amount of data in your browser's local storage, on your device. It is available to same-origin site code but is not transmitted to our server:

  • your recent searches, and stops you mark as favourites;
  • your home and work stops, if you set them;
  • journeys you save, and the one you are currently travelling on;
  • departure boards you have opened, and a day out while you are still planning it;
  • your language and light/dark preference, and the planner's own settings — the transfer time you want at a change, and whether you last read a journey as a picture or a table;
  • the front page's most recent route, whether you have asked to read the front page on a phone, and game preferences or progress if you use the game.

Under Settings → Keep a copy you can export your saved journeys, favourites, home and work, recent searches, boards and rides as a file your browser saves where you choose, and import it in another browser. The file is made and read in your browser; nothing is sent to our server.

These are functional: they exist to do what you asked the planner to do, and there is no analytics, advertising, tracking or profiling storage of any kind — no third-party scripts run on the page at all. Under Swiss law (Art. 45c of the Telecommunications Act) we tell you this is happening and you may refuse it: block or clear site data for this site in your browser settings, or use a private window. The planner then simply forgets you between visits and otherwise works normally.

Cookies, And Why You Are Not Asked To Accept Any

This site sets no cookies. Not one — not for analytics, not for advertising, not to recognise you on a later visit. No page on the public site reads or writes document.cookie, and no response it serves carries a Set-Cookie header. The single exception is the operators’ own /ops dashboard, which sits behind a login and is not part of the site described here.

What the pages do use is the local storage listed above, and they use it only once you ask them to: pinning a light or dark theme, choosing a language, running a search that is then offered back to you next time. Arrive, read and leave without touching anything, and nothing is written at all. Because that storage does nothing but carry out what you explicitly asked for, and is never used to recognise or profile you, it is the strictly necessary case that Art. 45c lit. a and b of the Telecommunications Act and Art. 5(3) of the EU ePrivacy Directive both leave outside the consent requirement. That is why there is no banner: there is nothing here for you to accept.

Refusing it is still yours to do, and costs you nothing but the convenience: block or clear site data for this site in your browser, or use a private window. The site then forgets your theme, your language and your last search, and otherwise behaves exactly as before.

Feedback You Send

The app includes an optional feedback form. If you choose to send feedback, the following is transmitted to and stored on the Spick Me server:

  • Your message, plus an optional subject and an optional email address if you fill them in. Provide an email address only if you would like a reply.
  • Technical context added by the app or request: which screen the feedback was sent from, the app version, the platform, operating-system version and SDK level, device manufacturer and model, submission time, and HTTP user agent.

This information is used solely to understand and act on your feedback, improve the app, and reply to you if you provided an email address. It is not used for advertising or profiling. Feedback you write is sent only when you tap Send. The phone app also sends crash reports on its own; they use this same form and are stored in the same place, and the next section describes them. The feedback database does not store your IP address; the network request itself appears in the standard server logs described below, like any other request.

Crash Reports

The Android phone app can tell us when it has crashed. This is the only thing it sends without being asked each time, and it is switchable: Settings → App → Crash reports. It is on when you install the app; the setup wizard says so and offers you the same switch before you finish setup; and switching it off also deletes any report still waiting to be sent.

Nothing is sent while the app is dying. It writes one file into its own private storage; the next time you open the app, if the switch is on, that file is sent as an ordinary feedback report marked as a crash and is then deleted from your device. If the app is offline it stays and is sent the time after that. A second crash before it is sent overwrites the first, so at most one report is ever waiting.

A crash report contains:

  • The error and where it happened: the exception and its stack trace — a list of the lines of our own and Android's program code that were running — the name of the thread it happened on, and, when the crash came from the app's native routing engine, the source file and line inside it together with the message that failure carried. These messages are written by us and describe program state — a count, an index, a name of something in the code — not what you were doing.
  • Enough to tell builds and devices apart: the app version, the Android version and SDK level, and the phone model.

That is all of it. There is no identifier of any kind — no account, no device ID, no advertising ID, no installation ID — and nothing about what you were doing: not the journey, the stops, the search, the timetable or your location. No email address is attached and no screenshot is taken. There is no crash-reporting or analytics library in the app; this is a few lines of our own code sending one plain-text file, which is why the list above can be exhaustive.

Because a crash report carries no identifier, it cannot be linked to you, to your device, or to any other report, and we have no means of finding "your" crash report if you ask for it. Under Article 11 GDPR we are not obliged to acquire that means in order to answer such a request, and we will not: making the reports identifiable in order to be able to delete them individually would be a worse outcome for everybody than not keeping them long. What you can do instead is switch the setting off, at which point nothing further is sent and anything pending is deleted unsent.

Crash reports are stored with written feedback, are reachable only through the same authenticated administration interface, and — like feedback — are not stored with your IP address. They are deleted no later than 30 days after receipt, a shorter period than written feedback keeps, because a crash report stops being useful once the release it came from is behind us.

The Wear OS watch app, the desktop app and the web planner send no crash reports at all.

Optional Short Links

A normal shared journey is kept after the # in a long URL and never reaches our server. If you explicitly enable short links, the encoded journey payload, a random slug, and creation and expiry times are stored on the server for up to 365 days. Anyone who possesses the short link can open it. The app receives a private revocation token, stores it only on your device, and lets you revoke the link in Settings. The server stores only a hash of that token. Clearing app data or uninstalling the app loses the ability to revoke links early; they still expire automatically.

Catch Me

Catch Me, at /catch/ and in the phone app, is a game a group of people play together in person on public transport, and unlike the planner it needs the server to keep something: the game itself, so that every player's phone shows the same game. When you plan or join a game, the server stores the game's settings (its name, date, meeting stop and play area), the name you type for yourself, and a random token that lets your browser act as you in that game. The server keeps only a hash of the token; the token itself stays in your browser or, in the phone app, in the app's private storage, which is left out of device backups. No account, email address or phone number is asked for.

While the game runs, the server stores what the players choose to send: the stops the Fox reveals, which kind of vehicle the Fox says they boarded, the status and preset messages players pick, and — only for a Hunter who switches on sharing — the stop that Hunter chose to share with their team. These are always stops chosen by hand from a list. Your phone's position is never sent for the game: if you ask for stops near you, the position is used once to find them, exactly as in the web planner, and only the stop you then pick is stored. Players cannot write free text to each other.

Everything in a game is seen only by the players of that game, and less than that by role: the Hunters do not see where the Fox is between reveals, the Fox does not see the Hunters' team messages, and a player's catch code is shown to nobody else. The invite code travels after the # in the invite link, which never reaches our server logs. The stops Hunters shared are deleted the moment the game ends, so the result can be looked back on without them, and the game and everything else in it is deleted seven days after it ends, or two days after its planned end if it never started.

When a game ends, each player is asked for feedback. That is sent, only if you choose to, exactly like the feedback described under "Feedback You Send", together with the game's outcome, its length, your role and the number of players — never the names or the stops.

Server Logs

The Spick Me timetable server uses nginx and writes access and error logs. Access logs include IP address, request time, HTTP method and status, bytes sent, and user agent; they omit the request target and referrer. Error logs may include the request context needed to diagnose a failure. These logs are used to operate the service, troubleshoot downloads, prevent abuse, and keep the service secure.

Two further logs are written purely to count things, and neither carries anything about you that the standard log above does not: one records a timestamp, a status and a content type for every request, so the number of requests and pages per day can be shown; the other records a timestamp, a status, the file name and whether the desktop app's updater fetched it, for downloads of the app, so we can see how often each platform's release is downloaded and tell a new download from an update. Neither contains an IP address, a user agent or a referrer, and neither can be tied to a person.

Server logs are not used to profile users, are not sold, and are not used for advertising. Container access and error logs are bounded to three files of 10 MiB per service. Aggregate traffic, download and planner-search counts contain no IP address or user identifier and keep at most 400 dated daily entries.

How Information Is Shared

Spick Me does not sell personal information.

The phone and desktop apps do not send your searches, saved journeys, favourites, recent searches, or location to the Spick Me timetable server, except that choosing an optional short link sends that one encoded journey as described above. The web planner sends searches unless you keep the timetable on your device, and sends your position if you ask it to find nearby stops — see "The Web Planner" above; neither is stored persistently as a search history.

Feedback you send is stored on the Spick Me server and is accessible only to the project maintainers. If chat notifications are enabled, the configured Matrix homeserver receives only a generic "New feedback" notice and a link containing the report number; opening the report still requires authentication to the ops dashboard. The message, email address, technical metadata and screenshots are never sent to Matrix.

If you use watch features, relevant journey or nearby departure data is shared from your phone to your paired watch through Google Play services. Google Play services is provided by Google and may process data as described in Google's privacy policy.

Opening a connection in another app or site. A journey offers a "Ticket" action. Tapping one of its entries opens that provider — SBB Mobile, Fairtiq, the SBB timetable at sbb.ch, the ÖBB timetable at oebb.at, Deutsche Bahn at bahn.de, search.ch, Google Maps or Apple Maps — outside Spick Me, and where the provider can take a pre-filled search, the address it opens carries the two station names and the departure time of that connection, and nothing else. This happens only on your tap and only for the entry you tap; nothing is sent in advance, no identifier or tracking parameter is added, and Spick Me does not learn what you do there. What each provider does with a search you open is governed by that provider's own privacy policy. On Android the app also checks whether SBB Mobile and Fairtiq are installed, in order to open the app rather than its store page; that check stays on the device.

Retention And Deletion

Local app data remains on your device until you delete it in the app where controls are available, clear the app's storage, or uninstall the app. You can revoke location permission at any time in Android settings; the desktop app never asks for one. On the desktop, deleting the data folder named under "The Desktop App" removes everything the app keeps.

What the web planner keeps in your browser — your settings, recent searches, and the timetable if you chose to keep it on the device — stays there until you remove it in the planner's settings or clear site data for this site, or use a private window that discards it when you close it. Location permission for the site is granted and withdrawn in your browser, not by us.

Access and error logs are retained only within the bounded rotation described above. To request deletion of entries that may relate to you, contact the project with the approximate date, time, and IP address of the request.

The MCP server's usage counts, described under "AI Assistants", are kept for at most 400 days as daily totals, and for 35 days per key; after that a key's calls are no longer told apart from anyone else's. A key can be revoked on request if you send us the key or its identifier; its per-key counts then age out after the same 35 days.

Crash reports are automatically deleted no later than 30 days after receipt. Feedback submissions and screenshots are automatically deleted no later than 365 days after receipt and may be deleted earlier when no longer needed. To request earlier deletion, contact the address below with the approximate submission date and, if you provided one, the email address you used. Short links expire after 365 days and are physically purged by automated maintenance; the creating app can revoke newer links earlier. A Catch Me game is deleted seven days after it ends, as described under "Catch Me".

Purposes And Legal Bases

  • Requested service, Article 6(1)(b) GDPR: delivering downloads, answering web-planner, live-data and formation requests, synchronising a paired watch, and creating an optional short link when you ask for one.
  • Legitimate interests, Article 6(1)(f) GDPR: limited operational logs, rate limiting, security, troubleshooting, aggregate service statistics, handling feedback, and receiving crash reports. The interests are keeping a small public service reliable and secure and improving it without behavioural tracking; for crash reports specifically, learning that the app is broken on a device we do not have, which without them we would learn only if somebody chose to write to us. A crash report carries no identifier and no content, is kept for thirty days, and can be switched off in the app — which is the balance that makes this interest the overriding one.
  • Consent, Article 6(1)(a) GDPR where required: optional device or browser location. Permission can be refused or withdrawn in system or browser settings without affecting other features.

No information is required by law. Without location permission, "near me" is unavailable; without browser storage, preferences are forgotten; without an email address, we cannot reply to feedback; and without short-link storage, the private long link remains available.

Your Rights

Where the GDPR applies, you may request access, correction, deletion, restriction, and portability where applicable; object to processing based on legitimate interests; and withdraw consent without affecting earlier lawful processing. You may complain to the Swiss Federal Data Protection and Information Commissioner or, where applicable, the data-protection authority in your EU or EEA country.

Send a request to unfreqapp@gmail.com. Include enough information to locate the record, such as the feedback date and email address or the log date, time and IP address. We may request proportionate verification, normally respond within one month, and ordinarily charge no fee. Because there are no accounts, we cannot identify device-only data or server records without a usable identifier.

Automated Decisions

Spick Me does not use personal data for profiling or automated decisions that produce legal or similarly significant effects.

Security

Timetable downloads and feedback submissions are made over HTTPS from and to `https://spickme.ch`. Downloaded timetable files are verified against checksums advertised by the server before they are installed. Local app data is stored in Android app-private storage. Stored feedback is accessible only through an authenticated, rate-limited administration interface.

Children

Spick Me is not directed to children under 13. The app does not knowingly collect personal information from children. Catch Me's rules ask that players under 16 play together with an adult.

Changes

This policy may be updated when the app's data practices change. The effective date at the top of this page will be updated when changes are published.

Contact

For privacy questions or deletion requests, contact the project at unfreqapp@gmail.com.

This policy applies to the Spick Me Android and Wear OS apps, the Spick Me desktop app for macOS, Windows and Linux, the Spick Me web planner, the Spick Me timetable download service, the live-data and train-formation services, and the Spick Me feedback service. See also the Terms of Use and the Legal Notice.