Privacy Policy

Last updated: 2026-10-29

This policy explains what Tourlet does with data: the Android app (name.gpm.tourlet), and the two services it can optionally talk to — its own backend at https://tourlet-app.gpm.name and the web app it serves at that address.

The short version: a trip lives on your phone, and nothing about it reaches our server unless you sign in. (The map and place search talk to other services on their own; they are described below.) Signing in is free and does not by itself send anything. What sending your trips elsewhere buys is Tourlet Pro — sync to your other phones and to the web app, and sharing a trip with somebody else — and it is not end-to-end encrypted: our server stores what you sync in a form it can read. That is stated plainly below, in its own section, because it is the one fact about this app worth reading before you turn sync on. The one other thing that shows what you wrote to people you did not choose is Explore, where you can publish a trip for anybody; it is off unless you publish, and it has its own section.

Who is responsible

Gabriele Proietti Mattia is the data controller for the processing described here. Contact: apps@gpm.name.

What stays on your phone by default

A trip — its places, legs, day-by-day plan, notes — is the app’s own data on your device. Nothing about it is read by, or sent to, anyone until you sign in and turn sync on. An install that never signs in never talks to our server at all, and everything in the app works that way: creating and editing trips, the map, place search, up to ten trips of your own.

Signing in

Sync and sharing need an account. Signing in is free, does not require Pro, and is proved one of two ways:

• A code sent to your address. You type an email address, our backend mails a six-digit code through Mailjet — a plain-text message with the code, how long it is good for (15 minutes, one use), and nothing else: no tracking pixel, no link that identifies you. You type the code back into the app.
• Signing in with Google, in the Play build only, through Android’s Credential Manager. Google hands the app an ID token; the app does not read it as identity — it goes to our server, which checks its signature against Google’s own keys and reads out of it the account’s stable identifier (“sub”), the address, and the name, all three of which it stores. The token also carries the address of your Google profile picture: unless you have set a picture of your own or removed the Google one, our server downloads that picture from Google (only from Google’s own image server, at most once a day) and keeps it as your profile picture, which the people who share a trip with you can see — see “Your profile picture” below. The app also draws it locally while sign-in is still in flight.

Either way you get a session key, kept on the phone and sent with every later request; the server keeps a hash of it, not the key itself. F-Droid build: no Google button — the code sign-in is the whole of it, the same account either way.

Syncing a trip — Tourlet Pro, and not end-to-end encrypted

Turning sync on requires Tourlet Pro (see “Tourlet Pro” below) if you are the trip’s owner; a trip shared with you keeps syncing for you for free, for as long as its owner is Pro — you did not choose to be billed for existing on someone else’s trip.

Once it is on, every place, leg, day item and note you write is sent to our backend at https://tourlet-app.gpm.name and stored there as you wrote it, so your other phones — and the web app at that same address — can read it. This is not end-to-end encrypted: our server can read what it stores. What protects it is:

• TLS on every request, with no unencrypted fallback;
• who can reach the server and its database — Gabriele Proietti Mattia and nobody else;
• nothing else. There is no search across trips and no analysis of what is in them. (The Play build can be sent a push notification when someone invites you or changes a trip you share; see “Push notifications” below.)

Requests to https://tourlet-app.gpm.name pass through Cloudflare, which proxies that address, so Cloudflare handles them in transit as any proxy in front of a website does.

If two devices edit the same thing, the one that reaches the server last wins, and the one it replaced is not thrown away: it is kept for seven days, the app shows you that something was overwritten, and it can be put back in that window. After seven days a nightly job deletes it for good.

What the server keeps alongside a synced trip: the account it belongs to, who last touched each item and when. What it never does with what it can read: build a profile from it, train anything on it, or show it to anyone you have not shared the trip with.

While the app is open and you are signed in, it keeps one connection open to our server so a change made on another phone or on the web reaches you within a couple of seconds, instead of waiting for the next sync. See “Who is online, and editing together” below for what that connection also tells the other people on your trip.

Signing in and using the app on one phone, with sync off, sends none of this — an itinerary typed in and never synced is exactly as private as it was before this feature existed.

Sharing a trip — inviting is Pro, accepting is free

The trip’s owner can invite somebody else to it by email, and that costs the owner Pro the same way turning sync on does. Accepting or declining an invitation you were sent is free, whether or not you have Pro yourself.

Inviting somebody sends a plain-text mail, again through Mailjet, that names the inviter’s own address and the trip’s name and says how to accept (sign in with that address, in Settings → Sync). It is good for 30 days. Once somebody is a member, every member of a trip can see the email addresses and names of the trip’s other members, and the profile picture each has set (see below) — there is no way to share a trip anonymously.

Removing yourself from a trip, or an owner removing somebody else, is one call away in the app; neither deletes anything the person kept on their own phone before that.

Who is online, and editing together

Holding that open connection is what “online” means. The other members of a trip you share see that you are online, and whether you are on the web or on a phone. While you are editing an item (a stop, an activity, a movement, the trip’s title or dates and so on), it is locked for the others: they see that you are editing it and cannot edit that item until you finish, or your connection ends and the lock expires (about 45 seconds after it stops being renewed; the lock is kept by your open connection, not written into your trip). Nothing about who is online is kept afterwards: it exists only while the connection is open. The person running the service sees the count of who is online, in the operator’s page described below.

Your profile picture

If you set a profile picture (PNG, JPEG or SVG, up to 1 MB), it is stored on our server, and it is shown to you and to the people who share a trip with you, on their phones and in the web app; nobody else can fetch it. The app crops it to a square and reduces it before uploading (an SVG is turned into a PNG on your device: the server never receives the SVG), and the server re-encodes it, which removes any metadata in the file, including the location a photo may carry.

If you sign in with Google and have not set a picture of your own, your Google profile picture becomes your profile picture (see “Signing in”), shown to the same people in the same way. A picture you upload always replaces it. If you remove it in Settings, it is deleted and is not fetched again at your next Google sign-in, until you choose “Use my Google picture”. Your picture, whichever it is, is deleted with your account.

Your language

If you choose a language for Tourlet (Settings on the phone, the account page on the web), and you are signed in, the choice is kept with your account — “Automatic”, English or Italiano — so the phone and the web app follow the same one. It is used only to show the apps in that language; nobody else sees it, and it is deleted with your account. Signed out, or in the F-Droid build without an account, it stays on the device.

Trip covers, and Unsplash

A trip can have a cover photo. One you upload yourself is stored on our server — like an attachment, and counted in the same 100 MB a trip may hold — and is visible to the trip’s members. It is deleted with the trip, and always with the account.

You can also pick a cover from Unsplash. The search goes through our server, which asks Unsplash on your behalf with the words you typed and nothing else about you or the trip; when you choose a photo, our server also tells Unsplash that it was chosen, as Unsplash’s rules require. The chosen photo itself is loaded from Unsplash’s own servers by whoever views the trip, so Unsplash sees that device’s IP address, the way any image on a web page is fetched. The trip keeps only the photo’s address and its credit line (the photographer and Unsplash).

Lists of places

The lists you keep in a trip — “where to eat”, “main sights” — and the places in them (name, address, coordinates, your note, a link, whether you ticked it) are part of the trip, synced and visible to its members like everything else in it. They are covered by the same “Syncing a trip” section above.

The public link — Tourlet Pro, off by default

The owner of a trip can turn on a read-only public link. Anyone who has the link can see the trip in a web browser without an account, and can pass the link on to anyone else, so share it as you would a photo you posted. Creating it needs Pro; looking at it and turning it off do not.

What the link shows: the trip’s name, dates, day colours and cover; the stops (name, arrival and departure, time zone, coordinates); each day’s activities (title, type, date, time, place, coordinates, opening hours); the moves between places (mode, from and to, carrier and number, times and status); and the lists and their places (name, place, coordinates, link); and the footprints you shared (see “Footprints”). The owner chooses whether the link shows the days, the map, the lists and the footprints.

What it never shows: notes (including the notes on a movement), costs and budgets, bookings and confirmation codes, ticket numbers and seats, attachments, the people on the trip (members, addresses, pictures) and who is online, the names of the travellers and their seats, the street address you typed by hand for a stop, your recorded routes, footprints you kept to yourself, and suggestions you have not accepted. The server decides this from a fixed list of what may be shown, kind by kind, so a new field added to the app stays private until it is put on that list.

The link’s secret is in the part of the address after the #, which a browser does not send when it opens a page; the page then passes it to our server in a request header. So it is not in the web server’s or our own logs. Our server does store it, unhashed, because the owner has to be able to see the link again. The public pages ask search engines not to index them, and each address is limited in how many requests it may make. If the viewer opens the map, their browser loads tiles from OpenFreeMap (see “The map”), and an Unsplash cover comes from Unsplash’s servers.

Turning the link off makes it stop working at once, and turning it on again makes a new, different link. Deleting the trip or the account deletes the link.

Explore — publishing a trip for everyone

Explore is a part of the app where people publish a trip for anybody to browse, like and copy into their own trips. It is free, it needs an account (not Pro), and it is off unless you publish: a trip you do not publish is exactly as private as before. Only the trip’s owner can publish it. Browsing, liking and copying do not need Pro; browsing and copying do not need an account either.

What becomes public: the trip’s name; the stops (name, time zone, time of day, coordinates); the days, shown as Day 1…N together with the month and year the trip starts; the movements (mode, from and to, carrier, times of day) without their numbers; the activities (title, type, place, coordinates, opening hours); the lists and their places (name, place, coordinates, link); the cover if it is an Unsplash photo; if the trip has a budget, a band (under €60, €60–150, over €150) and a figure in euro per person per day; the optional description (up to 500 characters) you write when you publish; and your public name. The countries are worked out by our server from the stops’ coordinates, or from their time zone when there are none.

What never becomes public: notes; individual prices and costs; ticket and confirmation numbers and booking codes; attachments; the people on the trip; your account name, e-mail address and picture; the real dates; a cover photo you uploaded; recorded routes; drafts. The server decides this from a fixed list, as for the public link, so a field added to the app stays private until it is put on that list. One thing to know: a trip you publish before it ends shows the month you are travelling, even though it never shows the days.

Your public name is a pseudonym you choose the first time you publish, and can change. It is separate from your account name, which only the members of your trips see, and it is never your e-mail address. “Tourlet” is reserved. It is the only thing that identifies you to people browsing Explore.

The budget. The figure is the trip’s planned budget (or, if there is none, the sum of its planned costs) divided by the number of travellers you type when you publish (1 to 20, asked only when the trip has a budget) and by the number of days, converted to euro with the European Central Bank’s daily reference rates. Our server downloads the ECB’s public rates file once a day; nothing about you or the trip is sent to the ECB. The figure is fixed when you publish. A trip with no budget, or one in a currency the ECB does not publish, is shown without it.

Likes, copies, reports.

• A like is stored with your account, so you can take it back; the author sees only how many there are.
• A copy: “Use this trip” builds a new trip on your phone from the published snapshot, with the dates you choose. It works without an account. When somebody copies, our server counts it once per account, or per day per hashed address when there is no account — a count the author sees, not who.
• A report: anybody may report a publication, with or without an account. A report carries a reason and an optional note of up to 500 characters. When the reporter is not signed in, the server stores a salted hash of their network address, never the address, so that one reporter counts once per publication. Reports are limited per address.
• Hiding an author: you can hide an author’s trips from your own Explore. The choice is stored with your account.

The automatic check. Before anything is published, every text that would become public — the trip’s name, the description, stop names, activity titles, places and locations, opening hours, list and place names, links, carrier names, and your public name — is sent from our server to OpenRouter, which forwards it to the model that checks it, currently Google Gemini (google/gemini-3.8-flash), looking for hate, sexual content, violence, spam and advertising, and personal data. Only the text is sent: not your account, your address or the rest of the trip. If the check cannot be made, nothing is published, and the app says to try again. The check is a machine and gets things wrong in both directions; it is not a promise that what is published is acceptable.

Moderation by a person. The person running the service sees the reported publications, with what the public sees, the reasons and notes, and how many different reporters there are. From there they can keep a publication, hide it, remove it, or ban its author, which removes all of that author’s publications. A publication reported by three different reporters is hidden automatically until the operator has looked at it; the author is told it is hidden pending review. The rules for what may be published are the community terms.

Removing a publication. The owner can remove a publication in the app at any time; it stops being shown at once, and its likes go with it. Updating a publication replaces what is shown and keeps its likes. What somebody has already seen or copied cannot be recalled: a trip someone copied is theirs. A publication that moderation has removed is not shown to anybody, but the server keeps its record, marked “removed”, so that it cannot be updated or put back and the decision can be checked; that record is kept until the account is deleted.

Search engines. The Explore pages ask search engines not to index them, and each address is limited in how many requests it may make. That is a request: it stops nothing that ignores it, and what is public is public to anyone who opens it. When somebody looks at a published trip, their own app loads its map and its Unsplash cover the way it loads them for their own trips (see “The map and place search” and “Trip covers”).

Deleting the account deletes your publications, your likes, the reports you made and the authors you hid.

Suggestions — Tourlet Pro, and only when you ask

Turn on trip suggestions and Tourlet sends the trip’s own structured data — its name, its places’ names, dates and coordinates, each leg’s mode of travel, and the optional interests text you typed — from our server to OpenRouter, which forwards it to the model that answers, currently Google Gemini (google/gemini-3.8-flash). The request includes a web search step, so the answer can use current opening hours and the like: OpenRouter runs that search through Parallel, so search queries derived from your request reach Parallel as well. Nothing is sent unless you ask for suggestions on that screen; there is no background or automatic use of this feature. What comes back is a fixed set of fields — a title, a note, a place, a rough cost and duration — never a free-form reply, and never written into your trip without you choosing to accept it.

This is metered: a daily and a monthly limit per account, and a shared limit across every account, so one person’s use cannot exhaust what everyone else’s Pro subscription paid for. Our server logs no trip content and no model output — only that a request was made, and, if the model provider failed to answer, that it failed.

Flight status — Tourlet Pro

Look up a flight, or watch it, and the number and date you ask about go through our server to AeroDataBox (reached through RapidAPI), which answers with that flight’s schedule and status. Our server caches an answer briefly — a few minutes to an hour, depending on how soon the flight departs — so asking again shortly after does not repeat the call to AeroDataBox. Nothing about your trip beyond the flight number and date is sent.

Watching is per phone: the phone keeps its own list of the flights it watches and asks again as the flight approaches. The alerts are notifications the phone makes itself from the answers it gets; our server does not send you a flight alert.

Weather — Tourlet Pro

For a stop that has a point on the map, the app can show the temperatures usual there at that time of year and, for the days just ahead, the forecast. The app asks our server, sending the stop’s coordinates, its time zone and the dates — nothing else about the trip. Our server asks two services on its own, with the point rounded so it no longer marks a building:

• NASA POWER (NASA Langley Research Center), for the monthly climate averages, with the point rounded to a half-degree grid (about 50 km). The averages do not change, so our server keeps them and asks again only after a year.
• MET Norway (the Norwegian Meteorological Institute), for the forecast, with the point rounded to two decimals (about 1 km). Our server keeps a forecast for as long as MET Norway says it is current, usually under an hour.

Neither service is told who you are or which trip the point belongs to: they see our server, not your phone. The figures are shown with their sources’ credit, as their licences require — forecast data from MET Norway (CC BY 4.0), climate data from the NASA POWER project.

To name the days after their city, when a stop does not already say which city it is in, the app asks our server which city the stop’s point falls in. Our server asks Nominatim, run by the OpenStreetMap Foundation (United Kingdom), on its own, with the point rounded to three decimals (about 100 m) and the language of the app. Nominatim is not told who you are or which trip the point belongs to: it sees our server, not your phone or browser. Our server keeps its answer — the city and the country, with the rounded point and nothing that says who asked — for up to 180 days (7 days when there is no city there), and gives it to anyone who later asks for the same point; it does not write the points in its logs. The city found is saved on the stop, in the trip, and you can change it by hand. City names © OpenStreetMap contributors.

Routes on the map — Tourlet Pro

On the map, a move on foot, by car, bus or boat can be drawn along the real road or path instead of a straight dashed line. The app asks our server, sending the two ends of that one line and how you travel — no names, no dates, nothing else about the trip. Our server asks OpenRouteService, run by HeiGIT gGmbH (Heidelberg, Germany), on its own, with the two points rounded to four decimals (about 11 m).

OpenRouteService is not told who you are or which trip the points belong to: it sees our server, not your phone or browser. Our server keeps its answer — the line, its length and its duration, with the rounded points and nothing that says who asked — for up to 180 days, and gives it to anyone who later asks for the same route, so the same line is not sent again; our server does not write the points in its logs. Without Pro, offline, or when the service is not available, the map keeps the straight dashed line and sends nothing. The small vehicle icon on each line is drawn on your device and sends nothing. While a route is shown, the map credits it: © openrouteservice.org by HeiGIT, map data © OpenStreetMap contributors.

Recording your route — Tourlet Pro, off by default

Switch on “Record my route” for a trip and the app asks Android for foreground location — while the app is in use — then records points (time, latitude, longitude and accuracy) from the trip’s first day to its last, and uploads them to our server. You choose one of three accuracy levels for the phone: about every 60 seconds and 100 metres at the lowest, every 20 seconds and 25 metres by default, every 3 seconds and 5 metres at the highest, which uses GPS. It runs as a foreground service, and a persistent notification stays on screen for as long as it is running, so it is never silent about it. Tourlet does not ask for background location: if Android stops the recording, it resumes the next time you open the app. Every point is visible to that trip’s other members, the same as the rest of the trip. Points are deleted when the trip is, or when the account is, and you can delete your own points on a trip at any time, independently of deleting the trip itself. Recording is off by default and is switched on per trip, never for the account as a whole.

Following a trip live — Pro for the traveller, free for the people who follow

A traveller with Pro can share a trip live: a link (tourlet-app.gpm.name/f/#…) that shows the trip’s flights as they happen, the traveller’s last position with its time, and the public plan. The link works without an account and stops working by itself the day after the trip’s last day; the traveller can revoke it, pause the position, and remove anybody who follows. The traveller also chooses whether the followers see the days, the map, the lists and the footprints, and can type the names of who is travelling (at most 6, up to 40 characters each); those names, and only those, are shown to the followers. (If none is typed, the followers see the name of the account that shares the link.) The names on the trip itself and the seats are not what is shown: see “Who is travelling”. The traveller chooses, per link, whether the position is exact or approximate (a point on a grid of about a kilometre, rounded on the phone before it is sent, so the exact point is never stored). Followers only ever see one point, never a route. While a live link is active and the trip is in progress the phone keeps sending its position with a notification on screen, the same foreground service as route recording, even when route recording is off; those points move only the live position and are not added to the trip’s route.

People who follow the link may ask to be told about delays, gate changes, take-off, landing and cancellation, and when the position is paused or has stopped. For that the server stores, about each of them, a name they type (shown to the traveller), their language, and one way to reach them: their browser’s push subscription, their e-mail address (only after they confirm it from a link we send; an address not confirmed within 24 hours is deleted), their Telegram chat id (if they start our bot, @gpm_tourlet_bot), or the notification token of the Tourlet app used without an account. The server also keeps the last known state of the trip’s flights, asked of AeroDataBox with the flight number and date only. Anyone can stop following at any time (a button, /stop in Telegram, a link in every e-mail). Everything about followers, and the live position, is deleted seven days after the link stops working or is revoked. Nothing about a follower is written to our logs, and the link’s secret travels in a URL fragment and a request header, so it appears in no access log. Processors: Mailjet (e-mail), the browsers’ push services (Google, Mozilla, Apple, Microsoft), Google Firebase Cloud Messaging (the app) and Telegram (the messages and the chat id).

Footprints — a diary of the trip

A footprint is a moment you write down: a few words, the place (its name and coordinates), the time and its time zone, and up to ten photos. The text, the place name, the coordinates, the time and the time zone are part of the trip: like the stops, they sync to our server when sync is on, and the people the trip is shared with can see them. Each footprint is either only yours or shared with the people following the trip; only a shared one can appear in the public link or in a live share, and only if that link shows footprints (see “The public link” and “Following a trip live”).

Photos, Play build. A footprint’s photos go from your phone straight to your own Google Drive, into a folder called tourlet (with a folder per trip inside it), after you agree to it the first time. The permission is drive.file: the app can only see the files it made itself, nothing else in your Drive. Our server never receives the photos. It stores only what the footprint needs to show them: the Google Drive file ids and the size of each picture.

When a footprint is shared, its photo files in your Drive get “anyone with the link can view”, so that the follower page, the public link and the other travellers can show them. Those pages load the photos straight from Google’s servers, with an API key, so Google sees the viewer’s request (and IP address), as it does for any file served from Drive. Making a footprint private again removes that permission from its photos. Deleting a footprint, or removing a photo from it, deletes the photo files from your Drive (when the phone is connected to your Drive at that moment). Disconnecting Drive in Settings stops new photos going there but does not touch the files already in your Drive.

Photos, F-Droid build. They stay on your phone and are never uploaded; there is no Google in this build. Other people see a footprint’s text and place, not its photos.

Who is travelling — private trip data

You can type the names of the people travelling on a trip, and give each of them a seat on a flight or a train. These are private trip data: they sync to the members of the trip like the rest of the trip, and they are never in the public link, in the live share’s itinerary or in Explore. Likewise the street addresses you type by hand for a stop and the notes on a movement (“booked with Trip.com”) are never public. What a live share tells its followers about who is travelling is only the names typed in the live share’s own sheet, as described in “Following a trip live”.

The trip video — made on your phone

From the Sharing tab you can make a short video of a trip (the map moving from city to city, a card for each stay, the trip’s numbers). It is made entirely on your phone: the trip’s data and your photos are never sent anywhere to make it, and our server is not involved. If you pick a music file from your phone for it, the file is read on the phone to build the soundtrack and is never uploaded. (In the Play build, a footprint’s photo that is kept in your Google Drive is first fetched to the phone from Drive, as the app does to show it; see “Footprints”.)

To draw the map behind the route, the phone asks OpenFreeMap (tiles.openfreemap.org) for the map of the trip’s area — in both builds, including the Play build that otherwise draws the map with Google Maps. OpenFreeMap receives that area and your IP address, as described in “The map and place search”, and nothing else about the trip. The close-up maps on short moves are drawn the same way, from map tiles of those places downloaded from OpenFreeMap.

By default the video shows the cities and how you moved between them; the route you recorded appears only if you choose it, because it shows the streets you actually took. Only your own photos (the trip’s cover, the pictures you attached) and an Unsplash cover with its credit can appear in it; Google’s photos of places never do. The finished video stays in the app’s own cache until you share it or save it to your gallery; sharing it — to Instagram or anywhere else — is your choice, and from then on it follows that service’s rules.

“My location” on the map — never sent

The Map tab has a “my location” button (and so does the web app’s map). It asks for location permission only when you tap it, and asks again only if you tap again. It centres the map on where the device is, and that position is drawn on your screen and is never sent anywhere — not to our server, not to a map service. If location permission is already granted (because you use route recording, for instance), the phone’s map also draws your position as a dot, still only on your screen. In the web app the position comes from your browser’s own geolocation, on click only, and stays in the browser.

Attachments — Tourlet Pro

A receipt or a ticket you attach to a trip is stored on our server — the file itself, its name, its type, its size and a checksum — visible to that trip’s members the same as the rest of the itinerary. A trip may hold 100 MB of attachments and cover together. It is included in the nightly backup our server keeps for 14 days, and it is deleted when the trip, or the item it is attached to, is deleted, and always when the account is.

Bookings forwarded by e-mail — Tourlet Pro

On a trip you can edit, Tourlet Pro can give the trip its own e-mail address. Forward a booking confirmation there and Tourlet reads it and offers the booking as an imported booking for you to add to the trip, or discard. Nothing reaches the itinerary without you adding it. Only a Pro holder’s address works, and the holder can change or switch off the address at any time; a mail to an address that is switched off or unknown is refused.

What is read, and how. The mail is read in three steps, stopping at the first that understands it: first the structured data many airlines and hotels put in their mails (schema.org markup, Apple Wallet passes); then the barcode of a boarding pass; and only when neither is there, a language model, through OpenRouter. OpenRouter is asked to use only providers with zero data retention, and not to allow data collection for training; the mail text, or a PDF or image attached to it, is sent to it for that one reading, and nothing else about your account, your trip or the other members is sent with it. OpenRouter is a processor acting for us, and the model reads the mail only to fill in the fields of a booking. Our server logs no mail content and no model output — only that a mail was received and which step read it.

What is kept. The raw mail is kept for at most 7 days, so you can open the original file behind a booking, and is never included in a backup. What is read from it is kept as a card: the booking’s own fields (kind, name of the place or carrier, dates, times, booking code, seat, price). Nobody’s name and no payment details are read into it or stored. A card that nobody adds or discards is deleted 30 days after it was last updated; once a card is added or discarded, the record of what happened to it (who, when, the key that stops the same booking appearing twice) is deleted 30 days later. An added booking is an ordinary item of your trip from then on, and is kept like the rest of it.

Fellow travellers. A forwarded mail can contain other people’s data — a family booking lists everyone on it. Only what the trip shows is kept: you add what concerns you, and anything else is dropped when the card is.

A limit. To keep this useful and its cost bounded, each holder can have 50 mails a month read, and there is a shared limit across every account. We count mails accepted, refused and read, by step; those counts hold no address, subject or content.

AI assistants — letting an assistant work on your trips (Tourlet Pro)

You can connect Tourlet to an AI assistant that supports connectors (MCP) — for example Claude, by Anthropic, or ChatGPT, by OpenAI. Nothing happens unless you add Tourlet in that assistant yourself and press Allow on Tourlet’s own page, signed in to your account; that page shows the app’s name and the address it returns to, and warns you when it is not one we recognise. We also send you an e-mail each time an app is connected. From then on, when you ask it to, the assistant can read your trips and the trips shared with you — including notes, booking and access codes, costs and the names of the people on a trip — and can add, change and delete what is in them, with your role on each trip: as owner or editor it can change and delete, as a viewer it can only read. A trip it deletes is deleted for everyone on it, exactly as if you had deleted it. Every change is made as you: the people you share a trip with see it, and are notified about it, as your change. The assistant can use your trips only while your account has Tourlet Pro (not while a payment has not gone through); anyone can connect. It cannot invite people, change who a trip is shared with or publish a trip.

What goes where. What the assistant reads is sent to the company that runs it (for example Anthropic for Claude, OpenAI for ChatGPT) and is handled under that company’s own terms and privacy policy: it is a service you chose to connect, not one working for us. Tourlet sends only what a request asks for — a trip, its days, bookings, costs or lists — never your other trips in the background, never the contents of your attachments (only their names), and never other people’s e-mail addresses. When you ask about a shared trip, what the other members wrote on it is sent too, as it is when the trip is shown to you.

What we keep. For each connection: your account, the name the app gave itself (for example “Claude”), the address it returns to (for example claude.ai), when it was made and last used, and keys that exist on our side only as a hash — an access key that lasts an hour and a renewal key replaced each time it is used. We count, per account and per day, how many requests a connected assistant made and how many changes it wrote. For each change a connected app writes, we note when it was made, which tool made it, the trip and its name, the name of what it changed (for example “Walk in Gion”, or a list’s name) and the day it is on, so that Connected apps can show you what that app changed recently; these notes are deleted with the connection and after 90 days. Apart from those notes, our server logs no trip content and nothing the assistant asked or received — only that a request was made, which tool, and whether it succeeded.

Read-only, and disconnecting. Settings → Connected apps, in the app and in the web app, lists every connection with its recent changes. A switch makes a connection read-only: the assistant can still read your trips but can no longer change them. Disconnect stops it at once and deletes its keys and its notes. You can also remove the connector in the assistant. A connection unused for 90 days expires by itself, and all of them are deleted with your account.

Play Integrity — Play build only

On a suggestion or a flight-status request, the Play build sends Google an attestation token (Play Integrity) alongside it, so our server can check that the request really comes from the genuine, Play-installed app rather than a script that has only stolen a session key. The token carries no trip content — only a hash of the request it is attached to, checked against Google’s own verdict on the app and the device. The F-Droid build and the web app cannot produce this token, so if this check is ever required rather than only logged, neither of them can use suggestions or flight status, and the app says so rather than failing silently.

Tourlet Pro

Free, on every build: creating, editing and reading trips, up to ten trips of your own, the map, place search with OpenStreetMap, and accepting a trip somebody else shared with you. Trips shared with your account do not count against the ten.

Pro (a subscription, monthly or yearly, with a seven-day trial): syncing a trip, inviting somebody to one, sending the plan to a paired watch, more than ten trips of your own, and, in the Play build, Google place search with Google’s photos of your stops.

In the Play build, Pro is bought through Google Play Billing. After a purchase, the app sends the purchase token to our server (POST /api/v1/purchase), which checks it — together with the address on your Tourlet account — against apps-management.gpm.name, the licence service every app in this family shares. That check, not the token itself, is what the app and the server go by; it is re-asked on every launch, so a lapsed or refunded subscription stops unlocking Pro on its own. A licence can also be granted to your address by hand (a tester, a translator, the author) — the same check covers that too.

The F-Droid build has no billing and no paywall at all: nothing in it can be Pro, and it does not link Google Play Billing.

The map and place search — what each build talks to

The Play build draws the map with Google Maps by default, and can be switched in Settings to the open map below. The map talks to Google directly from your phone: the area you are looking at goes straight to Google, never through our server.

Google place search and Google’s photos of your stops — Tourlet Pro, Play build, signed in — go through our server. When you type into a place field, our server (https://tourlet-app.gpm.name) asks Google Places (New) on your behalf with the service’s own key: it passes on the text you type (with a search-session token), the place you pick and which of its photos to show, and sends back Google’s answer. It stores none of it — not the text, not the place, not the photo — and only counts that a search was made (see “What we count about your account”). Google receives these requests from our server, not from your phone, so it does not see your IP address for them; the photo itself is then loaded by your phone straight from Google’s image server, which does see your IP address, the way any image on a web page does. Google is offered only in the Play build; the F-Droid build never links it.

Everyone else — the F-Droid build, the Play build without Pro or signed out, and the web app — searches places with Photon; the F-Droid build, the Play build if you switch, and the web app draw the map with OpenFreeMap. Neither is ours and neither needs a key:

• OpenFreeMap (tiles.openfreemap.org) draws the map tiles. What it receives, straight from your phone or browser: the area of the map you are currently looking at, and your IP address, the way any web request carries one. It never receives a place’s name, a trip’s name, or anything else about what you are planning. In the web app, the map code and the tiles are only loaded when you open the Map tab.
• Photon (photon.komoot.io), an OpenStreetMap geocoder run by komoot, answers place search as you type. What it receives: the text you type into a place field, and your IP address. It answers with a name and a coordinate; which place you pick, and what trip it goes into, is never sent back to it. The web app calls Photon directly from your browser.

Neither of these calls goes through https://tourlet-app.gpm.name: our server never sees the area you are viewing or the text you search for with them.

Neither the map nor place search sends your location: none of the services above — OpenFreeMap, Photon, or Google Maps/Places — is told where your device actually is, only what is on the map’s screen or typed into a search field. The position from the “my location” button (above) stays on your screen. The only thing in Tourlet that uploads your position is Recording your route, which is off by default.

Sending the plan to your watch — Play build, Pro

If you pair a Tourlet watch app, the Play build sends the next few days of your itinerary to it over Android’s Wearable Data Layer (Google Play services) whenever your trips change. This is Pro, the same as sync. It is phone-to-watch only — the watch never asks the phone for anything, and nothing about it goes through our server — and it is a courtesy: a phone with no watch paired, or no Play services at all, sends nothing and nothing on the phone notices. With the plan, Pro or not, goes one more thing: your two diagnostics answers (see “Diagnostics” below), so that the watch app follows what you chose on the phone.

Push notifications — Play build

The Play build registers the phone with Firebase Cloud Messaging, Google’s service for delivering notifications, once you are signed in. Our server stores that push token, one per device, and uses it to notify you when someone invites you to a trip or when a member changes a trip you share. Google delivers the message and so sees the token and that a message reached the phone. The token is deleted when you sign out and when the account is deleted. This is separate from the diagnostics switches below, and the F-Droid build has no push at all.

Notifications about a shared trip

When somebody else changes a trip you share, joins or leaves it, or a booking arrives at its forwarding address, Tourlet tells you, at most once every 10 minutes per trip, in up to three ways, each of which you can switch off in Settings (the app’s or the web app’s):

• On your phone, through Google’s Firebase Cloud Messaging (the play build only).
• In your browser, if you allow it in the web app: the browser’s own push service (Google’s, Mozilla’s or Apple’s, depending on the browser) carries an encrypted message that only your browser can read.
• By e-mail, to the address you signed in with, only if you have not seen the change on your phone or in the web app within 10 minutes, and at most one e-mail every 10 minutes per trip. Every e-mail has a one-click unsubscribe link (and the matching header, so your mail app can offer it); unsubscribing stops these e-mails and nothing else.

A phone or browser notification names the trip and the people who made the changes (their display names) and says how many things changed; it does not copy the contents of the change. The e-mail lists every change made to the trip, grouped by day, says who made each one when more than one person did, and shows what it was before and what it is now (dates, times, places, names). When a note, a cost, a booking code, a check-in time or an attachment changed, the e-mail says that it changed, for example “the price and the booking code changed” or “a note was edited”, but never copies its content. Tourlet keeps only a short fingerprint of those private fields, not their values, until the e-mail is sent. It never contains anybody’s address. To know whether you have seen a change, the server records when you last opened that trip in the app or the web app, and forgets it once nothing is waiting for you.

Checklist reminders — Tourlet Pro

A checklist can remind you of what is still to tick, for example a week before you leave. The reminder belongs to the checklist, so it is the same for everybody on the trip; the ready-made checklists come with one, and anybody who can edit the trip can change it or remove it.

• On your phone the app works out when each reminder is due and shows it itself, like its other reminders: nothing is sent for that.
• In your browser and by e-mail it is our server that works out when each reminder is due, from the trip it already stores for sync (the dates, times and places of the stops and journeys), and sends it to each member of the trip who has Pro and has not switched these reminders off. The browser notification names the checklist and the trip and says how many entries are left. The e-mail goes 30 minutes later, only if you have not opened the trip in the meantime and something is still unticked, and it copies the text of the entries still to tick (up to 15).

To do this the server keeps, for each checklist, the times its reminder is next due, and, for each person, whether a reminder was sent. You can switch these reminders off in the web app’s account page (Notifications) or in the app’s settings, or with the one-click link at the bottom of every reminder e-mail, which stops these e-mails and nothing else.

What the person running the service can see

Tourlet has an operator’s page, for Gabriele Proietti Mattia only, behind a secret token. It shows, for each account: the address, when it last made a request, how many trips it owns or belongs to, how much storage it uses, how many recorded points it holds, whether it is Pro and whether it is online right now; for the service as a whole, the number of accounts, trips, public links and connected apps and how much is stored. It also shows request statistics by route (how many requests, how long they took, how many failed), kept for 90 days, which are counts and not tied to a person. From that page the operator can create an account for an address (no mail is sent; the person signs in as usual), suspend one (its sessions are revoked and it cannot sign in until lifted, and nothing is deleted), or delete one, with exactly what “Delete account” does for you. The page never shows a trip’s contents — no names, notes, files or recorded route points — except for Explore: the operator sees every publication that has been reported, exactly as the public sees it, with the reports (reason, note, how many different reporters), and can keep, hide or remove it or ban its author, as described in “Explore”. The overview counts publications and open reports, never a title. Every one of those actions is logged as the action and the account number, not the address.

What we count about your account. To keep the service safe and its costs bounded, we count, per account and per day, how often certain things happen: how many times a limit was reached, how many trip suggestions, flight lookups, Google place searches and map routes were made, how many trips and invitations were created, how much data was synced or uploaded, how many forwarded mails were accepted, refused or read (and by which step), how many requests a connected assistant made and how many changes it wrote, how many publications and updates were made, and how many sign-in codes were sent to your address. These are counts only: they contain no trip, no name, no place and no message. They are kept for 90 days and are deleted with your account. They are seen only by the person who runs the service, to notice abuse and to keep costs in check. The network address your device connects from is never stored: the service keeps a short list of recent addresses in memory only, for at most 24 hours, to notice a script guessing sign-in codes or reading a public link, and it is lost whenever the service restarts.

Reporting a problem, and reading the answer

Tourlet’s Info tab has a report screen and a place to read what came back — the same screen every app in this family uses, and it talks directly to apps-management.gpm.name, not to Tourlet’s own backend.

A report carries: what you wrote, the app’s version, your Android version, your phone’s manufacturer and model, and your language tag — typed in by the app, not read from an identifier — and your email address only if you type one. Tourlet does not currently offer to attach a log or a screenshot to a report.

A report, and a feature request, also carry two things to keep abuse out:

• The IP address it was sent from. It is stored with the report, and only the person running the service sees it.
• A fingerprint of your device, made from its Android ID (Settings.Secure.ANDROID_ID), which the app reads without any permission. Android gives every app its own value, tied to the app’s signing key, so two apps by Gabriele Proietti Mattia see different ones, and a factory reset changes it. The service keeps only a keyed one-way hash of it, never the value itself, and never shows it to anyone.

Never the advertising id, and no install id of our own, in a report or anywhere else. The fingerprint is the only thing that identifies the device.

Keeping abuse out. A report or a feature request containing obscene words is not stored and not forwarded to anybody. Its sender is banned, without being told:

• by the device fingerprint, permanently;
• by the IP address, for 30 days;
• by the account or address, permanently, but only if you were signed in or had verified the address. An address you merely typed into the form is never banned.

The owner can lift any ban. If you think you were banned by mistake, write to apps@gpm.name.

Reading the answers is optional and needs its own proof: an address and a six-digit code, the same shape as signing in above but a separate account from Tourlet’s own. What it keeps is a key hanging from that address, scoped to Tourlet, stopping after a year unused, and withdrawn the moment you sign out. Sending a report itself needs none of this.

Diagnostics — Play build only, off until you answer

The F-Droid build has no diagnostics at all: it does not link Firebase, and nothing in it sends crash reports or statistics.

The Play build can send two kinds of diagnostics, both through Google’s Firebase, and both are off until you answer a question the app asks once, at the end of the first-run tour (or, for an install that predates the question, the first time you open the app after updating). The question shows two switches, both on, and says what each sends; nothing is collected before you press its button, and you can change either at any time in Settings → Diagnostics.

• Crash reports — if this is on and the app crashes, Firebase Crashlytics receives the stack trace, the device model, the Android version, the app version and an installation identifier Crashlytics generates. It does not include what you wrote or your trips.
• Usage statistics — if this is on, Firebase Analytics records which features are used, and, around the Tourlet Pro sheet, that it was opened and from where, which plan was picked, and whether a trial or a subscription then began: names of controls and plans, never an address or anything you typed. It goes together with the identifiers Analytics collects by default, which include the Android Advertising ID, an app instance identifier, the device model, the Android version and a coarse region.

The watch app follows the phone. The Tourlet watch app (Wear OS, from Google Play) links the same Crashlytics and Analytics and asks no question of its own: the phone passes your two answers to it with the plan, and on the watch both stay off until it has received them. With crash reports on, a crash on the watch sends the same report as above; with usage statistics on, Analytics records the watch app’s sessions with the same default identifiers, the Advertising ID included. Your trips are never part of either. A change you make on the phone reaches the watch the next time the two are connected.

Turning a switch off stops that collection from then on. Data already sent is held by Google under its own terms.

What stays on your device

• Every trip and everything planned for it, until you delete it or uninstall the app.
• The signed-in session and, if you used Google, your avatar picture — removed on sign-out.
• Pictures of the people on your trips, kept so their faces show offline.
• The photos of your footprints: in the F-Droid build they live only here; in the Play build a copy stays here too, next to the one in your Google Drive.
• The flights this phone watches, and the notifications it makes about them.
• The app’s settings.

If Android’s own backup is enabled on your device, this data may be included in your own device backup, under Google’s terms, the same as any app’s.

What the app never does

• No location upload beyond Recording your route above, which is off by default and switched on per trip. The “my location” button reads where the device is only when you tap it, and never sends it anywhere. With both unused, nothing reads where the device is.
• No advertising, and no sale or sharing of your trips or your address with anyone — except with an assistant you connect yourself (see “AI assistants”).
• No reading of your contacts, messages, call history or files.
• No fetching or showing anybody a trip you have not signed in and been invited to, or created yourself.
• Suggestions, flight status, attachments, route recording, lists, covers and the public link are covered in their own sections above; each is Tourlet Pro (to create or change), and suggestions, recording and the public link are each switched on by you — per request, or per trip — never by default. Explore, which is free, is the same: nothing is published unless you publish it.

Permissions, and why

No background-location permission, in either build. No storage or media permission either: a trip is the app’s own data.

Legal basis (GDPR)

For readers in the EU/EEA and the UK:

• Signing in — your consent (Art. 6(1)(a)), given by asking for a code or choosing Google, and withdrawable by signing out.
• Sync and sharing — necessary to provide the feature you turned on (Art. 6(1)(b)); nothing is sent until you sign in and turn it on, and a shared trip’s other members’ addresses are processed on the same basis, as part of the feature you and they both use.
• A Pro purchase — necessary to perform the contract you enter into by subscribing (Art. 6(1)(b)).
• Diagnostics (Play build) — your consent (Art. 6(1)(a)), given by the switches you leave on when you answer the first-run question, and withdrawable by turning them off in Settings.
• Profile picture, covers, attachments, lists, the public link — necessary to provide the feature you turned on (Art. 6(1)(b)); an Unsplash cover involves Unsplash’s servers as described above.
• Who is online, and editing locks — necessary to provide shared editing (Art. 6(1)(b)), and the operator’s page — the operator’s legitimate interest in running and securing the service (Art. 6(1)(f)).
• Google place search and photos (Play build, Pro) — necessary to provide the feature you subscribed to (Art. 6(1)(b)).
• Routes on the map (Pro) — necessary to provide the feature you subscribed to (Art. 6(1)(b)); the two ends of a line go to OpenRouteService (HeiGIT gGmbH, Germany) through our server, as described in “Routes on the map”.
• Bookings forwarded by e-mail (Pro) — necessary to provide the feature you turned on (Art. 6(1)(b)); the mails’ senders and any fellow travellers named in them are processed on the same basis, only as far as the trip shows. Notifications about a shared trip — necessary to tell you of a change you may have missed (Art. 6(1)(b)); each channel can be switched off, and an e-mail unsubscribed from in one click. Checklist reminders (Pro) — necessary to provide the feature you subscribed to (Art. 6(1)(b)); they can be switched off, and an e-mail unsubscribed from in one click.
• Following a trip live — for the traveller, necessary to provide the feature they turned on (Art. 6(1)(b)); for a follower, their consent (Art. 6(1)(a)), given by asking to be notified and, for e-mail, by confirming the address; withdrawn by leaving, at any time.
• Push notifications (Play build) — necessary to deliver the notifications you signed in to receive (Art. 6(1)(b)).
• Explore — publishing — necessary to provide the feature you asked for (Art. 6(1)(b)), which is showing your trip, under your public name, to anyone. The automatic check, the reports, the operator’s review and the limits per address — the operator’s legitimate interest in keeping the service free of abuse and unlawful content (Art. 6(1)(f)). Browsing, liking and copying — necessary to provide the feature (Art. 6(1)(b)); the hashed address kept for anonymous reports and copies is processed on the legitimate interest.
• AI assistant connector (Pro) — necessary to provide the feature you turned on (Art. 6(1)(b)); you start it by allowing the connection and stop it by disconnecting; other members’ contributions to a shared trip are processed on the same basis as sharing it.
• A report, and the address you attach to it — your consent, given by pressing send.
• The IP address and device fingerprint kept with a report or feature request, and the bans that follow an obscene one — the legitimate interest (Art. 6(1)(f)) in protecting the service and the people who run it.

Retention

A synced trip is kept for as long as your account holds it; deleting it in the app deletes it on the server too. An overwritten version is kept for seven days and then purged automatically. A pending invitation lapses after 30 days if nobody accepts it. A session key stops working when you sign out; there is currently no automatic expiry beyond that.

A profile picture is kept until you remove it or the account is deleted. A cover and a public link are kept until you remove them, or the trip or the account is deleted. A push token is deleted when you sign out and when the account is. Who is online is not kept: it exists while the connection is open. Request statistics on the operator’s page are kept for 90 days.

A publication is kept until you remove it or the account is deleted; its likes, and the reports against it, go with it. A removed publication’s record (status “removed”, shown to nobody) is kept until the account is deleted. A report’s hashed address is kept as long as the report is, and so are the IP address and the device fingerprint sent with it. A ban record stays until it expires (30 days for an IP address) or the owner lifts it. Your likes, the reports you made and the authors you hid are deleted with the account.

A forwarded mail is kept for at most 7 days and is never in a backup. An imported booking nobody adds or discards is deleted 30 days after its last update; the record of an added or discarded one is deleted 30 days after that. OpenRouter (zero data retention, no data collection) keeps nothing of a mail it reads for us.

A position-tracking point is kept until the trip, or the account, is deleted, or until you delete your own points on that trip yourself. A live link’s followers (names, languages, push subscriptions, confirmed e-mail addresses, Telegram chat ids, app tokens) and its last position are deleted seven days after the link stops working or is revoked; an unconfirmed e-mail address after 24 hours. An attachment is kept until it, or the trip, is deleted, and up to 14 more days in the nightly backup. A suggestion or a flight lookup is not stored at all beyond a flight status’s own brief cache (a few minutes to an hour) — only that a request was made counts toward its quota. A map route is kept, with no account or trip attached, for up to 180 days (a “no route” answer for 7 days) and then deleted. The city found for a point is kept, with no account or trip attached, for up to 180 days (7 days when there is no city there) and then deleted. A checklist reminder’s due times and the record of who was sent it are deleted at the latest 7 days after it was due, and the record also with the account.

A connection of an AI assistant and its keys are kept until you disconnect it, it goes unused for 90 days, or the account is deleted, and are erased within 30 days after; an unfinished connection request is deleted within a day. The notes of the changes a connected app made are deleted after 90 days, and at the latest with the connection.

Your rights, and asking for deletion

Under the GDPR you may request access to, correction of, or deletion of your personal data.

Settings → Account → Delete account closes your Tourlet sign-in — sync, sharing, purchases and all — in one step; see Delete your account for exactly what that takes with it and what it does not. Without the app, write to apps@gpm.name from an address on the account and say what you want deleted; expect it done within 30 days. Uninstalling the app removes everything kept only on your phone, but not a trip already synced to our server — delete the account, or the trip, before you do.

For a report sent through the Info tab, the same address gets it found, shown to you and deleted.

Children

Tourlet is not directed at children under 13 and knowingly collects no data from them.

Changes

Material changes will be published on this page with a new date at the top, and significant ones will be noted in the app’s changelog.

2026-10-04: added “Explore — publishing a trip for everyone”, and the matching lines under “What the person running the service can see”, “Legal basis” and “Retention”; added the exact alarms permission to “Permissions, and why”.

2026-10-08: added “Bookings forwarded by e-mail — Tourlet Pro” and “Notifications about a shared trip”, and the matching lines under “Legal basis” and “Retention”; “Signing in” and “Your profile picture”: your Google profile picture becomes your profile picture, seen by the people who share a trip with you; SVG pictures.

2026-10-10: “Notifications about a shared trip”: the e-mail lists what changed. Added “Following a trip live”.

2026-10-12: added “The trip video — made on your phone”.

2026-10-13: added “Footprints — a diary of the trip” (the photos go to your own Google Drive in the Play build and stay on the phone in the F-Droid build) and “Who is travelling — private trip data”. The public link and the live share say what they show of footprints and of who is travelling. The trip video says that music is never uploaded and that its close-up maps come from OpenFreeMap.

2026-10-20: added “AI assistants — letting an assistant work on your trips (Tourlet Pro)”: you can connect an assistant that supports connectors (MCP), such as Claude or ChatGPT, and it can read, add, change and delete what is in your trips, as you and with your role on each trip, only while you have Pro. Lists what we keep (the connection and hashed keys, daily counts) and that no trip content is logged; the matching lines are under “What the person running the service can see”, “What the app never does”, “Legal basis” and “Retention”.

2026-10-21: added “Checklist reminders — Tourlet Pro”: the browser notification and the e-mail are worked out and sent by our server, and the e-mail copies the text of the entries still to tick; the matching lines are under “Legal basis” and “Retention”.

2026-10-21: “Weather” now says how the city of a stop is found — our server asks Nominatim (OpenStreetMap) with the point rounded to about 100 m — with the matching line under “Retention”.

2026-10-29: “AI assistants” says that each change a connected app writes is noted — when, which tool, the trip and its name, the name of what changed and its day — so that Connected apps can show its recent changes, and that the notes are kept for 90 days; a connection can be made read-only; Connected apps is in Settings, in the app and in the web app. The matching line is under “Retention”.

2026-10-29: “Reporting a problem, and reading the answer” says that a report and a feature request keep the IP address they were sent from and a one-way fingerprint of the device’s Android ID, to keep abuse out, and that one with obscene words is not kept and bans its sender (“Keeping abuse out”). The matching lines are under “Legal basis” and “Retention”.

Last updated: 2026-10-29