Privacy Policy

There is no account and no sign-up. We cannot see who you are, and your coordinates are never published. If you turn sharing on, what we can see is which public markers you reached and on what day — that, and nothing about where you went in between.

The app needs your location to do the one thing it does — work out the direction and distance from you to a place. That calculation happens on your phone. The result is a compass heading. Your own coordinates are never attached to anything the app publishes — not while you are driving, and not in a finished record.

There is one place your position does leave the phone, and it is worth naming plainly rather than burying: the map. Holding the MAP key draws a map around where you are, and drawing a map means asking a map provider for the tiles at that spot. On iOS that provider is Apple, through MapKit. On Android it is Google, through the Maps SDK. It happens only while you hold the key, it is not something we store, and it is the only moment in the app where your position is sent anywhere.

Used on your device. Your coordinates are never published. The app reads your GPS position to compute the bearing and range to your destination, and to recognize when you have arrived. That is the entire purpose and the entire use.

Your coordinates are not logged to a server of ours, not attached to anything shared, and not retained by us in any form. Denying location permission will stop the game working, because a bearing from an unknown position is not a thing that exists.

On Android, two Google components are involved in location and we would rather name them than let you find them in a permissions screen. The position itself comes from Google Play services’ fused location provider, which is the standard way an Android app asks where it is. And holding the MAP key asks the Google Maps SDK for tiles around you, which necessarily tells Google where to draw. Both are governed by Google’s privacy policy. On iOS the equivalents are Apple’s, through Core Location and MapKit. Neither platform’s map is a tracker we added; it is what drawing a map costs, and it is why the Play data disclosure for this app lists precise location as shared.

Both stores’ privacy labels declare location, and that deserves an explanation rather than looking like a contradiction. A published record carries a broad region — but the region is worked out from the marker’s own public coordinate, not from where you were standing. A store label asks which data type is collected and not where it was derived from, so the honest answer on the label is coarse location, and the honest answer here is that the region names the place you went, never you.

Google Play’s disclosure additionally lists precise location as shared, and that one is not about the record at all. It is the map described above: the tiles are requested around where you are. We declare it because it is true, not because a published record contains a coordinate. It does not.

All of the following is kept on your phone. With sharing turned off, none of it goes anywhere at all — the map described above is the one thing that still talks to a map provider, and it sends the view you are looking at, never any of the items below. With sharing on, the only thing that ever leaves is the small record described in the next chapter — and that record is drawn from the first line below, so read that chapter too.

• Your drive and attempt history
• Which places you have found, and how you did
• Any photos you take in the app
• Your settings, including your home location

Delete the app and all of this goes with it. Records you already published are the one exception, and they are covered below.

The app has an optional shared layer that lets you see how other players have got on at a place — whether anyone has found it, whether it turned out to be a dud. The app asks you about it once, on first run, before it has published anything at all. Two answers, given equal weight on the screen: share your finds, or not this time. Neither is pre-selected and neither is styled to be the one you press.

Nothing is published before you have answered, and nothing is published ever if you answer no. You can change your mind either way, whenever you like, in the log — and records from drives you took while sharing was off are discarded, not held back and released later.

When it is on, a completed attempt publishes exactly this from us and nothing else:

• which marker it was
• how the attempt ended — found, arrived, not found, or reported as a dud
• if a dud, which kind
• a coarse efficiency figure and a count of hints used
• the day
• a broad region and cohort, used to group results
• which platform the record came from — the word “ios” or “android”

We put no name, no account of ours, no advertising identifier and no coordinate in that record. One further identifier is attached and it differs by platform — on iOS it is Apple’s account identifier, on Android it is a random visit ID we generate. Both are described under Where shared records go. An in-progress run is never published, because a run in flight is a person who is currently somewhere.

The one rotating identifier we put on it is the cohort, and it is worth being exact about what that is. Only a single feature needs identity at all — counting distinct drivers, so the map reads as populated rather than merely busy. So the cohort is a random value generated on your install and re-hashed every month. Within a month the driver count is honest. Across months, the records cannot be assembled into one person’s travel history, because the value they share has already changed. The residual, stated rather than waved away: inside a single month, someone with access to the store could group one install’s records and infer a rough area of operation. That is the price of the driver count, it is bounded to 31 days, and it is the only rotating identifier we put on the record. It is not the only one a shared record carries. On iOS, Apple attaches a per-app identifier for the account that wrote it, which is not ours to see. On Android there is no account to attach, so the record carries a random visit ID we generate — one per attempt, not one per person. Both are described below.

The cohort is what the App Store privacy label calls a Device ID and what Google Play’s disclosure calls Device or other IDs, declared on both as collected. We say so here because all three descriptions should agree, and because those labels sound heavier than what this is: a random number made on your install, not your phone’s serial, not an advertising ID, and not an account of any kind.

This is the one place where the two platforms are genuinely different, so both are set out rather than averaged into a sentence that is true of neither.

On iOS, the shared layer uses Apple CloudKit’s public database. We do not run that server; Apple does, and their handling is governed by Apple's privacy policy. As with any CloudKit public database, Apple associates a saved record with a per-app identifier for the account that wrote it. That identifier is not visible to us and is not your Apple ID.

On Android, the shared layer is a database we run ourselves, hosted on Supabase. There is no Apple account involved and nothing to attach one from, so the record carries a random visit ID we generate instead. The key that ships in the app holds no privilege on that table at all — it cannot read, write, change or delete a row directly. What it can do is call three database functions and nothing else: one that publishes a record, and two that return aggregate summaries of a place — how many attempts, how many finds, the best figures — which never hand back who wrote anything. Publishing again for the same visit amends that one visit’s record — it is how a verdict gets corrected — and that is the whole of what the app can change: it cannot touch anyone else’s record, and nothing it can call deletes anything. That is enforced by the database, not by the app being polite.

Two things worth knowing before you say yes. Switching sharing back off stops all future publishing but does not retract records already written. And records on the shared layer are readable by the app’s other users, which is the point of the feature. What version 1.0 does with that reading half differs by platform. On iOS the app reads the shared layer to show you how other players have got on at a place. On Android it reads the shared layer too, at one moment: when a find is published, to work out whether anyone had found that place before you — and it shows you that answer as a star on the entry in your log. What Android v1.0 does not have yet is the browsing surface, so the star is the only thing the shared layer tells you there.

We should be straight about what the no-retraction one means, because it is the one place where a privacy feature and a privacy right pull against each other. A record carries no name, and the one identifier we put on it that outlasts a single attempt — the month’s cohort code — is a random value with no link to a person, so we cannot look up “your” records. The other identifier does not give us a lookup either, on either platform: on iOS it is Apple’s and is not visible to us, and on Android it is a per-attempt random value that names no person and no install. That is not an oversight we are apologizing for; it is the same property that makes the record harmless in the first place, and we would have to collect more about you, not less, to be able to honour a lookup.

What we can do, and will: tell us the place and the day and we will delete every record matching that description. We cannot verify which of them was yours, and we are not going to ask you to prove it — deleting a few extra anonymous rows costs nobody anything.

• No accounts or sign-ups
• No advertising and no ad identifiers
• No third-party analytics or tracking SDKs in the app
• No third-party library in the Android build touches your data except Google’s location and maps SDKs, described under Location — and they are there to find you a bearing and draw a map
• No selling of data, ever, and no sharing with advertisers, data brokers or analytics companies — the transfer that does happen is to Google, for location and map tiles, described under Location, and it is why the Play data disclosure for this app declares data as shared
• No crash reporting that carries personal data

The app is not directed at children under 13, and it treats everyone the same way regardless of age: it asks for no name, no email, no account, and no personal details from anyone, ever.

The one identifier we put on a record is the rotating cohort described above — what the App Store label calls a Device ID and Google Play calls Device or other IDs, and replaced every month. If sharing is on, iOS also attaches Apple’s per-app identifier for the account that wrote the record; that one is Apple’s rather than ours, it does not rotate, and it is not visible to us. On Android the record instead carries a random per-attempt visit ID, which names no person and no install. If sharing is off nothing is published at all, so that identifier never arises. Nothing is collected from a child that is not equally collected from an adult, and nothing we hold is enough to identify either.

If the data practices above ever change, this page changes with them and the date below is updated. This policy covers Nowhere in Particular specifically; other Clapham Digital apps are covered by the general policy.

Questions, or a removal request: hello@claphamdigital.com.

Last updated: September 2026