Privacy
No cookies, no accounts
The service creates no accounts, uses no cookies and sends nothing to external analytics services. There is no script here from any outside server — the content security policy does not allow one.
What stays on your device
Favourite boards, the order of pinned stops, the theme and the selected city are saved in your browser and are never sent to the server. You can export them to a file and import them on another device — that is the only way they leave your hardware, and you do it yourself.
The visit counter
The service counts how many people use it. It does so in a way that makes it impossible to reconstruct who did what:
- An IP address never reaches disk. Only the count of visits is written to the
database.
- To tell two visits apart from one, we use a hash of the address, the browser and
a random salt that changes at midnight and is never stored.
- After the salt changes, the same person has a different hash. Their visits cannot be
linked across days, and the hash cannot be turned back into an address — not even with full access to the entire database and the entire code.
The cost of this decision is that the number of unique visits in a month is not the sum of the daily figures. We decided that a measure which cannot be abused is worth more than a more precise one.
Exactly what the counter stores
To leave no doubt, here is the complete list. There is nothing here but numbers.
| what | example | what for |
|---|---|---|
| hour and count of unique hashes | 2026-09-04 14:00 → 12 | “how many people and when” |
| request category | api → 980 | traffic proportions, transfer cost |
| path without the query string | /api/departures | which screens are used |
| client class | mobile / desktop / bot | whether to build for phones |
What is not there: the IP address, the full User-Agent, stop keys, request bodies, or any identifier that would survive a day. The path is stored without the part after the question mark — /api/departures, never /api/departures?keys=… — because stop keys would say where somebody is going.
The client class is three buckets derived from the User-Agent and immediately forgotten: the header itself is never stored. Bots are counted separately, because without filtering them out the visit count is fiction — they can account for most of the traffic.
What this counter cannot do, and never will
We cannot say how many regular users there are. The salt changes at midnight, so the same person has two different hashes on Monday and Tuesday, and there is no way to link them. A week's visits add up to “visit-days”, not a number of people, and they are labelled that way in the statistics.
This is not a shortcoming to be fixed in a future version. Counting regular users would require an identifier that survives a day — exactly the thing that is not here. We chose the weaker measure, but one that cannot be abused.
“Time to leave” notifications
If you turn on a departure reminder, the service stores a notification subscription — an identifier your browser receives from its own push service (Google, Mozilla or Apple, depending on the browser). It is the only thing in the whole service that survives a day and is tied to a specific device. We stored nothing of the kind before, and we are not changing that lightly.
What the server knows about your alarm
Exactly two things: an opaque identifier and a wake-up time.
The database holds something like k7QmAbCdEfGh and a timestamp. There is no line number there, no destination, no stop. The identifier is a hash computed in your browser, and the server has no dictionary to reverse it.
The line number and destination are held by your device alone — they sit in the app's local storage and are only assembled into the notification text there. That is why the service's database cannot reveal where anybody travels, even with full access to it.
What the push service receives
Only the encrypted packet. The content is encrypted with a key known only to your browser (the RFC 8291 standard) — Google and Apple cannot see what is inside. They do know that we sent you something at a given time; that is unavoidable with any push notification and applies to every app that uses them.
It will not work in every browser
A notification with the app fully closed requires the Push mechanism, which in Chromium rests on Google services. Browsers that deliberately remove those services — Cromite, Bromite, ungoogled-chromium — do not support it, and that is their deliberate privacy decision, not a fault of this service.
In those browsers the reminder will work while the app is running, including in the background. The service detects this situation and says so plainly in Settings, rather than promising a notification that will not come.
It is worth knowing that on Android switching browsers is no way out: push delivery rests on Google Play services and every browser needs them, Firefox included, which uses Google's mechanism for the delivery itself. On a device without those services, notifications with the app closed will not work in any of them.
On iPhone and iPad, notifications require adding the site to the Home Screen — in an ordinary Safari tab they do not work at all.
How to turn it off, and what disappears
Turning off a reminder removes the alarm from the server immediately. Withdrawing notification permission in your browser settings invalidates the subscription — the service finds out on its first failed delivery and deletes it from the database. A subscription that has received nothing for 90 days is deleted on its own.
Your location
If you enable location, the service will show your position on the map and will be able to calculate distances to stops.
The coordinates do not leave your device. There is no request that would send them; the map asks the server about the area around the centre of the view, not about where you are. Distances and walking times are computed by the browser from data it has anyway: stop coordinates arrive in the stop catalogue, and vehicle positions in the request about the surrounding area.
Nor is the position stored anywhere — not on disk, not in browser storage. It lives in the open tab and disappears with it.
A dedicated test watches over this, checking that no data transmission has appeared in the location module. This is not a matter of good intentions: a single added line could void that promise, while the feature carried on working exactly the same and nobody noticed.
The position receiver runs only while the map is open and switches off with it — left on permanently it would drain the battery, and there is no way to notice that.
Public transport data
The history of departures and vehicle positions is stored, because punctuality cannot be calculated without it. It covers only vehicles, services and stops — not the people using the service.