Privacy
What the app sends, and what it never does
This policy is written from the code rather than from intentions — every claim below corresponds to something in the software, and the tests that ship with it fail if the two part company.
The short version
The tour works with no signal, so almost nothing needs to leave your phone. There are no accounts, no analytics, no advertising and no tracking of any kind — not a reduced amount, none. Where you walk, which language you chose and which clips you have seen stay on the device and are never transmitted.
Three things use the network from the app: the tour you download, the store receipt that proves you paid for it, and — only if you agree to it — a report when something breaks. The download and the receipt go to the venue's own server; payment itself is taken by Apple or Google, not by us. No third party hears from the app at all: no advertiser, no analytics service, and nothing that counts installations. A future release will add exactly one, once, at the moment you buy a paid tour — your phone will ask Google to vouch that it is a genuine device running the real app — and it is described below so the change is not sprung on anybody. No build you can install does this today, and the word “will” leaves this page on the day one does. Separately, this website carries the enquiry form venues use to contact us, and the portal holds invitations for venue staff — both are described further down.
What leaves the app
The tour you download
When you choose a tour, the app fetches its catalogue entry, its manifest and its media files. The request carries which tour you asked for and nothing about you: no name, no account, no identifier the app invented. Whoever runs that server sees the request information any web server does, including your IP address. Once the download finishes, the whole tour plays from your phone with the network off.
Who that server belongs to depends on where you are. Usually it is ours. At a site running the tour on its own machine on the premises, it is the venue's, and nothing from your phone leaves that building. It is the same address in both cases — the app has one — which is why this page does not claim otherwise.
A purchase: the receipt and the entitlement
A paid tour is bought through Apple's App Store or Google Play. The store takes the money and issues a receipt. The app presents that receipt to the same server the tour comes from; what we keep is an entitlement — a record that this store transaction bought this tour, when, and whether it is still good. It holds the store, the store's transaction id, the tour id and the purchase time. It holds no name, no email and no account: entitlement is keyed on the store transaction, which is why the app invents no identifier of its own to hang the purchase on. The record lasts twenty-eight days from the purchase — the same window the tour stays on your phone — and a refund from the store revokes it. Restore asks the store again, per platform; a Play receipt and an App Store receipt are two entitlements.
Proving the app is the real app — not in any released build yet
Nothing described in this section happens in any version of the app you can install today. It is written down in advance because it is the one time the app will ever speak to a third party, and a change like that should be on this page before it ships rather than after.
A paid tour's files are encrypted, and the key that opens them is issued once, at the moment you buy. When this ships, before issuing that key we will ask your phone to prove it is a genuine device running an unmodified copy of this app, using Play Integrity on Android. Your phone would obtain that proof from Google and hand it to the same server the tour comes from. It answers a one-time number our server made up seconds earlier, so an intercepted copy is worth nothing, and it is checked and thrown away rather than stored: no identifier for you or your phone reaches us, and nothing about the check is written down beside your purchase. A tour server that cannot make the check — a machine on a venue's own premises, with no way out to the internet — issues no keys and says so on the download screen.
Nothing checks in on launch
Apps of this kind commonly ask a service on every launch whether newer code exists, and that request usually carries an installation identifier — a value that follows one phone for as long as the app is on it. This app has that mechanism built in and switched off. Until it is switched on, and until this page says so, nothing is sent when you open the app.
Fault reports — off unless you say yes
If the app breaks, it can record what went wrong and send it — to the same server the tour came from, which is ours or the venue's exactly as above — the next time it has signal. We ask once, plainly, and the answer is no until you choose otherwise; you can change it at any time in the app's settings. A report contains the error, the technical trace, the app version and your operating system version. It contains no location, nothing about your walk, and no identifier for you or your phone. If you say no, anything already recorded is deleted rather than held.
Location
The app reads your position to know when you have reached a stop and to draw you on the map. That reading is used on the device and never leaves it — it is in no request the app makes. It continues while your screen is locked so the walk still works in your pocket, which is what the location notice on your phone refers to.
Tags and the camera
Tapping an NFC plaque is read by your phone's radio and resolved against the tour already on the device; no request is made. The camera, where a tour uses it, renders on the device only — no image is uploaded.
This website
The pages carry their own fonts, images and one script — no content delivery network, no third-party fonts, no analytics, and no cookies set by us. Our host, Cloudflare, sees the ordinary request information any web server does, including your IP address.
The enquiry form is the one page that involves anybody else. What you type — your name, your organisation, your email address and your message — is sent to us by email through Resend, and the form is protected from automated abuse by Google reCAPTCHA Enterprise, which is loaded on that page only and which collects browser and interaction information under Google's own privacy terms. We store nothing from the form beyond the resulting email in our inbox, and the message content is never written to our logs.
The portal — invitations and credentials
The portal at portal.hindsite.mobi is for the people who run a venue's tour, not for visitors. There is no public sign-up: membership arrives by invitation only.
An invitation
An owner names an email address and a role. We store that address, the destination, the role, who invited them, and a hash of the one-use token mailed to that address — never the token itself. The token is good for seven days and five wrong guesses; after either limit a new invitation is needed. Until the invitation is accepted the address is held so the mail has somewhere to go; on acceptance we record the subject who accepted and stop treating the invitation as outstanding. Whoever administers the deployment can read an invitation, which is why the token is hashed.
A credential
A password is set when accepting an invitation, never on a public page. What we store is a credential: an identifier (typically the invited address), a one-way hash of the password, and — when a reset is in flight — a hash of the reset token with the same seven-day life and five-guess limit. The password itself is never stored; the hash is Argon2id, chosen so a stolen store is slow to guess against. The same people who administer the deployment can read a credential record, which is why only digests sit there. Google sign-in stays the other door; founder and administrator accounts are established from configuration rather than by invitation.
Children, retention and your rights
The app is not directed at children and collects nothing that would identify one. Because it holds no accounts for visitors, we have no visitor profile to keep. What we do hold about a purchase is the entitlement keyed on the store transaction, for twenty-eight days or until a refund; a fault report you agreed to send, kept while it is useful for fixing the fault and then discarded; and, for venue staff only, the invitation and credential records described above.
You can withdraw consent for fault reports at any time in the app's settings, and remove everything the app holds by deleting it from your phone. To ask what we hold or to have an entitlement or other record removed, write to [email protected] and a person answers.
Hindsite is operated by Vitruvian AI. Questions about this policy go to the same address.