// LEGAL · PRIVACYPrivacy Policy

Effective

6 June 2026

Updated

4 November 2026 (US Eastern time)

Controller

Minhaj Khan

Contact

minhaj@safe-route.app

01Who we are

SafeRoute is a crime-aware walking navigation app for the United Kingdom, 26 US cities, two Canadian cities (Toronto and Vancouver), and Mexico City. It also publishes a website, safe-route.app, with neighbourhood safety pages and a map for checking any address. The data controller is Minhaj Khan (an individual based in the State of New York, United States), referred to throughout this policy as "we," "us," or "SafeRoute."

Contact: minhaj@safe-route.app

This policy explains what personal information SafeRoute collects, why we collect it, how we use it, and the rights you have under the UK General Data Protection Regulation (UK GDPR) and the UK Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025.

02Scope

This policy applies to the SafeRoute iOS app, the optional SafeRoute Apple Watch companion, the SafeRoute website at safe-route.app (including its address-check map and neighbourhood safety pages), this policy page, and the SafeRoute backend service that supports them, including the page it shows to anyone who opens a link to a walk you share (section 03). It does not cover third-party services that the app or the website links out to (for example, the App Store, the police and open-data portals we credit, the OpenStreetMap or Open Government Licence pages, the Department for Education's school-information service, or, from version 1.4, the websites of the school and home-value publishers, and of their licences, that the app's Schools and Home values layers, its About screen and, in version 1.4, its home-values card link to), which have their own privacy policies.

03Information we collect

SafeRoute is designed to collect as little personal information as possible. We do not require accounts, sign-in, or registration. We do not ask for your name, postal address, phone number, or payment information; if you type an address into a search box, it is handled as described below, and if you share a walk, so is the name or address of its destination.

We process the following limited categories of data while you use the app or the website:

Location data (GPS coordinates)

When you actively use SafeRoute to plan or follow a route, the app reads your device's GPS location. Coordinates are sent to our backend to compute walking routes, to retrieve crime context for your area, to work out how much of each route we find runs along lit streets (from version 1.2.1, the app sends the routes back to our backend for this; section 05, and "Places that can help, and street lighting" below) and, if you use Share my walk, to show your walk to the people you send the link to (see "Share my walk" below). When you navigate, the app also sends your route, and in some cases your position, straight to Mapbox. To name the area you are in, the app also sends your location to Apple's map services. Both are described under "The app's map" below. From version 1.4.2, the large Home Screen widget also sends Mapbox, for a picture of its map, a point a fixed distance east of the centre of the area it shows, both rounded to about 100 m (see "Home Screen widget" and "The app's map" below). Coordinates are not stored against any persistent identifier on our servers; if you share a walk, its route and positions are held for a few hours under a random code, not under any identifier of yours. When the app checks your area, looks for help nearby, or ranks search results near you, your device's current location travels in the address of the request, and our request log keeps it only to about 1 km (see "Technical request data" below). Our cache of crime data keeps the box around the point of an area check, and around a route you plan, to about 10 m for up to a day, and can hold it in memory for about an hour more, or longer in Dallas (section 08).

Four features can send your location to our backend without you opening the app; since version 1.3.8, released on 1 October 2026, Area heads-up no longer does:

• Home Screen widget: if you add the SafeRoute widget to your Home Screen or Lock Screen, it asks our backend for an update about every 30 minutes (iOS decides exactly when), sending the last location the app recorded, if that is less than a day old. Since version 1.3.8, released on 1 October 2026, the widget first rounds that location to about 100 m. It then sends nothing to our backend, but shows its last answer again, while the rounded point is within about 100 m of the one that answer was for, that answer gave a risk level (not, for example, "No data here") and is less than 6 hours old, and the app has not checked an area since. Earlier versions send the location unrounded at every update. From version 1.4.2, the large widget also asks Mapbox for a picture of the map of the area it shows (see "The app's map" below); earlier versions ask Apple.
• Area heads-up: if you turn on these alerts and let SafeRoute use your location Always, iOS watches a few nearby high-incident zones for the app and notices when you have moved some distance. The watching itself sends nothing to our backend, and since version 1.3.8, released on 1 October 2026, the app checks your area for these alerts only when you open it. In earlier versions, iOS can relaunch the app in the background to update the zones, and when it does, the app also checks your area as if you had opened it, which sends your current location to our backend. The alerts do not need this, and version 1.3.8 no longer does it.
• Fresh incident nearby: if you turn this on (in About, or on the Tonight card in cities that offer it), the app sends its latest known position when iOS wakes it in the background (at most about every 30 minutes), when you open or return to the app, and when you switch the setting on, to check for serious incidents nearby. Since version 1.3.8, released on 1 October 2026, the app rounds that position to about 1 km before sending it; earlier versions send it to about 1 m. Our server cuts it to about 1 km as it arrives and uses it only to find your city's recent calls.
• Find Help on Apple Watch: when you open Find Help on the watch, the iPhone app looks for places near you, even while SafeRoute is not open on your iPhone, and, unless it already looked near the same spot in the last 5 minutes, sends our backend a location to do so. From version 1.4, that is your current location: a position from the last minute or, if you have already allowed SafeRoute to use your location, a new one; if it gets neither, it sends nothing. Earlier versions send the last position recorded during a navigation since SafeRoute last started, which may be far from where you are now, and send nothing if there is none. From version 1.4, if you then choose Go on a place while SafeRoute is not open on your iPhone, the iPhone app also sends your current location to our backend straight away to plan the walk to that place and, if you are sharing a walk, points the link at that place (see "Share my walk" below). If it finds a route, the walk itself starts when you next open SafeRoute, if you do so within about 10 minutes.

As with any other request, our request log keeps these locations only to about 1 km. You can stop them by removing the widget or by turning the alerts off in About; Find Help on Apple Watch sends nothing unless you open it.

Share my walk

This part is written for the person who shares a walk. If you opened a link to someone's walk, the last paragraph of this part says what your browser sends and to whom; section 05 gives our lawful basis, section 08 says how long we keep what it sends, and section 09 sets out your rights.

If you tap Share my walk on a route and then Create link & send, the app sends our backend the name of your destination (a place name or an address), the route you planned and your estimated walking time, and our backend makes a link to a page that shows them. The route is its full line of coordinates: it starts where you planned it from, which is often your current location, and passes through any stops you added. Nothing is sent until you tap Create link & send.

If you choose Live location, which is selected unless you change it, the app also sends your precise position, with the time, about every 15 seconds while you navigate, including while your screen is locked. If a send fails, the app tries again with the next position, up to about once a second. In versions before 1.4, if our backend no longer has the walk, for example after it restarts, every later attempt fails, whenever you navigate, until sharing stops in one of the ways below, and our backend rejects those positions without keeping them. From version 1.4, the app stops sending positions as soon as our backend answers that it no longer has the walk, or that sharing has already stopped, and, if you are navigating, tells you "Sharing ended — your link is no longer active. Share again to keep going." From 4 hours after the link was made until we delete the walk (section 08), our backend still acknowledges each position the app sends, but does not keep it, so the last position the page can show is the last one sent before the 4 hours were up; from version 1.4, the app stops sending them at 4 hours (see below). If you choose Route only, the app sends no position.

From version 1.4, sharing stops when the app detects that you have reached the destination of the navigation you are on (the last one, not a stop along the way), when you end navigation (other than by choosing Go in Find Help; see below), when you share another walk, when the link is 4 hours old, or when you tap Stop sharing on Apple Watch, which appears among the watch's safety options whenever you are sharing. In versions before 1.4, reaching your destination does not by itself stop sharing: it stops when you end navigation (including from the screen navigation shows when you arrive), when you share another walk, or when you tap Stop sharing on Apple Watch, which appears only while you navigate. With Live location, if you start navigating, even to somewhere else, before sharing has stopped and while SafeRoute has kept running since you made the link, your positions from that navigation are sent to it too. From version 1.4, with Live location or Route only, if that navigation reaches its destination, the app also tells our backend that you arrived, and the page says "Arrived" under the destination you shared, even if that navigation went somewhere else.

Arrival, from version 1.4. When the app detects that you have reached the destination of the navigation you are on, it stops sending positions and tells our backend that you arrived. The page then says "Arrived" and "Reached the destination", with how long ago. The app knows only that your phone reached the destination, and the page says nothing more than that. The app then shows a check-in screen, which offers a ready-made message saying that you arrived safely; the ready-made message names your destination when the app knows it. You send it yourself, if you want to, with whichever app you pick from iOS's share sheet, and we are not told whether you send it or to whom. If the app cannot reach our backend, it tries once more a few seconds later and then, until our backend has it, each time you bring SafeRoute back to the foreground, for up to about 5 hours after you arrived; until then the page goes on showing the walk as it last was, and once the arrival gets through, the page gives the time it got through, not the time you arrived. To send it again, the app keeps the link's code and its secret, and the time you arrived, on your phone (section 08). An arrival that reaches our backend more than 4 hours after the link was made is not recorded: the page goes on saying that the link is closing. Versions before 1.4 never tell our backend that you arrived (section 13).

The 4-hour limit, from version 1.4. 4 hours after you made the link, with Live location or Route only, the app stops sharing the walk: it sends no more positions, and nothing else about the walk, to our backend. If you are navigating, it tells you so in navigation, on its Live Activity and on Apple Watch: "Sharing ended — links last about 4 hours. Share again to keep going." The page says that the link is closing until we delete the walk, about 15 minutes later (section 08).

Find Help, from version 1.4. If you choose Go on a place in Find Help, on your phone or on Apple Watch, while you share a walk, sharing continues and the same link is pointed at that place; before you choose, Find Help says "Your contact will see you're heading here." The app ends navigation, finds a walking route from where you are to the place, as for any route you plan (see "Location data" above), and, if it finds one, starts navigating it straight away. If SafeRoute is not on screen, for example when you choose Go on your watch with your phone in your pocket, that walk starts when you next bring SafeRoute to the foreground, if you do so within about 10 minutes of the route being found. If the walk does not start, the route waits in the app for you to start it, and the link goes on saying that you are heading to that place until sharing stops in one of the ways above or the link expires (section 08). Until the walk to the place starts, the app sends no positions, so with Live location the page shows the last position it was sent before you chose Go. Our backend receives the place's name and location and, with Live location, once the walk to it starts, the new route, which starts where you are, and its estimated walking time. With Route only, the app sends, and our backend keeps, only the place's name and location, and the page stops showing your original route. The page then says that you are "Heading to" that place "(chosen in Find Help)" and marks it on the map, with Live location also the new route and, as you walk, your positions again. Because Find Help lists places near you, the place shows roughly where you are, even with Route only. Whether you are later than expected is then judged, with Live location, against the new walk's estimated time once that walk starts and, with Route only, against the original walk's. Pointing the link at a new place does not make it last longer (section 08), and sharing then stops in the ways above, for example when you arrive at the place. If the app cannot update the link, it says "Couldn't update your shared walk", with Try again and Stop sharing, and, until the walk to that place starts, your watch says so too; until the link is updated, the page goes on showing the walk as it last was. Without a shared walk, Go works in the same way, without the link.

In versions before 1.4, there is one exception to ending navigation: if you choose Go on a place in Find Help, on your phone or on Apple Watch, navigation ends but sharing does not. The link stays open, and the page keeps saying that you are walking and, later, that you are later than expected; Stop sharing disappears from your watch; and with Live location, your next navigation, for example to that place, sends its positions to the same link. Sharing then stops only when you end a later navigation in the usual way, tap Stop sharing on your watch during one, or share another walk; otherwise the link stays open until about 4 hours 15 minutes after it was made (section 08).

You send the link yourself, with whichever app you pick from iOS's share sheet, and that app handles the message under its own terms; the ready-made message names your destination. The link works as soon as it is made, even if you then close the share sheet without sending it, and we are not told who receives it.

The link holds a random 12-character code, not your name or phone number, but anyone who has it, including anyone it is passed on to, can open the page without a key (section 11). They see your destination, your planned route with its start and end marked, and whether you are still walking or are later than expected, or, from version 1.4, that you arrived, or that sharing has ended (the page then says "Sharing ended" and "The walker ended navigation or stopped sharing"), or, once the link is 4 hours old, that the link is closing and, with Live location, how long ago it last updated. In versions before 1.4, when our backend is told that sharing has stopped, even at your destination, the page says that sharing ended, not that you arrived: it can say that you arrived only if the app tells our backend so, which those versions never do (section 13). From version 1.4, it says that you arrived once the app has told our backend so, and, after you choose Go in Find Help, that you are heading to that place (see above). The page, or the data behind it, also gives your estimated walking time and when the link was made and last updated. With Live location they also see your latest position, and the data behind the page holds the positions our backend has kept for that link, each with its time, up to the last 200 (at least about 50 minutes of walking). Send the link only to people you want to see this.

We hold a shared walk in our backend's memory only and never write it to disk. We delete it about 30 minutes after sharing stops, and never later than about 4 hours 15 minutes after the link was made (section 08). Every shared walk is also lost if our server restarts. Until then the page keeps showing the route and, with Live location, your last position. The ways of stopping above work only while SafeRoute has kept running since you made the link: if it has been closed or restarted, or cannot reach our backend when sharing stops, the link receives no more positions but stays open until it expires; from version 1.4, an arrival the app has detected is the exception: if it does not get through, the app sends it again later, even if SafeRoute has been closed in the meantime (see "Arrival, from version 1.4" above). A link you make without then starting navigation can be stopped only by starting and ending navigation or by sharing another walk, or, from version 1.4, by tapping Stop sharing on Apple Watch. Deleting the app does not end a walk you have shared.

The page asks our backend for updates about every 5 seconds for the first 4 hours, until sharing stops, and every 30 seconds after that, and each request reaches our backend, through Cloudflare, with the viewer's IP address (section 06); our request log replaces the code in these links with a placeholder (see "Technical request data" below). The page draws its map from images that the viewer's browser downloads straight from Mapbox, so Mapbox receives the viewer's IP address and browser details and the area of map around your route (from version 1.4, after you choose Go in Find Help, the area around the place you chose, which is near you, any new route and, with Live location, your latest position), and any other area the viewer moves the map to; your route, your destination, your positions and the link's code are never sent to Mapbox. Since 17 October 2026 the page runs no code from Mapbox, stores nothing for Mapbox in the viewer's browser and sends Mapbox no usage events; until then, Mapbox's map library, which the page loaded, sent Mapbox usage events with a random identifier that it kept in that browser (sections 06 and 13). Since 30 September 2026 the page links to this section. Our usage analytics (below) record only that a walk was shared and whether you chose Live location, and nothing about it once you have turned them off.

Search queries

Text you type into the place-search box (for example, a destination name) is sent to our backend, which forwards it to Mapbox's geocoding service to turn it into a map location. If you have allowed location access, the app also sends your current location with each search so that nearby places rank first, and our backend passes it to Mapbox for the same purpose. We do not link your searches to you: we keep no account or identifier for you that they could be linked to. The App Store's privacy label nonetheless lists search history, like the other data the app collects, as “linked to you”, because Apple counts as linked anything that is personal data under privacy law, and a place you search for can be a precise location, which we treat as personal information (see also section 04). The text and any location travel in the address of each request, but our request log keeps only the length of the text and the location cut to about 1 km (see "Technical request data" below).

Places that can help, and street lighting

The places that Find Help, on your phone or on Apple Watch, and the Nearby tab list, and the street-lighting figures on route results, come from OpenStreetMap data. For places, the app sends our backend the point to look from (see "Location data" above); for street lighting, the candidate routes (section 05). Until the server update that switches on our own copy of this data (section 13), our server asks Overpass servers for it everywhere (section 06): for places, the fixed map squares, about 2 km across, around the point looked up; for street lighting, a box around the candidate routes, widened by about 300 m.

From that update, our server keeps its own copy of the OpenStreetMap data these features need, and answers from it as follows:

• Inside our covered regions, our server answers only from its copy, and sends no map square and no route box to any Overpass server, overpass.ch included, except in the cases under “When lookups in our covered regions can still go to the Overpass servers” below. Our covered regions are Great Britain, Northern Ireland, the Isle of Man and the Channel Islands, with their coastal waters (the outline the app uses for the UK; unlike the area of our UK crime data, which is England, Wales and Northern Ireland, it includes Scotland, the Isle of Man and the Channel Islands), and, around each city we cover in the United States, Canada and Mexico (section 06 names them), the rectangle our server uses to choose that city's crime data, which can take in parts of neighbouring towns (the rectangles are listed in config/regions.json in our copy's repository); to be exact, every fixed map square, about 2 km across, that touches one of these areas. A route whose box touches them is not sent either: if our copy does not hold street-lighting data for the whole box, the route results show no street-lighting figures.
• While our copy cannot be used (for example, if it could not be loaded, or its data is more than 30 days old), our server still sends nothing from inside our covered regions to any Overpass server, except in the cases under “When lookups in our covered regions can still go to the Overpass servers” below. A lookup there that needs a square our copy cannot answer fails, as a lookup does now when the Overpass servers cannot answer. From version 1.4, Find Help then says that it could not load places (on your iPhone, it also points you to the emergency number and offers Try again), and so does the Nearby tab if it has no places for that area yet; earlier versions say instead that they found no 24-hour places nearby, or can show places they looked up earlier for somewhere else, so there can be places nearby that they do not show. Route results show no street-lighting figures.
• Outside our covered regions, our server also answers from its copy where the copy holds the data: for places, almost all of the 26 US states and the District of Columbia, Ontario, the South Coast region of British Columbia, Mexico and the Republic of Ireland that the copy is built from (except some squares at their edges); for street lighting, the Republic of Ireland and about 5 km, or a little more, around each city's rectangle. Elsewhere, and while our copy cannot be used, it asks the Overpass servers as before (section 06). A Find Help or Nearby tab lookup made inside a covered region, near its edge, can also need a square just outside it that our copy does not hold, such as open sea; that square goes to the Overpass servers, though the squares inside the region do not.
• What the copy holds: map data only: hospitals, police stations, pharmacies and 24-hour shops, with the details of them that we show or use, such as their names, addresses, phone numbers and opening hours, and the streets that OpenStreetMap marks as lit or unlit. It holds nothing about you or your lookups, and nothing is added to it when you use the app. We build it each week on GitHub, from OpenStreetMap extracts published by Geofabrik, in Germany, and publish it there under the Open Database License, with the scripts that build it (github.com/minhajk21/saferoute-osm-data). Our server downloads it from GitHub when our server is updated or restarts, again if that download fails, or to replace a damaged copy, never for a lookup, so neither Geofabrik nor GitHub receives anything about you or your lookups.
• How up to date it is: the copy is usually between about 1 and 8 days old. If a weekly update fails, it can be older, and our server stops using it once its data is more than 30 days old. So a place's 24-hour opening details, or whether it is there at all, can be about a week out of date, or more if a weekly update fails.
• What our server keeps: for a lookup our copy answers, the point or the routes are used in memory for that lookup only, and our request log keeps the point only to about 1 km, as for any request (see "Technical request data" below). Our server reads its copy from its own disk, and holds what it has read for each map square in memory for up to 1 hour, keyed by square, not by you, and deletes it by then (section 08).
• When lookups in our covered regions can still go to the Overpass servers: our server can be set, or taken back to a version from before the update, so that lookups in our covered regions go to the Overpass servers again, as they do before the update, either always or whenever our copy cannot answer them; and if our server cannot read its own list of the squares in our covered regions, lookups there that our copy cannot answer go to the Overpass servers too. We will set our server, or take it back, in this way only if our copy turns out to be faulty. If, after the update, our server asks the Overpass servers for a map square or route box inside our covered regions, for any reason, we will add to section 13 the dates on which it did.

The app's map

The maps in the app — on the Nearby tab, including its full-screen crime map, on the Live and Plan tabs, and in turn-by-turn navigation — are drawn by Mapbox's software inside the app, which downloads map data directly from Mapbox (api.mapbox.com): the map's style, fonts, icons and map tiles and, while you navigate, terrain, 3D buildings and routing data for the area around you. So Mapbox receives your device's IP address, the app's name, version and build number, the versions of Mapbox's software, your iOS version and device model, and the areas of map you view, which, while you navigate, are the area around you. These requests also carry a billing token from Mapbox's software, part of which stays the same for as long as the app is installed. Searching for places, and finding the routes you compare before you start, do not go from your device to Mapbox: the app sends them to our backend (see "Search queries" above and section 06); only once you navigate does the app ask Mapbox for directions itself, as described below.

Each time a map or a navigation session starts, Mapbox's software also sends Mapbox a usage check-in (to events.mapbox.com), which Mapbox uses for billing, and from time to time it asks Mapbox for its settings (from config.mapbox.com). Both carry the identifier iOS assigns to SafeRoute on your device (Apple's "identifier for vendor"), unhashed, which stays the same until you delete the app; the analytics identifier described below is derived from it. The check-in also gives your device model, iOS version and the app's name and version, whether Location Services is on, and the location access you gave SafeRoute (While Using or Always, and precise or approximate).

When you start navigation, the app sends Mapbox the route you chose — up to 100 points along it, from its start, which is usually where you are, to your destination — with the names of the start and the destination (when you start from where you are, the start is named "Current Location"), your language and your units of distance, so that Mapbox can turn it into turn-by-turn directions. As you walk, the app fetches each spoken instruction from Mapbox by sending its text, which names the streets ahead, with your language. On that route, the app sends Mapbox no position while you walk, even if you leave the route. If Mapbox cannot use the route you chose, the app instead asks Mapbox for a walking route between your start, any stops and your destination, with their names; while you follow that route, it sends Mapbox your current position, at full precision, and your direction of travel whenever you leave the route, to get a new one, and your current position and direction of travel from time to time, to look for a better one. Versions before 1.2.1 always navigate this second way.

Every version of SafeRoute from 1.0.2 (June 2026) and before 1.4 switches off Mapbox's own usage telemetry each time it starts. From version 1.4, it is your choice: it is off when you first install the app, you can turn it on or off with the switch at About → Mapbox map data or in a map's ⓘ menu (below), which are the same setting, and SafeRoute no longer switches it off each time it starts, so it stays as you last set it. If you update from an earlier version, version 1.4 switches it off once, the first time it starts; from then on it stays as you set it. With it off, the Report button that Mapbox's software shows during navigation, and the "Rate your trip" screen it shows when you arrive, send nothing to Mapbox; we checked this with version 1.3.8. From version 1.4, the app does not show that button or that screen at all. Versions 1.0.0 and 1.0.1, from May 2026, do not switch it off, so with them Mapbox's software sends what the list below describes unless you switch it off as described there.

The ⓘ button on each map opens a menu from Mapbox. Its Improve this map item opens Mapbox's map-feedback page in your browser at the place the map shows; the page's address gives that place to about 1 m, and says that you came from SafeRoute. Its Mapbox Telemetry item asks whether you want to take part in Mapbox's telemetry, which Mapbox's dialog describes as "contributing anonymous usage data". It is not anonymous: it carries the identifier described above. If you choose Participate, or, from version 1.4, turn on About → Mapbox map data, Mapbox's software sends Mapbox the following: in versions from 1.0.2 and before 1.4, until SafeRoute next starts, when the app switches it off again; from version 1.4, and in versions 1.0.0 and 1.0.1, until you switch it off:

• your precise location each time the app receives it (about once a second while you navigate), with your speed, direction of travel, altitude and the location's accuracy, whether the app is open or in the background, and the location access you gave SafeRoute; only approximate locations if you gave SafeRoute approximate access;
• events when a map opens, with the identifier described above, your device model, iOS version, screen scale, text-size setting and orientation, and whether you are on Wi-Fi; and counts of how the app uses Mapbox's map software;
• events when you start, finish or cancel navigation, with your route, your last 20 positions, and your device's battery, volume, screen brightness, audio output and type of connection;
• in versions before 1.4, which show them, anything you send with the Report button or the "Rate your trip" screen: the category you chose or your rating, any comment, word for word, your last 20 positions, your route, and a screenshot of the navigation screen, which shows the map around you and your comment.

You can stop it at any time by choosing Stop Participating in the same menu or, from version 1.4, by turning off About → Mapbox map data.

From version 1.4.2, the map in the large Home Screen widget is a picture that Mapbox draws for the widget with its Static Images API, in the same map style as the app's maps; Mapbox's software in the app is not involved. When the widget refreshes and has no picture of the same map from the last 12 hours, it asks Mapbox (api.mapbox.com) for a light and a dark picture, sending the centre of the picture, rounded to about 100 m, which is a point a fixed distance east of the centre of the area it shows (that centre is rounded to about 100 m too: it is the point the widget sends our backend), so that the area sits toward the left of the picture (the shift is only for the widget's layout: Mapbox can work out the area's centre from the point sent); the zoom; the position, outline and shade of each crime cell drawn on the map; and the app's Mapbox access token, which is the same for every install. Mapbox receives these with your device's IP address, the widget's name and build number, the versions of iOS's network software, which show your iOS version, and your language setting. They carry no billing token and no identifier of your device, the widget sends Mapbox no usage check-in, and About → Mapbox map data does not change what it sends. The widget reuses each picture for up to 12 hours and keeps the latest two on your iPhone (section 08). Only the large widget shows a map; the other sizes, on the Home Screen and the Lock Screen, ask for none.

A few things in the app use Apple's own map services (Apple Maps), which iOS provides, rather than Mapbox. To show the name of your area on the Nearby tab, the app asks Apple to turn your current location into a place name. When an alert fires, it asks Apple for the name of the street and area at the alert's point and for a small picture of the map around that point; in versions before 1.4.2, the widget also asks Apple for a picture of the map of the area it shows. So Apple receives those locations and areas of map from your device, with its IP address.

Schools and home values in the app

School and home-value data is built into the app (from version 1.4). The Schools and Home values layers of the Nearby tab's full-screen map, the School data and Home values data sections in About and, in version 1.4, the home-value figures under an area's report all come from that data, and showing them sends nothing to us or to anyone else. Turning either layer on or off, filtering schools, using the Schools in view list, or opening a school or an area sends nothing either, except, if Usage analytics is on, the usage signal for that action, which says what kind of thing you did, never which school or area (see "Usage analytics" below). Moving the map works as it does without these layers: the map itself loads from Mapbox (see "The app's map" above), and while the crime shading is shown, with or without Schools, the app asks our backend for the crime data of the area you move to. While Home values is shown instead, the app does not ask our backend for crime data as you move the map; when you switch back to the crime shading, it asks for the area in view if you have moved the map away from the area it last looked up. In version 1.4, the home-value figures under an area's report are for the area the app has already looked up, and finding them sends nothing more. From version 1.4.1, the Nearby tab shows no home-value figures: its map of the area it has looked up has a Schools button, a Home values button or both, each where that layer has data, which open the full-screen map on that layer, and Home values also opens the details of the area at that same point, or says why it has no figure. The app finds that area in its built-in data, so this sends nothing more, other than the usage signal for switching the layer on described below; opening the area this way records nothing. Links marked ↗ open in your browser, which, as for any website, sends that website your IP address and browser details. A link to a school's own record or inspection report (for example the Department for Education's record in England, the NCES record in the US, the Ontario School Finder page, SEP's school finder in Mexico City, or the inspection report in Northern Ireland) puts the school's official ID, or its report's, in the address, so that publisher sees which school you opened. The other links, to a source, a rating's publisher or a licence, and every link in the home-value layer, in About and, in version 1.4, on the home-values card, open general pages and do not say which school or area you were looking at. The app keeps on your iPhone whether you have turned the Schools layer on (section 08).

Apple Watch

The SafeRoute Apple Watch companion reads no motion, health or other sensor data. While you navigate, your iPhone checks whether you have left the route you chose, by comparing the position it already uses for navigation with that route, and tells you so on your iPhone and on Apple Watch. This check runs on your iPhone and sends nothing to our servers.

Technical request data

For security and abuse prevention, our backend writes one line to its log for every request: the time, the address requested, the response code, the size of the response and how long it took to answer. Before the line is written, any search text in the address is replaced by its length, and any coordinates are cut to two decimal places (about 1 km); the code in a link to a shared walk is replaced by a placeholder, and the rest of the address is kept, such as a camera identifier. That line does not include your IP address. Our host, Render, keeps these logs for about 7 days, and they are not used to build a user profile. Separately, to enforce rate limits, our server counts requests in memory for one to two minutes, keyed on the IP address each request arrives from (see section 08).

Usage analytics

To understand which features are used and to catch performance problems, SafeRoute records a small number of usage signals through TelemetryDeck, a privacy-focused, GDPR-compliant analytics provider. These signals carry an event name (for example, that a screen was opened or a route was found; that you opened Find Help, or confirmed a call to the emergency number, during navigation; that the app gave you an Area heads-up or Fresh incident nearby alert, that you chose Quiet for today on one, or that the app offered you alerts; or, from version 1.4, that a walk reached its destination or that the app asked iOS to show Apple's rating request) and a small set of coarse values describing what happened, some of them exact counts — how many routes or search results were returned, or how many incidents are in a part of the heatmap you tap; whether the safest route, or the one you started, was low, moderate or high for reported incidents, or, from version 1.4, for the one you started, that it had no crime data; which tab you switched to, and which of the routes, by rank, you chose; whether the routes had crime data behind them (from version 1.4 with, if they had none, the kind of reason our backend gave: a crime-data source failed to answer, the trip covered too large an area for a source, no crime data is published there, or another or no reason), whether you started navigation from them (from version 1.4, whether you started a walk while they were open; in versions before 1.4, whether a walk was under way when you left them, which often said no after a walk, because the results usually reappear when a walk ends), and whether navigation followed the route you chose or one Mapbox made instead; whether an alert setting was switched on or off; that the app told you alerts could not reach you, or could reach you only while the app was open, and why (notifications were off, or location access was not set to Always), and whether you then opened Settings from that notice; when the app offered you alerts, whether you turned them on or chose Not now, and how many times it had offered them; a load-time band; a failure reason; how long the route results were open, to the nearest band; from version 1.4, which map layer (Schools, Home values or the crime shading) was switched on or off, and from where (the map's own controls or, on the Nearby tab, in version 1.4 the Show home values on the map button or the Show schools here button, and from version 1.4.1 the Schools or Home values button on its map, both recorded as the Show schools here button was, so the value for Show home values on the map is no longer sent); each time a school's details are shown, its sector (state or private) and stage (nursery, primary or secondary), or that it publishes none; which school filter you changed (sector, stage, gender, boarding or charter), not what you chose; that you used the Schools in view list, and whether you opened a school from it; and, when you open an area with Home values shown (from version 1.4.1, not when the Home values button on the Nearby tab opens it for you), the kind of figure it has (a sale price, an owners' estimate or none) and whether it is coloured on the map; and a coarse region label (for example US, UK, Canada, or Mexico). TelemetryDeck's software also adds to each signal details of your device and settings, including the device model, iOS version, screen size and orientation; your language, region, locale and time-zone settings, light or dark mode, and accessibility settings such as text size, bold text and reduced motion; the app's version and whether it came from the App Store or TestFlight; the date and hour, and the time the signal was recorded, to the second; a random identifier for the session, which changes each time SafeRoute starts afresh or you come back to it after more than 5 minutes away; and the date TelemetryDeck's software first recorded a session (or, after more than 90 days without one, the date it next recorded one), how many sessions the app has had and on how many days, and how long the last session and the average session lasted. It also sends signals of its own when a session starts and when it detects a new installation. These signals never include your search text, coordinates, addresses, routes, or contacts, or, from version 1.4, which school or area you opened. From version 1.4, the app checks each of its own signals against a fixed list of signal names and values before recording it, and drops any signal that does not match; every signal on that list that version 1.4, 1.4.1 or 1.4.2 can send is described in this section, and the details TelemetryDeck's software adds, above, are not part of that check.

They are not, however, wholly identifier-free, and we would rather say so than imply otherwise. TelemetryDeck assigns each installation a pseudonymous client identifier, derived from the vendor identifier iOS gives us by hashing it on your device, with SHA-256 and no secret salt, so anyone who holds the unhashed identifier, as Mapbox does, could compute it. It is stable across sessions on the same device, which is what lets us tell one returning user from ten new ones. It is not your name, it is not shared with anyone, it cannot be reversed into your identity, it is reset if you delete and reinstall the app, and it is never combined with data from other companies. The vendor identifier it is derived from also goes, unhashed, to Mapbox, whose map software in the app sends it each time a map starts (see "The app's map" above); TelemetryDeck receives only the hashed form, and the app never sends the hashed form to Mapbox. TelemetryDeck does not use advertising identifiers and does not track you across other apps or websites. You can turn this off at any time in the app under About → Usage analytics (called Anonymous analytics before version 1.4). The app then stops recording its own signals at once, and nothing is sent from the next time SafeRoute starts afresh, rather than returning from the background. Until then, TelemetryDeck's software can still send signals the app recorded before you turned it off. In versions before 1.4, it can also send its own signal that a session has started, with the identifier and device details described above, when you come back to the app after more than 5 minutes away; from version 1.4, turning the switch off also stops TelemetryDeck's software from recording signals of its own.

Beyond the usage analytics described above and the website analytics described below, SafeRoute uses no advertising identifiers and no cross-app trackers, and the app is configured with NSPrivacyTracking = false in its Privacy Manifest.

Where an install came from

We advertise SafeRoute on the App Store, and we need to know whether those ads work. On its first launch, and if it has no answer, on up to four later launches, the app asks iOS for an attribution token using Apple's own AdServices framework and sends it to api-adservices.apple.com, which answers whether this install followed one of our Apple Search Ads. We keep two things from that answer: a single label — appleSearchAds, organic, or unknown if it has asked on five launches without an answer — and, where Apple supplies one, the numeric campaign identifier. Everything else Apple returns is discarded on the device.

This is Apple's own measurement API, not a third-party one. It does not use the advertising identifier (IDFA), it requires no App Tracking Transparency prompt, and it describes the advert rather than the person — so it is not tracking as Apple defines it. The resulting label is recorded as one analytics event, which means it carries the same pseudonymous client identifier described above, and it is silenced entirely if you have turned analytics off.

What is in your ears

To decide whether open-ear audio hardware is worth supporting, the app checks which kind of output your audio is currently routed to and records it as one of five broad categories: built-in speaker, wired, other Bluetooth, open-ear glasses, or other. The device's own name for that output — which is free text you may have personalised — is matched on the phone and discarded immediately. It is never stored, never logged and never transmitted; only the category leaves the device, with whether it was read as navigation started or when the output changed. SafeRoute requests no microphone access and records no audio.

Visiting safe-route.app

The website is hosted by GitHub Pages. As with any website, each page your browser loads sends GitHub your IP address, your browser's identification string (which names your browser, operating system and type of device), your language setting, the address of the page, and the page or site you came from if your browser reports one. The same goes for the data files a page fetches as you use it. On the map at /check/, while its Schools or home-values (Prices) layer is switched on, the names of the files it fetches show which squares of the map you are viewing; and after each lookup in an area with home-value data, the page fetches the home-values file for the square, from a few kilometres to about 28 km across, that holds the place looked up. The website serves its own typefaces and code libraries, including the Leaflet map library its map pages use, so loading a page contacts no font or code-delivery service. This policy page is different: GitHub Pages serves it from minhajk21.github.io, and it loads its typefaces from Google Fonts (fonts.googleapis.com and fonts.gstatic.com), which receive your IP address, the same browser details and, normally, only that the request came from this page's site (section 06).

The website sets no cookies. It stores nothing in your browser beyond its ordinary cache of the pages, images and other files it has loaded — no database, no service worker — unless you opt out of its analytics (see "Website analytics" below), in which case it keeps one on/off flag in your browser's local storage. That flag is the same for everyone who opts out, so no stored identifier follows you from one page or visit to the next.

Links to the App Store carry a label naming where on the site the link sits (for example web-home), so that Apple's App Store Connect can tell our placements apart; Apple receives the label, and your IP address, only if you click. On iPhone and iPad, our pages also carry a tag that lets Safari show Apple's Smart App Banner for SafeRoute. The tag gives Safari only our app's ID; Safari gets everything else the banner shows from Apple, and may contact Apple's App Store when a page loads to do so. We receive nothing from the banner. What Apple receives, from a click or from the banner, is covered by Apple's privacy policy.

Website analytics

Unless your browser sends a Global Privacy Control signal or you have opted out (see below), every page on the website loads Cloudflare Web Analytics, a cookieless visit counter. When a page loads, and again when you leave it, the script sends Cloudflare:

• Page: the page address, with anything after a ? or # removed.
• Where you came from: the page or site that linked you there, if your browser reports one.
• Browser: your browser's engine and version.
• Performance: how long the page took to load and draw, how much memory it used, how quickly it responded to a click or tap, and which element on the page was the largest or moved while loading. On the map pages the largest element can be a map image, whose web address names the square of map it shows — for example the wide region /check/ opens on, which it picks from your device's time zone, or, after a search from the home page, a square of map containing the place you searched for.
• Page-view number: a random number that identifies that one page view and is not reused.

As with any request, Cloudflare also receives your IP address, your browser's identification string and your language setting. The script does not send what you type into the website, and it sets no cookie and stores nothing on your device. Cloudflare states that this product uses no client-side state such as cookies or local storage, and that it does not fingerprint visitors for the purpose of displaying analytics. We look at the results only as totals, such as a daily summary of the most-visited pages, the sites visitors came from, and visitors' countries, with automated traffic excluded.

You can say no to this without contacting us, and nothing on the website depends on it:

• Global Privacy Control: if your browser sends this signal, the website does not load the counter at all, and stores nothing.
• Our opt-out switch: you can turn the counter off at safe-route.app/privacy-choices/. This keeps one on/off flag in your browser's local storage for safe-route.app (named sr:analytics-optout), which the website checks before loading the counter on any page. The flag is set by our page, not by Cloudflare. It records only that choice, is the same for everyone who opts out, is never sent to us or to Cloudflare, applies only to that browser, and is removed if you switch the counter back on or clear your browser's data for the site.

Blocking cloudflareinsights.com in your browser or with a content blocker also stops it.

Checking an address on the website

The map at safe-route.app/check/ sends what you type in its search box to our backend as you type — after each short pause, once you have typed two characters — so unfinished text is sent, not only the search you settle on. With each search it normally also sends the point at the centre of the map, rounded to about 100 m, so that places near what you are viewing rank first: before your first lookup, that point is usually in the region the map opened on; after one, it is in the area you are looking at, which may be around your own location. Our backend passes the text and that point to Mapbox to find matching places; Mapbox receives them from our server, not from your browser, and does not get your IP address. A search typed on the home page is normally carried to /check/ after a # in the page address, a part that browsers do not send to any server; /check/ removes it as it opens and then sends it to our backend like any other search. If JavaScript is turned off in your browser, the home-page box instead sends your search to GitHub as part of the page address (/check/?q=…).

When you pick a place or one of the examples, the page rounds that point to about 100 m (three decimal places) and sends it to our backend to fetch the crime summary for the area. Choosing a city under Where it works, or its dot on the map, sends that city centre's fixed coordinates in the same way. After a lookup, moving the map sends the new map centre, rounded in the same way, for the same purpose and to name the area. Our backend handles these as it does for the app: for most cities, a box about 2 km across, centred on the point, goes to that city's crime-data source, and the map centre goes to Mapbox for a place name. A point outside the areas we cover goes to no crime-data source. In the UK, the area we cover is England, Wales and Northern Ireland, the area data.police.uk holds (section 06). For the recent 911 calls, the page then sends only a short key naming the city or area our backend matched (for example seattle), not a point. For the street cameras, it asks which cameras are near the point rounded to about 1 km, and then asks for each still or clip by camera and city alone. Our server sends nothing about you on to those sources, but for the street cameras of New York City's Department of Transportation (NYC DOT), your browser then fetches each picture from NYC DOT itself (see "Street cameras on the website" below).

Nothing is sent to our backend until you search, pick a place or a city, or press the location button. The neighbourhood search boxes on the home page and on the city pages under /safety/ work entirely in your browser and send what you type nowhere. /tonight/ asks our backend for recent 911 calls in seven fixed cities as it opens, which tells us nothing about you beyond what any request carries.

Your location on the website

/check/ asks your browser for your location only when you press its location button, never when the page loads, and no other page on the website asks for it. If you allow it, the page does not ask your browser for its high-accuracy mode, and it rounds the position your browser returns to about 100 m before sending it to our backend to look up that area, as above. If you decline, nothing is sent.

The website's map

The map pages draw their map from images that your browser downloads directly from Mapbox (api.mapbox.com). Each image covers a fixed square of the map, so Mapbox receives your IP address and browser details together with the areas you look at, and the set of squares fetched shows where your view is centred. After a lookup — including one of your own location — the squares range from a few kilometres down to a few hundred metres across, and are smaller still if you zoom in. /check/ opens on a region chosen from your device's time zone; the time zone itself is not sent anywhere.

Street cameras on the website

As in the app, camera stills and London clips on /check/ are fetched by our server, so the transport authority never sees you, except the stills from NYC DOT's street cameras. Your browser asks our backend for each one by camera and city alone, with no point, and each request is written to our request log; while a Las Vegas still is open it is refreshed about once a minute, and each refresh is a new request. For an NYC DOT camera, NYC DOT's server does not answer ours, so our backend answers only with where to fetch the picture, and your browser then loads it directly from NYC DOT (nyctmc.org), each time it loads or refreshes. NYC DOT therefore receives your IP address, your browser details and which camera you opened. Your browser is told not to send a referrer, so NYC DOT is not told which page you were on (section 06). Live video works differently, again as in the app: it is played directly from the video service the camera's authority uses (511NY / NYSDOT for New York, Nevada DOT for Las Vegas), so that service receives your IP address, your browser details and that the request came from safe-route.app. The small video-player library (hls.js) that plays it comes from our own website. And because the still shown while the video starts comes through our server, our server can tell which live camera you opened on the website.

04What we do not collect

To remove ambiguity, SafeRoute does not collect:

• Your name, email address, phone number, or postal address (an address you type into a search box, or the destination of a walk you share, is handled as described in section 03)
• Your contacts, photos, calendar, or other on-device content
• Your device's advertising identifier (IDFA)
• Browsing history outside of SafeRoute, beyond the single page or site that linked you to our website, if your browser reports it (section 03)
• Health data, biometrics, or financial information
• Any identifier that ties your activity to you — the analytics client identifier described in section 03 is per-installation and pseudonymous, and is never linked to a name, an account, or data from other companies; the identifier iOS assigns to the app on your device, which Mapbox's map software in the app sends to Mapbox, is per-installation too (section 03). Because these identifiers are tied to your device, the App Store's privacy label lists the data the app collects as “linked to you” (section 03, "Search queries")
• Any identifier that follows you into other apps or websites
• Cookies or other data stored in your browser — the website sets no cookies, and stores nothing beyond your browser's ordinary cache of its pages, images and other files unless you opt out of its analytics, when it keeps one on/off flag that records only that choice (section 03); the page that shows a walk you share sets no cookies either and, since 17 October 2026, stores nothing beyond the browser's ordinary cache of the Leaflet files and map images it loads. Until then, the Mapbox map library it loaded kept a random identifier, a note of when it last reported to Mapbox, and a cache of map data in the browser of anyone who opened it; the page no longer reads or sends them, but a browser that opened such a link before 17 October 2026 keeps them until its data for the site is cleared, although Safari may remove them sooner, after 7 days without interaction with the site (sections 06 and 08)

05Why we use this information

Under Article 13 UK GDPR, we are required to tell you why we process your data and the lawful basis we rely on. Our processing is grounded in the following bases under Article 6(1) UK GDPR:

We have considered the balancing test for each "legitimate interests" use and concluded, except as set out below, that the limited processing involved is proportionate to a clear user-facing benefit. For the website's uses, we carried out that test in a written legitimate interests assessment dated 27 September 2026. That assessment also found one exception in the app: the area check that versions before 1.3.8 make when iOS relaunches them in the background for Area heads-up (section 03), which the alerts do not need; version 1.3.8, released on 1 October 2026, no longer makes it. Until 17 October 2026, that assessment did not cover Share my walk: we had not carried out the test in writing for the page that shows a shared walk to the people who open its link, including what their browsers send to Mapbox for the map. It still does not cover what Mapbox's software in the app sends to Mapbox (section 03): we have not yet carried out the test in writing for its usage check-ins, or for what versions 1.0.0 and 1.0.1 send while Mapbox Telemetry is on without your having chosen it. Update, 18 October 2026: for the page that shows a shared walk, we carried out that test in writing on 17 October 2026, in a revision of that assessment. It found that the page passes the test from 17 October 2026, when it stopped using Mapbox's map library (section 13). Until then, the usage events that the library sent Mapbox from viewers' browsers, and the random identifier it kept there for them, did not pass: they were not necessary to show the walk, and the identifier was stored in viewers' browsers without their consent. Update, 23 October 2026: on 19 October 2026 we carried out that test in writing, in a further revision of that assessment, for what changes on the page from version 1.4, which is not yet on the App Store on this date. That includes what happens after you choose Go in Find Help while sharing a walk (section 03): the page shows the place you chose, and the viewer's browser asks Mapbox for the map images around it. It found that the page still passes the test. The place, and with Live location the route to it, are needed to show your contact where you are heading. With Route only, the place shows roughly where you are, which the share otherwise shows only as the planned route; you choose that by tapping Go, after the app tells you that your contact will see where you are heading. The link's lifetimes do not change, and the only thing Mapbox receives in addition is the requests for the map images of one more area, with nothing stored in the viewer's browser. You can object to legitimate-interests processing at any time (see Section 9).

06Who we share your information with

To deliver the app and the website, your data is processed by a small number of named third parties. We do not sell, rent, or monetise your data, and we share only what is necessary for each subprocessor's specific function. The exception we know of is Mapbox's: in the app, Mapbox's map software sends Mapbox its own usage telemetry if you switch it on in a map's ⓘ menu or, from version 1.4, with About → Mapbox map data, and, in versions 1.0.0 and 1.0.1, unless you switch it off in that menu (section 03). Until 17 October 2026 there was a second: the Mapbox map library that the page showing a shared walk used sent Mapbox usage events, with a random identifier it kept in the viewer's browser. Since 17 October 2026 that page draws its map another way, as the website's map pages do, and sends Mapbox none (see Mapbox below and section 13).

If you share a walk, the people who have the link, and anyone they pass it on to, can see what section 03 describes under "Share my walk". They are not subprocessors, and we do not know who they are. The app you send the link with handles the message, which names your destination, under its own terms.

Each subprocessor handles your data under their own privacy policy. Mapbox and Render are subject to their own contractual data-protection terms with us. Apple's privacy practices are governed by their public privacy policy.

When you read this policy page, your browser also fetches its typefaces directly from the service below, which handles those requests under its own privacy policy. The website itself serves its own typefaces and code libraries.

07International transfers

Because the data controller (Minhaj Khan) is based in the United States, your personal data is processed in the U.S. by us and by Mapbox. Our backend infrastructure runs in Germany; requests to it pass through Cloudflare's network, which our host Render uses in front of its servers. The app's maps and navigation, and from version 1.4.2 the large Home Screen widget's map, also connect your device directly to U.S.-based Mapbox (section 03). When you use the website, your browser also connects directly to U.S.-based GitHub, Cloudflare and Mapbox, and, when you open an NYC DOT camera or a live video, to NYC DOT or the live-video service (see below); when you read this policy page, to GitHub and Google. When someone opens a link to a walk you share, their browser connects to our backend through Cloudflare, and directly to U.S.-based Mapbox for the map's images (section 06); until 17 October 2026, also for the usage events of the Mapbox map library the page then used.

Transfers from the UK to the European Economic Area (our backend's servers in Frankfurt, TelemetryDeck, the public Overpass servers in France, Austria, Germany and Finland and, once our server starts asking it (section 13), overpass.ch's servers in the EU) rely on the UK's adequacy regulations for the EEA, and, from that day, transfers to overpass.ch's operator, in Switzerland, rely on those for Switzerland: under Schedule 21 to the Data Protection Act 2018 (paragraphs 4 and 5), transfers to an EEA state, and to Switzerland under the European Commission's Decision 2000/518/EC, are treated as approved by regulations made under Article 45A UK GDPR. From the server update that switches on our own copy of OpenStreetMap data (section 13), our server sends the Overpass servers, overpass.ch included, only map squares and route boxes outside our covered regions, except in the cases section 03 describes ("Places that can help, and street lighting"). The UK has no general adequacy regulation for the United States, but since 12 October 2023 the UK–US "data bridge" has allowed transfers to U.S. organisations certified to the UK Extension to the EU–US Data Privacy Framework. Our U.S. recipients — GitHub, Inc.; Cloudflare, Inc.; Mapbox, Inc.; Render Services, Inc.; and Google LLC (for the typefaces on this policy page, which the website also used until 27 September 2026, and, from 10 August to 26 September 2026, for Gmail, which carried the status emails described in section 13) — are each certified to the UK Extension, so transfers from the UK to them rely on the UK–US data bridge. Render is a U.S. company, although our backend runs on its servers in Germany. We checked these certifications on the Data Privacy Framework List (dataprivacyframework.gov) on 27 September 2026.

The safeguards above do not cover three cases. First, our server sends the public crime-data services named in section 06 in the United States and Canada, and Hoyo de Crimen for Mexico City, at most the coordinates of the area or route being looked up, with no IP address or identifier. These are open-data services that we query, run by public bodies or, in Hoyo de Crimen's case, by an independent republisher of public data; they are not processors acting for us. Second, your browser contacts the live-video services and Apple directly, the app asks Apple's map services directly for place names and small maps (section 03), and your device, in the app or on the website, contacts NYC DOT directly for its street-camera stills; they handle your request under their own terms. Third, a walk you share is shown to whoever has the link, wherever they are, because you chose to send it to them.

You can request a copy of the safeguards in place by emailing minhaj@safe-route.app.

08How long we keep your information

We keep your information only as long as necessary to provide the service:

• Live route requests: Coordinates are processed in memory only and are not persisted to disk on our servers. The box around the routes we find is kept for a time as a cache key (see "Backend cache" below).
• Shared walks: Held in our backend's memory only and never written to disk. Deleted about 30 minutes after sharing stops, and never later than about 4 hours 15 minutes after the link was made, so no shared walk is kept for more than about 4 hours 15 minutes. From version 1.4, sharing also stops when the app tells our backend that you arrived, and pointing a walk at a place you choose in Find Help does not change when it is deleted. Positions sent from 4 hours after the link was made are not kept. At most the last 200 positions are kept, each with its time: at least about 50 minutes of walking. Every shared walk is lost if our server restarts. Once a walk is deleted, a page already open in someone's browser says the link was not found, but keeps showing the map it has already drawn until it is closed.
• Searches and lookups: Search text and any location sent with it (in the app, your device's current location; on the website, the centre of the map), the coordinates of places you look up, and, in the app, your device's current location when it checks your area, looks for help nearby or runs the Fresh incident nearby check, travel in the address of each request. Our request log (below) keeps only the length of the search text and those locations cut to about 1 km, and the line holds no IP address or other identifier of you; our caches keep some of these locations more precisely for a time (see "Backend cache" below).
• Backend cache: To reduce load on our sources, our server caches what it fetches from them. Crime data is cached for up to 24 hours under the box that was looked up, to about 10 m: for an area lookup, a box centred on the point the app or the website sent (the website rounds it to about 100 m first); for a route, the box around the candidate routes, whose edges usually pass through or near where the route starts and ends. So, for that time, a cache key can show the point you looked up, or roughly where a route you planned starts and ends. For Dallas, since 30 September 2026, our server also keeps the last good result for each box, to fall back on if a fresh pull fails or is slow; it uses that result for up to 7 days, but holds it in memory until newer results push it out or the server restarts, which may be later still. Crime data for Fort Worth and San Diego, and each city's recent 911 calls, are cached for the whole city, with no point. Street-lighting data is cached for up to 24 hours, keyed by the box around the candidate routes, to about 100 m. Place-of-interest data is cached for up to 24 hours, keyed by fixed map squares about 2 km across; from the server update announced in section 13 on 31 October 2026, when a square cannot be fetched, our server also notes that square, in memory, uses that note for up to 2 minutes, so that it does not ask for the square again at once, and deletes it within about 3 minutes. From the server update that switches on our own copy of OpenStreetMap data (section 13), these street-lighting and place-of-interest caches, and those notes, hold only the boxes and squares our server asks the Overpass servers for (section 03, "Places that can help, and street lighting"). For the lookups our copy answers, nothing is cached by route box, and our server holds what it has read from the copy, for places and for street lighting, in memory for up to 1 hour, keyed by fixed map squares about 2 km across, and deletes it by then; the clean-up times below do not apply to it. Search results are cached for up to 30 minutes, keyed by the search text and the area searched from, to about 10 km, and place names for up to 30 minutes, keyed by the location rounded to about 100 m. Area summaries are cached for up to 24 hours, keyed by the location rounded to about 100 m; each holds only the centre of that cell, and every answer carries the asker's own point (until 27 September 2026, a summary kept the exact point of the lookup that created it; see section 13), but the crime data fetched for it is cached under the box around the point itself, as above. Which UK police force covers an area is cached for up to 7 days, keyed to about 1 km; street-camera stills and clips for less than a minute, and each city's camera list for 10 minutes, keyed by camera or by city. For crime data, street lighting, area summaries, search results, place names and UK police forces, each time above is how long our server uses an entry: it deletes an expired entry when the same entry is next looked up, or at its next clean-up, which runs every hour for the entries kept for 24 hours or 7 days and every 5 minutes for search results and place names, so an entry can stay in memory for up to about an hour, or 5 minutes, longer (section 13). From the server update announced in section 13 on 31 October 2026, street-lighting entries are deleted within about 24 hours of being fetched. Cached data is keyed by search text, area, camera or city, not by user, is held in memory only, and is lost whenever the server restarts.
• Our copy of OpenStreetMap data: from the server update that switches it on (section 13), our server keeps on its disk a copy of the OpenStreetMap data that Find Help, the Nearby tab and street lighting use, usually replaced each week and never used once its data is more than 30 days old. It holds map data only, and nothing about you or your lookups (section 03, "Places that can help, and street lighting").
• Request logs: One line per request (see section 03), kept for security and abuse prevention, with search text reduced to its length and coordinates cut to about 1 km. Our host Render keeps them for about 7 days, after which they are no longer available to us.
• Rate limiting: To enforce rate limits, our server counts requests in memory for one to two minutes after the last one, keyed on the IP address each request arrives from (yours, or an address in our host's network). The count is never written to disk.
• On-device data: Your iPhone keeps, under your device's normal control, Mapbox's cache of the map data it has downloaded (section 03); from version 1.4.2, the large widget's latest pictures of its map, one light and one dark, which show the area around the last location the app recorded: the widget reuses them for up to 12 hours and keeps them until a later refresh draws a different map, and otherwise until iOS clears the widget's cache or you delete the app; the last 8 places you picked in a place search, your home place if you set one, and the last 6 areas you looked up on the Nearby tab, each with its location; the last location the app recorded, with its time, which the widget uses (section 03), the name of your area, with the location the app found it for, and the last area check the app or the widget made, with its answer and the point it was for; and your settings, such as which alerts are on. If you turn on Area heads-up, it also keeps a map of the nearby high-incident zones, with the point it was built around, and which zones have given you an alert, and when (up to the last 80), which shows roughly where you were at those times; and if you turn on Fresh incident nearby, the location of each incident it has alerted you to, with when. Turning these alerts off stops the app adding to these records but does not delete them; deleting the app does. With Usage analytics on, TelemetryDeck's software also keeps the signals it has not yet sent to TelemetryDeck, and a record of your sessions: the date it first recorded a session (or, after more than 90 days without one, the date it next recorded one), each day on which TelemetryDeck's software started, when each recent session started and how long it lasted, and how many earlier sessions there were; each time TelemetryDeck's software starts, which it does only while Usage analytics is on, it drops sessions more than 90 days old from that record and adds them to that count (section 03). Turning Usage analytics off does not delete them either: until SafeRoute next starts afresh, TelemetryDeck's software can still send those signals and add to its record of your sessions (section 03), and if you turn Usage analytics back on, it sends any signals it had not yet sent. Your Apple Watch keeps only the latest navigation status your iPhone sent it. From version 1.4, the app also contains the school and home-value data it shows, and keeps on your iPhone whether you have turned the Schools layer on (not your school filters, or whether Home values was shown); with the latest list of nearby places it found for Find Help or the Nearby tab, which earlier versions keep too, the point it looked from and when, so that it shows a list only near where you are, until it finds a newer one; your choice for Mapbox map data, and that version 1.4 has switched it off once (section 03); how many of your walks have reached their destination, with when and in which version the app last asked iOS to show Apple's rating request, to decide when it may ask again; and, each time a shared walk reaches its destination, the code and secret of that walk's link and the time you arrived, until our backend confirms or rejects the arrival, so that the app can send it again if it does not get through (section 03). The app deletes them once our backend confirms or rejects the arrival or, if it never does, the first time you open SafeRoute more than about 5 hours after you arrived, without sending them. The app does not send us these records, apart from the last location the app recorded, which the widget sends as section 03 describes; that code and secret, which the app sends to our backend with the arrival; and the signals TelemetryDeck's software has not yet sent, which it sends to TelemetryDeck with figures taken from its record of your sessions (section 03). You can clear this at any time by deleting the app. You can also clear the lists of recent places and recent areas, and your home place, in the app. The website sets no cookies and stores nothing on your device beyond your browser's ordinary cache of the pages, images and other files it has loaded, except the one on/off flag it keeps if you opt out of its analytics, which stays until you switch analytics back on or clear your browser's data for the site. You can clear both in your browser.
• Other providers' records: GitHub states that it logs and stores the IP addresses of visitors to the website, without saying for how long. Cloudflare states that it keeps unsampled Web Analytics data for 7 days, after which it is aggregated down to around 10%; it does not say how long that is kept. overpass.ch, from the day our server starts asking it (section 13), states that it does not store the content of queries. It does keep each successful answer in a cache for 60 seconds, to answer an identical query again, and, for 30 days, a record of each request with its time, our key's identifier, its status, duration and size, whether the cache answered and a hash of the query; for nearby help, whose map squares are fixed, that hash can show which square our server asked for, and when, though not who asked. Its technical logs, which hold our server's IP address, not yours, are deleted generally within 30 days. From the server update that switches on our own copy of OpenStreetMap data (section 13), our server sends overpass.ch only map squares and route boxes outside our covered regions, except in the cases section 03 describes, and the records of its requests concern the same squares and boxes. We have not been able to confirm how long Google, Mapbox, Apple, the live-video services, NYC DOT, Cloudflare's network in front of Render, or unpkg and jsDelivr (which the website used until 27 September 2026) keep records of your browser's or device's requests; their own privacy policies apply. Until 17 October 2026, Mapbox's map library kept a random identifier in the browser of anyone who opened a link to a walk you share, with a note of when it last reported to Mapbox and a cache of map data; the page no longer reads or sends them, but they stay in that browser until its data for the site is cleared, although Safari may remove them sooner, after 7 days without interaction with the site. We cannot see how long Mapbox keeps the usage events it was sent with.

We keep no account, profile or identifier for you on our servers; a walk you share is held under a random code, not linked to you or to any other link you make, until it is deleted as above. Our request log and caches are not linked to you by any identifier, but we treat a precise location you look up as personal information, because it can reveal where you are.

09Your rights under UK GDPR

You have the following rights regarding your personal data. Because we hold no persistent identifiers tying you to specific records, some rights may be inapplicable in practice — but you can always invoke them and we will respond. While a walk you share lasts, its link identifies its record. These rights also apply to people who open a link to a shared walk.

• Right of access (Art. 15): you can request a copy of any personal data we hold about you.
• Right to rectification (Art. 16): you can request correction of inaccurate data.
• Right to erasure (Art. 17): you can request deletion. (In practice, simply uninstalling the app removes any locally cached data; the website stores nothing on your device beyond your browser's ordinary cache and, if you opted out of its analytics, one on/off flag, both of which you can clear in your browser.) Deleting the app does not end a walk you have shared: to end one early, end navigation or tap Stop sharing on Apple Watch (in versions before 1.4, only while you navigate), and we delete it within about 30 minutes (section 08). Choosing Go on a place in Find Help ends navigation but not sharing. From version 1.4, the app then starts navigating to that place, if it finds a route and, after Go on your watch, you open SafeRoute within about 10 minutes, and ending that navigation ends sharing too; if that walk does not start, tap Stop sharing on your watch, start and end another navigation, or share another walk; in versions before 1.4, end your next navigation in the usual way or tap Stop sharing on your watch during it (section 03). Sharing another walk also ends one, but we then keep the new walk until it, in turn, stops or expires. If SafeRoute has been closed or restarted since you made the link, you cannot end it early from the app (section 03); you can email us, and we can end it by restarting our server, which ends every shared walk, if it has not expired by then.
• Right to restrict processing (Art. 18).
• Right to data portability (Art. 20): receive your data in a structured, machine-readable format.
• Right to object (Art. 21): you can object to processing based on legitimate interests at any time. For the website's analytics, which carries no identifier we could use to find your records, you can object without contacting us: turn on Global Privacy Control in your browser, or switch the analytics off at safe-route.app/privacy-choices/ (see section 03).
• Rights relating to automated decision-making and profiling (Art. 22A, as introduced by the Data (Use and Access) Act 2025): SafeRoute uses an algorithmic crime-exposure score to rank candidate walking routes. This is route ranking based on public data, not a decision made about you, and does not produce legal or similarly significant effects on you. Article 22A safeguards therefore do not apply, but you can disable the safety overlay in-app at any time.

To exercise any of these rights, email minhaj@safe-route.app with the words "Privacy request" in the subject line. We will respond within one calendar month.

10Children

SafeRoute is a general-audience navigation app and website. It is not directed at children under 13 and we do not knowingly collect any personal information from children under 13. SafeRoute may be downloaded and used by older minors (13–17) on their own devices; in that case, the same minimal data practices described in this policy apply.

In line with the "children's higher protection matters" duty added to the UK GDPR by the Data (Use and Access) Act 2025, we have considered the needs of minors who may use the app or the website. SafeRoute does not contain advertising, in-app purchases, social features, profiling, or content unsuitable for minors. The one feature that shows anything about you to other people is Share my walk (section 03). It works the same way for every user: nothing is shared until you make a link, the link carries no name or account, and the walk is deleted within hours (section 08); but Live location is selected unless you change it, so a link you send shows your position while you navigate. We do not target children with marketing.

11Security

We protect your data using:

• Transport security: All traffic between the app and our backend uses TLS 1.2 or higher. App Transport Security (ATS) is enforced. The website is served only over HTTPS (plain http:// requests are redirected), and its requests to our backend use HTTPS too.
• Authentication on backend endpoints: Most of our backend requires a key that is shipped with the app, not entered by users. The read-only endpoints the website uses need no key, because a web page cannot keep one secret, and neither do a few other read-only ones: a health check, the nearby-help lookup, and the pages that let someone follow a walk you have shared. Anyone with the link can open those pages: the link holds a random 12-character code, the pages are not rate-limited, and changes to a walk need a separate secret, which our server keeps with the walk and gives only to your phone.
• Rate limiting: Most endpoints are rate-limited by the IP address each request arrives from, to prevent abuse; the ones the website uses allow 30 requests a minute, and the nearby-help lookup, since 17 October 2026, 60.
• Minimal data collection: The strongest protection is data we never collect.
• No password storage: SafeRoute has no accounts, so we never store passwords.
• Server hardening: Our backend runs on Render's managed platform with automatic OS patching.

No system is 100% secure. If we ever became aware of a personal data breach affecting users, we would notify the ICO within 72 hours under Article 33 UK GDPR, and notify affected users without undue delay if the breach posed a high risk to their rights.

12Right to complain

If you believe we have not handled your personal data appropriately, you have the right to lodge a complaint with the Information Commissioner's Office (ICO):

• Website: ico.org.uk/concerns
• Phone: 0303 123 1113
• Post: Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF

We would prefer the chance to address your concern first — please email minhaj@safe-route.app.

13Changes to this policy

We may update this policy from time to time, for example to reflect changes to our app, our subprocessors, or applicable law. Material changes will be reflected by a new "Updated" date at the top of this document. Significant changes that introduce new processing purposes will be communicated through an in-app notice before the new processing begins; because the website cannot notify you, changes that affect it will be published on this page before they take effect.

Correction, 29 September 2026. Until this update, this policy did not cover the website, even though the website linked to it, and the website's processing began before we disclosed it: GitHub Pages hosting and Google Fonts from the website's first version in May 2026; the tag for Apple's Smart App Banner from 2 July 2026; the address-check map — search, location, the Leaflet library from unpkg, and map images from CARTO — from 25 July 2026; Cloudflare Web Analytics from 2 August 2026; live camera video on the website, with hls.js from jsDelivr, from 25 August 2026; map images from Mapbox, replacing CARTO, from 27 August 2026; and the map position, rounded to about 100 m, that the address-check map sends with each search, from 26 September 2026. CARTO received your IP address and the map areas you viewed during that period; it receives nothing now. Until 27 September 2026, the website also loaded its typefaces from Google Fonts and its code libraries from unpkg and jsDelivr, which received your IP address and browser details, and the address-check map sent the points you looked up, and your location if you shared it, without rounding them. Since then the website serves those files itself, and the map rounds these points to about 100 m before sending them.

Several statements about the app and our backend were also wrong, some of them since this policy was first published on 6 May 2026:

• Request log: we said it records IP addresses and that we do not store your searches. Until 27 September 2026, it recorded the address of each request in full, including any search text or coordinates — among them your device's location when the app checks your area, looks for help nearby or ranks search results — and it has never recorded the IP address. We also said we retain no personal information on our servers; the log held these locations and searches. Since 27 September 2026 it keeps only the length of search text and cuts coordinates to about 1 km; lines written before then are kept for about 7 days, like any other.
• Home Screen widget: we did not say that it sends the last location the app recorded to our backend about every 30 minutes, without you opening the app. Update, 4 October 2026: Version 1.3.8, released on 1 October 2026, rounds that location to about 100 m before sending it, and does not send it while the rounded point is within about 100 m of the one its last answer was for, that answer gave a risk level and is less than 6 hours old, and the app has not checked an area since; earlier versions still send it unrounded (section 03).
• Area heads-up: since version 1.3.0 (August 2026), when iOS relaunched the app in the background for these opt-in alerts (since version 1.3.4, also as you moved), the app could check your area as if you had opened it, sending your current location to our backend; we did not say so, and the app's request for Always location access said your location was never sent to our servers. Update, 4 October 2026: Version 1.3.8, released on 1 October 2026, no longer checks your area, or contacts our backend, when iOS relaunches it in the background for these alerts, and its request for Always access now says that watching the zones happens on your phone and sends nothing to our servers; earlier versions still make the background check (section 03).
• Fresh incident nearby: since version 1.3.0 (August 2026), this opt-in check has sent the device's position, to about 1 m, to our backend in the background and when the app opens, and until 27 September 2026 our request log recorded it at that precision; we did not say so. Update, 4 October 2026: Version 1.3.8, released on 1 October 2026, rounds the position to about 1 km on your device before sending it, and the text under the switch says so; earlier versions still send it to about 1 m, which our server cuts to about 1 km as it arrives (section 03).
• Area summaries: from 3 June to 27 September 2026, a cached area summary kept the exact point of the lookup that created it, and our server returned that point with the summary to anyone whose later lookup in the app or widget fell in the same cell of about 100 m within 24 hours; we did not say so.
• data.police.uk: we said it receives bounding-box coordinates only. It has also received the exact point of each area lookup, and until 27 September 2026 it was our fallback for places outside the areas we cover, so lookups in the app anywhere else in the world, including lookups of your own location, were sent to it. Until 28 September 2026 it also received lookups anywhere in the rectangle our UK area used, including Scotland, the Isle of Man, the Republic of Ireland and part of northern France, although it holds no crime data for those places. Until 29 September 2026, a lookup near the border with Scotland or the Republic of Ireland could also send it grid points on the other side: up to about 4 km across it for an area, and as far as the route went for a route that crossed it.
• Other crime sources: for an area lookup, the box they receive is centred exactly on the point looked up; Fort Worth, San Diego and the 911-dispatch sources receive no coordinates at all.
• OpenStreetMap lookups: we said the OpenStreetMap Foundation, in Germany, receives approximate area coordinates. These lookups go to independently run Overpass servers, not to the Foundation and not only in Germany (section 06), and since 11 June 2026 the street-lighting query has sent a box around the candidate routes that is not rounded.
• Error reports: From 10 August to 26 September 2026, some error messages included a map position rounded to about 100 m. They reached our private monitoring logs, status emails and an AI triage step that used Anthropic's Claude: from 10 August on our own computer, under Anthropic's consumer terms rather than a data processing agreement, and from 15 September also in our GitHub monitoring, under Anthropic's commercial terms. We removed the position on 26 September 2026 and have since deleted the affected monitoring logs. No personal data reaches Anthropic now.
• Backend access: we said our backend rejects unauthenticated requests and that every endpoint is rate-limited. A health check and the nearby-help lookup have been open, without a rate limit, since before this policy was published; the links for following a shared walk have been open since 9 May 2026; and the website's endpoints have needed no key since 25 July 2026. Update, 18 October 2026: since 17 October 2026, the nearby-help lookup has been rate-limited, at 60 requests a minute for each IP address requests arrive from (section 08); it still needs no key.
• Transfers: we said there is no adequacy decision for the United States. The UK–US data bridge has been in force since 12 October 2023, before this policy was first published.

Correction, 30 September 2026. Dates in this correction, like every mention of 30 September 2026 in this policy, are in US Eastern time. This policy did not describe Share my walk; what we published about the feature in the app, on the page your recipients see, on our support page, home page and other website pages, and in our App Store description and release notes was wrong; the app's own screens, our home page and our release notes were wrong about the app's alerts, the app's screens and our home page about where your location goes and about its analytics, and our home page said there was no advertising; this policy has never said how precisely two of our server's caches are keyed; and our update of 29 September 2026 described our request log wrongly and misdated a problem with area summaries:

• Share my walk: section 03 said coordinates are sent to our backend solely to compute walking routes and to retrieve crime context for your area. Since the app was first released, in May 2026, Share my walk has also sent our backend the name of your destination, the full route you planned, including where it starts, and your estimated walking time, and, with Live location, which is selected unless you change it, your position about every 15 seconds while you navigate, for anyone with the link to see; we did not say so. Until 29 September 2026 this policy did not mention shared walks at all, and since then only in passing; nor did it say that the browser of anyone who opens such a link contacts Mapbox, whose map library keeps a random identifier in it. Section 03 now describes the feature.
• Arrival: because of a fault in the app, no released version has ever told our backend that you arrived. Sharing, Live location included, continues until you end navigation, at your destination or earlier, or stop it in one of the other ways section 03 describes; choosing Go on a place in Find Help ends navigation without stopping it. When our backend is told that sharing has stopped, the page says that you stopped sharing, never that you arrived, and the link keeps working for about 30 minutes; if sharing never stops, it works until about 4 hours 15 minutes after it was made (section 08). Until then our backend holds the walk's route and positions. The next seven bullets list what we published that said otherwise. Update, 23 October 2026: version 1.4, which is not yet on the App Store on this date, fixes the fault. When it detects that you have reached your destination, it tells our backend, sharing stops and the page says that you arrived; choosing Go on a place in Find Help keeps sharing and points the link at that place (section 03). Earlier versions keep the fault until they are updated.
• The app's sharing screen: it says, in English and Spanish, that Live location "Stops automatically when you arrive", that with Route only the "Page turns green when you mark arrived", and that "The link expires when you arrive — and after 4 hours either way". It also calls the link "Anonymous": the link carries no name or phone number, but the route it shows often starts where you were when you planned it. We will correct this screen in version 1.3.9. Update, 4 October 2026: we will correct it in version 1.4, not 1.3.9 (see the correction of 4 October 2026 below). Update, 23 October 2026: version 1.4, which is not yet on the App Store on this date, corrects it, in English and Spanish. It says that "Sharing stops when you arrive or end navigation; the link stops working about 30 minutes later, and at the latest about 4 hours 15 minutes after you make it", and it no longer calls the link anonymous. Choosing Go in Find Help, which says that your contact will see you heading to the place you choose, ends navigation without stopping sharing (section 03). Its Route only option now says that the page shows your planned route and estimated walking time but not where you are, unless you choose Go on a place in Find Help, when it shows that place, which is near you (section 03).
• The page your recipients see: since the app was first released, it said for Route only that "The page will turn green when they arrive" and, once a walk had passed 4 hours, that "The walker may have arrived without confirming". We removed both on 30 September 2026; the page now also links to section 03. Once a link is 4 hours old, the page still says "No update for a while" and "The walk hasn't updated for over 4 hours", even if your positions have kept arriving; we will correct that. Update, 4 October 2026: corrected today. Once a link is 4 hours old, the page now says "Link is closing" and "This link is more than 4 hours old and will stop working soon", with, for Live location, how long ago it last updated, and our backend no longer keeps positions sent from then on (see the change of 4 October 2026 below).
• Our support page: from 12 May 2026 it said that share links end when you mark your walk as arrived or four hours after they are made, whichever comes first, and that once a link expires the page tells your recipient the walk has ended. A link lasts up to about 4 hours 45 minutes (section 08), and when it is 4 hours old the page says that it will close soon. It also asked you to send us share links (see "Share links sent to us" below). We corrected both on 30 September 2026.
• Our home page: from May to 23 August 2026, it said of Share my walk that the person you send the link to will "see you reach your destination, then the link expires", that with Route only "the page turns green when you mark yourself arrived", and that "The link ends when you arrive, and after four hours either way"; a picture of the sharing screen was captioned "EXPIRES ON ARRIVAL". In fact the link does not end when you arrive, the page never shows that you arrived, and a link lasts up to about 4 hours 45 minutes (see above and section 08). We removed that section on 23 August 2026 without saying it was wrong.
• App Store description: in English and Spanish, it says that the recipient can follow your location "until you arrive", that share links "expire when your walk ends", and that "Your routes aren't stored on our servers", although a walk you share is held there until it is deleted, and our cache keeps the box around each route you plan for up to a day, or longer in Dallas (section 08). It also describes an "Arrival check-in" that, when you reach your destination, prompts you to send an "Arrived safely" message, which the app has never shown. We will correct the description with the listing for version 1.3.8. Update, 4 October 2026: done. The description published with version 1.3.8 on 1 October 2026, in English and Spanish, no longer says any of this.
• Our neighbourhood safety pages: since 2 July 2026, the pages under safe-route.app/safety/ have said that you can use the app to "check in when you arrive", and since 14 September 2026 our night-safety pages have said that it "lets you share a walk and check in on arrival". We will remove both. Update, 4 October 2026: we removed both.
• Release notes: our App Store release notes for version 1.3.2 (September 2026), in English and Spanish, said "When you arrive, SafeRoute now asks one question" about how the walk felt, and that "It is anonymous". Because of the fault above, no released version has asked it, and the answer would be sent with a pseudonymous key for your device (see Street Feel below). Our notes for version 1.3.0 (August 2026) said of the app's opt-in alerts "your location is never sent to our servers", and those for version 1.3.4 (September 2026), in English and Spanish, that they work "with nothing sent anywhere" (see "Alerts and analytics on our home page" below). Published release notes cannot be changed, so we correct them here.
• Share links sent to us: from 12 May to 30 September 2026, our support page asked you to include the link in a bug report about a shared walk, saying such links "are anonymous and don't contain personal data". While a link works, anyone who opens it can see your destination, your route and, with Live location, where you are. Any link sent to us that way stopped working within about 4 hours 45 minutes of being made, or sooner if our server restarted, and none can be opened now.
• Alerts and analytics on our home page: since 23 August 2026, safe-route.app has said of the app's opt-in alerts: "No push servers, no location ever sent to us". Until 27 September 2026 it also said "The alerts run entirely on your iPhone — your location never reaches our servers at all", and until 29 September 2026 "The safety alerts run entirely on your iPhone". The app sends your location to our backend whenever you plan a route or check your area; Fresh incident nearby has sent your position since version 1.3.0 (August 2026), and Area heads-up can send it when iOS relaunches the app in the background (section 03 and the bullets for 29 September above). Until 29 September 2026 the home page also said that the app's analytics carry "no personal data", although they carry a pseudonymous identifier for each installation (section 03). We changed the second of these statements on 27 September 2026, and removed the third and changed the fourth on 29 September 2026, without saying they were wrong; we corrected the first on 30 September 2026.
• The app's own screens: since June 2026 the card that asks for your location has said, in English and Spanish, "We use your location only on your device — no account, nothing stored on our servers"; since version 1.3.0 (August 2026) the Area heads-up switch in About has said "your location is never sent anywhere", and since version 1.3.4 (September 2026) the offer to turn alerts on has said that iOS watches the boundaries on your phone, "so nothing is sent anywhere"; and since June 2026 the analytics switch has said, in English and Spanish, "No personal data, location, or searches — ever". The app sends your location to our backend whenever it checks your area or plans a route, Fresh incident nearby sends your position and Area heads-up can, our backend holds a walk you share, and the analytics carry a pseudonymous identifier for each installation (section 03). Until 29 September 2026 a picture of the About screen on our home page showed the second and fourth of these; we removed them from it without saying they were wrong. Version 1.3.8, our next release, replaces all four. Update, 4 October 2026: done. Version 1.3.8, released on 1 October 2026, shows none of the four; earlier versions still do until they are updated.
• Advertising on our home page: until 30 September 2026 our home page said there is "no advertising". The app carries no ads, but we advertise it on the App Store with Apple Search Ads and the app reads Apple's attribution token on its first launch (section 03). The home page now says "no ads in the app".
• Request log: our update of 29 September 2026 said the log keeps the code in a link to a shared walk. It had stopped on 27 September 2026; since then it replaces the code with a placeholder. Until 27 September 2026, the full addresses it recorded also included the code in each link to a shared walk, which would have let anyone reading the log open that walk while it lasted; we did not say so. Those walks were deleted within hours (section 08), so the codes in lines still kept no longer open anything.
• Backend cache: since it was first published, this policy has said that cached data is keyed by area, not by user, without saying how precisely, and our update of 29 September 2026 gave the precision of several keys but left out two. Crime data is cached for up to 24 hours under the box that was looked up: to about 100 m until 22 May 2026, and to about 10 m since. For that time, a cache key can show the point of an area lookup, or roughly where a route you planned starts and ends. And since 11 June 2026, street-lighting data has been cached for up to 24 hours under the box around the candidate routes, to about 100 m. Section 08 now describes both, and the fallback for Dallas that we added on 30 September 2026.
• Area summaries: our update of 29 September 2026 said that a cached area summary kept the exact point of the lookup that created it, and passed it on, from 3 June 2026. That began on 22 May 2026, when our server began answering area lookups, and lasted until 27 September 2026.

The same fault means the app has never shown the check-in it was meant to show when you arrive. That check-in includes Street Feel, an optional question about how the walk felt, which would send our backend the small map cells along your route, each about 150 m from north to south and, depending on how far north you are, 85 to 145 m from east to west (except the first and last), whether it was day, evening or late, your answer and a pseudonymous key for your device. No released version has asked it or sent anything for it, although our release notes for version 1.3.2 said otherwise (see "Release notes" above). We will fix the fault in version 1.3.9. Because that will also change how sharing ends, we will update sections 03 and 08 and our support page, and describe Street Feel in this policy, before that version is released. Update, 4 October 2026: that version will be numbered 1.4, not 1.3.9, and these commitments now apply to version 1.4 (see the correction of 4 October 2026 below). Update, 23 October 2026: version 1.4, which is not yet on the App Store on this date, fixes the fault, and sections 03 and 08 now describe how sharing ends from that version, as does our support page. When you arrive, version 1.4 shows the check-in, which offers a ready-made message saying that you arrived safely, for you to send yourself if you want to, but it does not ask the Street Feel question and sends nothing for it. We said we would describe Street Feel here before that version was released. Because version 1.4 does not ask it, we have not done so; we will describe it here, and show a notice in the app, before any version asks it.

Change, 1 October 2026. Dates in this note are in US Eastern time. Until 29 September 2026, 511NY passed the pictures from NYC DOT's street cameras through its own server, so our server fetched them from 511NY, just as it fetches every other camera still from its source. That day 511NY moved to a new system and stopped passing them through, and NYC DOT's own server does not answer ours, so those cameras dropped out of our New York camera layer. To bring them back, from 1 October 2026 your device, in the app or on the website, loads their pictures directly from NYC DOT, which therefore receives your IP address and your device's or browser's details. The app sends no referrer, your browser is told not to send one, and our server only tells your device where to fetch each picture (section 06). Stills from NYSDOT's highway and bridge cameras still come through our server. Separately, since 1 October 2026 New York stills on the website are no longer refreshed while they are open, so section 03 no longer says they are.

Correction, 4 October 2026. Dates in this correction are in US Eastern time. One of our commitments has changed, and some of what we published was wrong or incomplete:

• Version 1.3.9: on 30 September 2026 we said we would fix the arrival fault and correct the app's sharing screen in version 1.3.9. Those fixes will ship in version 1.4 instead. If we release a smaller update before then to fix an urgent problem, it will not contain these fixes, and we will say so here. Update, 23 October 2026: version 1.4, which is not yet on the App Store on this date, contains these fixes (section 03, and the change of 23 October 2026 below). No smaller update has been released since version 1.3.8.
• "Anonymous" analytics: this policy, our support page, our home page and the README published with our website's code called the app's usage analytics "anonymous", and section 06 said they carry no personal data. They carry a pseudonymous identifier for each installation, as section 03 also said, so we no longer call them anonymous. The switch in the app keeps the name "Anonymous analytics" until version 1.4 renames it. Update, 23 October 2026: version 1.4 calls it "Usage analytics".
• What our analytics record: section 03 listed the values the app's analytics record, but left some out, such as which tab you switch to, which route you choose, whether navigation followed the route you chose, and, with the kind of audio output, whether it was read as navigation started. Nor did it say that TelemetryDeck's software adds details of your device and settings to every signal, or that it sends signals of its own when a session starts and when it detects a new installation. Section 03 now lists them; none of them includes your search text, coordinates, addresses, routes or contacts.
• Where an install came from: this policy said, in sections 03 and 06 and in our correction of 30 September 2026 above, that the app asks for Apple's attribution token on its first launch, and section 03 said that the label recording where an install came from is appleSearchAds or organic. If Apple has no answer, every version that asks for the token asks again on up to four later launches, and if it still has none, the label is unknown. Sections 03 and 06 now say so.
• Turning analytics off: section 05 said that turning off the app's analytics stops the processing entirely. The app stops recording its own signals as soon as you turn the switch off, but until SafeRoute next starts afresh, rather than returning from the background, TelemetryDeck's software can still send signals the app recorded before then, and its own signal that a session has started, with the pseudonymous identifier and the details of your device and settings, when you come back to the app after more than 5 minutes away. From the next start, nothing is sent. Sections 03 and 05 now say so. Update, 23 October 2026: from version 1.4, turning the switch off also stops TelemetryDeck's software from recording signals of its own, including the one when a session starts; signals already recorded can still be sent until SafeRoute next starts afresh (section 03).
• The app's map: this policy said what Mapbox receives through our backend, from the website and from the page that shows a shared walk, but not what the maps and navigation in the app send to Mapbox directly from your device: your IP address and device details, the areas of map you view, the route you navigate, with the names of its start and destination (in some cases, of its stops too), the text of spoken directions, in some cases your position, and, each time a map starts, the identifier iOS assigns to the app on your device, unhashed. Section 03 said that our analytics identifier is derived from that identifier and hashed, but not that the hash has no secret salt, so anyone who holds the unhashed identifier, as Mapbox does, could compute it. Nor did it say what Mapbox's software sends if you switch on its telemetry in a map's ⓘ menu, which Mapbox describes as "anonymous usage data" although it carries that identifier, including your location, your route and anything you send with Mapbox's Report button or "Rate your trip" screen, with a screenshot; or that versions 1.0.0 and 1.0.1, from May 2026, leave that telemetry on unless you switch it off. Every version since 1.0.2 (June 2026) switches it off each time the app starts. Sections 03, 04, 05 and 06 now describe all of this. Update, 23 October 2026: version 1.4 no longer switches it off each time it starts: it switches it off once, the first time it starts, including after an update, and then it stays as you set it, and version 1.4 does not show Mapbox's Report button or "Rate your trip" screen (section 03, and the change of 23 October 2026 below).
• Apple's map services: this policy did not say that the app asks Apple's map services (Apple Maps) to turn your current location into the name of your area on the Nearby tab, to name the street and area at the point of an alert, and to draw the small maps in alerts and in the widget, so that Apple receives those locations and areas of map. Our support page already said so for alerts. Sections 03, 06 and 07 now say so.
• Home values on the address-check map: since 29 September 2026, the map at safe-route.app/check/ has had a home-values (Prices) layer, which fetches data files whose names show which squares of the map you view, and after each lookup the page fetches the home-values file for the square that holds the place you looked up. Section 03 did not say so until today.
• Our App Store screenshot: our update of 30 September 2026 said that a picture of the app's About screen on our home page showed two of the app's wrong texts (see "The app's own screens" above), but not that the last of the iPhone screenshots on our App Store page, a picture of the same screen, shows the same two: "your location is never sent anywhere", under Area heads-up, and "No personal data, location, or searches — ever", under the analytics switch. Apple lets us change screenshots only with a new version, and we did not replace it with version 1.3.8. We will replace it no later than version 1.4. Update, 23 October 2026: version 1.4's screenshots replace it, from when version 1.4 is on the App Store; until then, the old screenshot is still shown there. Update, 30 October 2026: replaced on 23 October 2026, when version 1.4 reached the App Store.

Change, 4 October 2026. Dates in this note are in US Eastern time. From today, we delete a shared walk about 30 minutes after sharing stops, and never later than about 4 hours 15 minutes after its link was made. Until today, if sharing stopped between 4 hours and 4 hours 15 minutes after the link was made, we kept the walk for 30 minutes after that, up to about 4 hours 45 minutes in all, as section 08 said; where this section says that a link lasts up to about 4 hours 45 minutes, that was true until today, and where it says that a link keeps working for about 30 minutes after sharing stops, it now does so for at most about 30 minutes. From 4 hours after the link was made, our backend now acknowledges the positions the app sends without keeping them, and the page says that the link is closing, where it used to say that the walk had not updated. When sharing stops, the page now says "Sharing ended" and "The walker ended navigation or stopped sharing". It can also say "Arrived", with how long ago the walker reached the destination, but only if the app reports an arrival, which no released version does (section 03). Update, 23 October 2026: version 1.4 reports arrivals (section 03).

Change, 18 October 2026. Dates in this note are in US Eastern time. Since 17 October 2026, the page that shows a walk you share has drawn its map with the Leaflet library, which our backend serves, from map images that the viewer's browser downloads from Mapbox, instead of with Mapbox's own map library, which the page loaded from Mapbox. The viewer's browser now runs no code from Mapbox, sends Mapbox no usage events, and stores nothing for the page beyond its ordinary cache of the Leaflet files and map images. Mapbox still receives requests for the map images of the area around the walk and of any other area the viewer moves the map to, with the viewer's IP address and browser details and our backend's web address as the site making the request; the page asks for them without a referrer and without cookies, so the link's code is not sent to Mapbox. Until 17 October 2026, as this policy said from 30 September 2026, each time the page loaded, Mapbox's map library sent Mapbox (events.mapbox.com) two usage events, style.load and map.load, and at most once a day a third, appUserTurnstile; the last two carried the library's version and a random identifier that the library kept in the browser's local storage, with a note of when it last reported, and the library also kept a cache of map data in the browser. Until 30 September 2026 it also sent performance measurements with each view, including the browser's screen and window size, connection type, graphics hardware and load timings for the map's files. A browser that opened a link to a shared walk before 17 October 2026 keeps that identifier, note and cache until its data for the site is cleared, although Safari may remove them sooner, after 7 days without interaction with the site; the page no longer reads them or sends them anywhere. A page already open before 17 October 2026 kept Mapbox's map library until it was reloaded or closed. Where this section says that the page's map library keeps a random identifier in the browser of anyone who opens a link (see the correction of 30 September 2026 above), that was true until 17 October 2026. Sections 03, 04, 05, 06, 07 and 08 now say so. We made these changes on 17 October 2026 and published this note on 18 October 2026. Until then, this policy still said that the page used Mapbox's map library, section 05 said that the page had not been assessed in writing, and the correction of 29 September 2026 above said that the nearby-help lookup had no rate limit.

Correction, 18 October 2026. Dates in this correction are in US Eastern time. Backend cache: since this policy was first published on 6 May 2026, it has said that place-of-interest data is cached for up to 24 hours. Until 17 October 2026, each map square of that data stayed in our server's memory until the server restarted or a lookup more than 24 hours after it was fetched replaced it with fresh data; when that fresh fetch failed, we kept using the old data, whatever its age. Since 17 October 2026, no square is kept more than 24 hours after it was fetched, so what section 08 says is now true.

Change, 23 October 2026. Dates in this note are in US Eastern time. Version 1.4 of the app changes what it sends and when. We publish this note before version 1.4 is on the App Store. Sections 02, 03, 05, 06, 08 and 09 describe each change, and say what versions before 1.4, which keep working as before until they are updated, still do:

• Arrival: when the app detects that you have reached the destination of the navigation you are on, it tells our backend, and sharing stops; the page says "Arrived". If the arrival does not get through, the app keeps the link's code and secret, and the time you arrived, on your phone, and sends the arrival again each time you bring SafeRoute to the foreground, for up to about 5 hours after you arrived; it deletes them once our backend confirms or rejects the arrival, or the first time you open SafeRoute after those 5 hours.
• Find Help: choosing Go on a place while you share a walk keeps sharing, and points the same link at that place: our backend receives its name and location and, with Live location, the route to it and the estimated walking time, and the page says that you are heading there. Because Find Help lists places near you, the place shows roughly where you are, even with Route only. The app then starts navigating to the place straight away, if it finds a route (after Go on Apple Watch, once you open SafeRoute, within about 10 minutes).
• Find Help on Apple Watch: when you open it, the iPhone app looks for places near where you are, using a position from the last minute or a new one, instead of near the last position recorded during a navigation (section 03).
• The 4-hour limit: the app stops sharing a walk 4 hours after you made its link, and tells you if you are navigating. It also stops sending positions when our backend answers that it no longer has the link, or that sharing has already stopped, instead of trying again with every position, and tells you if you are navigating.
• Street cameras: in the app, the point sent to list nearby cameras is rounded to about 1 km on your phone, and an open NYC DOT camera picture refreshes about every 15 seconds, not every 6 (sections 05 and 06).
• Stopping on Apple Watch: Stop sharing appears among the watch's safety options whenever you are sharing, not only while you navigate.
• Mapbox telemetry: the app no longer switches Mapbox's own telemetry off each time it starts. Version 1.4 switches it off once, the first time it starts, including after an update; after that you can turn it on or off with About → Mapbox map data or in a map's ⓘ menu, where it stays as you set it; your consent therefore lasts until you withdraw it. The app no longer shows Mapbox's Report button or "Rate your trip" screen.
• Usage analytics: the switch is called Usage analytics, and turning it off also stops TelemetryDeck's software from recording signals of its own. The app also records that a walk reached its destination and that it asked iOS to show Apple's rating request, which iOS may do after your second and later arrivals; neither carries a value of its own, so nothing about where the walk went or about a shared link. It records the uses of the school and home-value layers that section 03 lists and, when routes have no crime data, which kind of reason our backend gave. When you leave the route results, it now records whether you started a walk while they were open. Correction: in versions before 1.4, it recorded whether a walk was under way when you left them, not, as section 03 said, whether you started navigation from them. The app now checks each of its own signals against a fixed list of names and values before recording it.
• Schools and home values: the app contains official school and home-value data and shows it on the Nearby map, under an area's report and in About. Showing it sends nothing; our analytics record only the kinds of use listed in section 03, never which school or area; and a link to a school's own record or report includes its official ID (section 03). The app keeps only whether the Schools layer is on (section 08).
• Nearby places on your phone: with the latest list of nearby places it found, the app also keeps the point it looked from and when, and shows a list only near where you are (section 08).
• Street Feel: version 1.4 does not ask it (see above).

Update, 30 October 2026: version 1.4 was on the App Store from 23 October 2026 until version 1.4.1 replaced it there on 29 October 2026 (see the change of 30 October 2026 below), so this note and the updates of 23 October 2026 above that call it not yet on the App Store now describe a released version.

Correction, 23 October 2026. Dates in this correction are in US Eastern time. Some of what this policy said about the app was wrong or incomplete:

• Apple Watch: since this policy was first published on 6 May 2026, section 03 has said that if you use the SafeRoute Apple Watch companion, "the watch reads device motion data on-device only, to detect off-route deviations", and section 05 has listed "Motion sensor (on-device only)" as the data used for "Off-route detection on the watch". That was wrong. No version of the watch companion has read motion data, or any other sensor data, and the check for leaving your route does not use them: your iPhone checks whether you have left the route you chose, by comparing the position it already uses for navigation with that route, and tells you so on your iPhone and on Apple Watch. The check sends nothing to our servers. Sections 03 and 05 now say so.
• Find Help on Apple Watch: since this policy was first published on 6 May 2026, it has not said that opening Find Help on Apple Watch sends a location to our backend, and since 29 September 2026 section 03 has said that three features can send your location to our backend without you opening the app. There is a fourth: when you open Find Help on Apple Watch, the iPhone app looks for places near you, even while SafeRoute is not open on your iPhone, and sends our backend a location to do so. Versions before 1.4 send the last position recorded during a navigation since SafeRoute last started, if there is one. Section 03 now describes this, and what version 1.4 sends instead.
• Finding help nearby: since this policy was first published on 6 May 2026, section 05 has not given a purpose or lawful basis for looking up places near you that can help, in Find Help on your phone or on Apple Watch, or on the Nearby tab. Section 05 now does: we rely on performance of a contract.
• What our analytics record: since 6 June 2026, when we added TelemetryDeck to this policy, section 03 has given only examples of the events the app's analytics record, and has not said that they also record when you open Find Help, or confirm a call to the emergency number, during navigation; when the app gives you an Area heads-up or Fresh incident nearby alert, and when you choose Quiet for today on one; and when the app offers you alerts, whether you turn them on or choose Not now, and when you open Settings from the notice that alerts cannot reach you, or can reach you only while the app is open. Like every signal the app records, these carry the pseudonymous identifier and the time the app recorded them, to the second (section 03). Since 18 September 2026, sections 03 and 05 have also called the values these signals carry bucketed, but some are exact counts: how many routes or search results were returned, how many incidents are in a part of the heatmap you tap, and how many times the app had offered alerts. Since 4 October 2026, section 03 has also said that the app's analytics record why alerts could not work, "notifications or location off". They give location as the reason whenever Area heads-up is on and location access is not set to Always, including when it is set to While Using, unless notifications are off, and the app then tells you that alerts work only while it is open, not that they cannot work. Since that date, section 03 has also said that TelemetryDeck's software adds the date the app was first used; it adds the date it first recorded a session, which it sets again after more than 90 days without one, so that date can be later. Section 03 now names these events, gives that reason and that date as they are recorded, and says that some values are exact counts; section 05 no longer calls the values bucketed. Since 6 June 2026, this policy has also not said that TelemetryDeck's software adds to each signal the time the signal was recorded, to the second, and a random identifier for the session. Since 4 October 2026, section 03 has given the time of each signal only as the date and hour, and our correction of 4 October 2026 above, which said that section 03 now lists the details TelemetryDeck's software adds to every signal, did not mention either. Sections 03, 05 and 06 now say so.
• On-device data: since this policy was first published on 6 May 2026, section 08 has said that your iPhone and Apple Watch keep cached map tiles and route history. Your Apple Watch keeps neither: it shows no map, and keeps only the latest navigation status your iPhone sent it. Your iPhone keeps Mapbox's cache of map data, but no history of your routes, and section 08 did not mention several records of places it does keep, among them your recent place searches and your home place, the areas you looked up on the Nearby tab, the last location the app recorded, and, if you turn on Area heads-up, which zones have given you an alert, and when, which shows roughly where you were at those times. Nor did it mention the signals TelemetryDeck's software has not yet sent, or its record of your sessions. Section 08 now lists them.

Change, 30 October 2026. Dates in this note are in US Eastern time. Version 1.4.1 of the app changes the Nearby tab and fixes faults; it collects nothing new and sends nothing to anyone new. We should have published this note before version 1.4.1 was on the App Store, and did not: it has been on the App Store since about 5:09 pm US Eastern time on 29 October 2026, and we published this note on 30 October 2026, the day after it was released. Until then, this policy described the app only as far as version 1.4: in sections 02 and 03, it still referred to the Nearby tab's home-values card, its home-value figures and its Show schools here and Show home values on the map buttons, which version 1.4.1 does not have, and it did not say what version 1.4.1's analytics record when you use its new buttons, or when version 1.4.1 sends Apple Watch its navigation status. Sections 02 and 03 now describe the change to the Nearby tab, and say what version 1.4, which keeps working as before until it is updated, still does:

• Schools and home values on the Nearby tab: the Show schools here button, the Home prices near here or Home values near here card and its Show home values on the map button are gone. Instead, the tab's map has a Schools button, a Home values button or both, each where that layer has data, which open the full-screen map on that layer; Home values also opens the details of the area the app has already looked up, which it finds in its built-in data, sending nothing. The Nearby tab shows no home-value figures. Our analytics record both buttons as they recorded Show schools here, with the layer switched on, so the value for Show home values on the map is no longer sent, and opening the area this way records nothing (section 03).
• Apple Watch: if you install the SafeRoute Apple Watch companion while the app is open on your iPhone, your iPhone now sends it the navigation status it sends any Apple Watch, without the app being reopened; earlier versions sent it nothing more until you reopened the app on your iPhone. Your iPhone also sends it that status more often, every 5 seconds instead of 10 while SafeRoute is running on your iPhone, and whenever the companion asks for it, which it now does when it opens, when your iPhone comes back in range, and during a walk when it has heard nothing for a few seconds. Nothing new is sent, and it goes only to your Apple Watch.

Change, 31 October 2026. Dates in this note are in US Eastern time. Version 1.4.2 of the app changes where the large Home Screen widget's map comes from, and fixes faults, one of them in navigation. We publish this note before version 1.4.2 is on the App Store; the change takes effect with version 1.4.2. Sections 03, 05, 06, 07 and 08 describe it, and say what earlier versions, which keep working as before until they are updated, still do:

• The widget's map: the large Home Screen widget's map is now a picture that Mapbox draws, in the app's own map style, so that roads and place names show over the crime shading; earlier versions ask Apple's map services for it. When the widget has no picture of the same map from the last 12 hours, it sends Mapbox, with your device's IP address, the centre of the picture, rounded to about 100 m, a point a fixed distance east of the centre of the area it shows (that centre is rounded to about 100 m too: it is the point the widget sends our backend), so that the area sits toward the left of the picture; the zoom; the crime cells drawn on the map; and the app's Mapbox access token, which is the same for every install, but no identifier of your device. It keeps its latest two pictures on your iPhone (section 08). The other sizes of the widget show no map and, from version 1.4.2, ask for none; earlier versions ask Apple's map services for a map at every size, although only the large widget shows one. Mapbox already receives the areas of map you view in the app (section 03); for the widget's map it takes the place of Apple.
• Navigation in the background: during a walk, iOS can disconnect the app's window (its "scene") while the app is in the background, for example with your phone in your pocket, and reconnect it when you return to the app. In earlier versions, when that happens, turn-by-turn guidance stops until you open SafeRoute again: there are no spoken directions, a walk you share with Live location receives no positions, and the app cannot tell that you have arrived. When you then open it, the app asks Mapbox for your route again, our analytics record again which route navigation followed and, if you chose Go in Find Help while sharing with Live location, the app sends our backend the route to that place again, which also makes the page wait longer before it says you are later than expected. From version 1.4.2, guidance keeps running until the walk ends: while you walk, the app sends what section 03 already describes for a walk, and it asks Mapbox for the route, records which route navigation followed and sends the route to a Find Help place once per walk. Nothing new is collected or sent, and no other part of this policy changes for it.

Change, 31 October 2026: Find Help and street lighting. Dates in this note are in US Eastern time. The places that Find Help and the Nearby tab list, and the street-lighting figures on route results, come from OpenStreetMap data that our server asks Overpass servers for (section 06). The public Overpass servers we use now often refuse our server's requests or answer too slowly: since 29 October 2026 at the latest, our server has almost never been able to fetch street-lighting data, so route results almost always show no street-lighting figures, and Find Help often cannot load places where our server has not fetched them in the last 24 hours. Until we build this data ourselves, our server will ask overpass.ch, a keyed Overpass service, first. This note describes the server update that makes these changes. None of it is in effect yet: we publish this note before that update is made, and before our server sends anything to overpass.ch. Our server will start asking overpass.ch no earlier than the update, and perhaps later; we will add to this note the date of each when it happens. Sections 05, 06, 07 and 08 describe the changes:

• overpass.ch: a new recipient, run by Chavdar Dutsov, in Switzerland, with its servers in the EU. From the day our server starts asking it, it receives the same as the public Overpass servers: for nearby help, the fixed map squares, about 2 km across, around the point looked up, and for street lighting, a box around the candidate routes, widened by about 300 m. Our server sends these without your IP address and with its own key for overpass.ch, which identifies our account, not you or your device (section 06). If overpass.ch cannot answer in time, refuses our server's requests, or has paused them because our monthly allowance is used up, our server asks the public Overpass servers instead, one at a time. Section 07 now names Switzerland, and what transfers there rely on.
• One server at a time: from the update, our server asks the Overpass servers for street lighting one at a time, in turn, as it already does for nearby help. Until the update, it sends each street-lighting box to all three public servers at once.
• Street-lighting cache: from the update, each entry is deleted from our server's memory within about 24 hours of being fetched, instead of up to about 25 hours (see the correction below, and section 08).
• Squares that could not be fetched: from the update, when a map square for nearby help cannot be fetched, our server notes that square, in memory. For 2 minutes, a lookup that needs that square, such as Try again, gets the error at once, instead of waiting while our server asks the servers again; the note is deleted within about 3 minutes (section 08).

Update, 1 November 2026: this note said that our server would ask overpass.ch first “until we build this data ourselves”. We now build it, each week (see our change of 1 November 2026 below), but our copy does not answer everywhere, so building it does not end our use of overpass.ch. Until the server update that change describes, this note applies everywhere. From that update, it applies only to map squares and route boxes outside our covered regions (section 03, "Places that can help, and street lighting"), for which our server will ask overpass.ch first, as this note says, with no end date set; inside our covered regions, our server asks neither overpass.ch nor the public Overpass servers, except in the cases section 03 describes.

Update, 1 November 2026: the server update this note describes was made on 1 November 2026, at about 15:15, together with the one in our change of 1 November 2026 below; our server has not yet asked overpass.ch.

Correction, 4 November 2026: our update of 1 November 2026 just above said that the server update this note describes, and the one in our change of 1 November 2026 below, were made at about 15:15. They were made at about 14:15 (19:15 UTC): the clocks went back an hour at 2:00 that morning, at the end of US daylight time, and we gave the time as if they had not.

Update, 4 November 2026: our server has still not asked overpass.ch. It starts asking it on 4 November 2026, no earlier than we publish this update, and we will add to this note the time from which it does. From then, it asks overpass.ch first, ahead of the public Overpass servers, as this note says, but only for what still goes to the Overpass servers after the server update of 1 November 2026 that switched on our own copy (see our change of that date below): map squares and route boxes outside our covered regions that our copy does not answer, and those inside them only in the cases section 03 describes ("Places that can help, and street lighting"). Three passages change with this update. Section 06 now says that overpass.ch says its servers are in Finland: when we checked on 31 October 2026, it said Germany, as section 06 said until this update; on that day and on 4 November 2026, api.overpass.ch resolved to the same address, in Hetzner's Helsinki data centre, in Finland. Once our server asks overpass.ch, if overpass.ch turns a map square for nearby help away only because it is busy, our server uses its note of that square ("Squares that could not be fetched" above) only until it would ask overpass.ch again, if that is sooner than 2 minutes, so section 08 now says that it uses the note for up to 2 minutes. And because our server had sent overpass.ch no requests before that server update of 1 November 2026, there are no records of earlier requests for overpass.ch to keep, so section 08 no longer mentions them.

Update, 4 November 2026: the server update that gives our server its key for overpass.ch was made on 4 November 2026, at about 06:40 (11:40 UTC); since then, our server has asked overpass.ch first, as this note says.

Correction, 31 October 2026. Dates in this correction are in US Eastern time. Some of what this policy said about our OpenStreetMap lookups, and about how long our server keeps what it caches, was wrong or incomplete:

• Kumi Systems: since 29 September 2026, section 06 has named Kumi Systems as one of the operators of the Overpass servers our server asks. The service at overpass.kumi.systems has been run since July 2024 by Private.coffee, an association in Graz, Austria: that address is another name for Private.coffee's own, overpass.private.coffee. When we checked on 31 October 2026, that server was in Austria, as sections 06 and 07 said; section 06 now names Private.coffee.
• Street lighting: since June 2026, our server has worked out how much of each candidate route runs along streets marked as lit, from OpenStreetMap data, and since 14 June 2026 section 06 has named street lighting as a purpose of our Overpass lookups. But section 05 has never given a purpose or lawful basis for it, and section 03 did not list it among the reasons coordinates are sent to our backend. Sections 03 and 05 now do; for section 05, we rely on performance of a contract.
• The Nearby tab: since 6 June 2026, section 06 has given the purpose of our Overpass lookups as nearby safe-place lookups for Find Help. The places on the Nearby tab come from the same lookup (section 05, since our correction of 23 October 2026); section 06 now names it.
• Cache times: since this policy was first published on 6 May 2026, it has said that crime data is cached for up to 24 hours. Since 29 September 2026, section 08 has also said that area summaries are cached for up to 24 hours, search results and place names for up to 30 minutes, and which UK police force covers an area for up to 7 days. Since 30 September 2026, section 03 has said that our cache of crime data keeps a box for up to a day, and section 08, and our correction of that date (which said this had been so since 11 June 2026), that street-lighting data is cached for up to 24 hours. Our server has never used an entry for longer than that. But it deletes an expired entry only when the same entry is next looked up, or at its next clean-up, which runs every hour for the caches kept for 24 hours or 7 days and every 5 minutes for search results and place names. So an entry can stay in memory for up to about 25 hours, about 35 minutes, or 7 days and about an hour. Sections 03 and 08 now say so. From the server update described above, street-lighting entries are deleted within about 24 hours; it does not change the other caches.

Change, 1 November 2026: our own copy of OpenStreetMap data. Dates in this note are in US Eastern time. We now build, each week, our own copy of the OpenStreetMap data that Find Help, the Nearby tab and the street-lighting figures on route results use, and publish it under the Open Database License at github.com/minhajk21/saferoute-osm-data. This note describes the server update that switches it on. None of the server changes below is in effect yet: we publish this note before that update, which we will make no earlier than 1 November 2026, and we will add to this note the date it is made. The update can be made at the same time as the server update in our change of 31 October 2026 on Find Help and street lighting, or after it; until it is made, what that change describes applies everywhere. Sections 03 ("Places that can help, and street lighting"), 05, 06, 07 and 08 describe the change:

• Inside our covered regions (Great Britain, Northern Ireland, the Isle of Man and the Channel Islands, and, around each city we cover in the United States, Canada and Mexico, the rectangle our server uses for that city's crime data; section 03): our server answers Find Help, the Nearby tab and street lighting from its own copy, and sends no map square and no route box from them to overpass.ch or to the public Overpass servers, even while it cannot use the copy, except in the cases section 03 describes. A lookup there that needs a square the copy cannot answer then fails, as one does now when the Overpass servers cannot answer: from version 1.4, Find Help says that it could not load places, and so does the Nearby tab if it has no places for that area yet; earlier versions can say instead that they found no 24-hour places nearby. Route results show no street-lighting figures (section 03).
• Outside them: our server answers from its copy where the copy holds the data, and otherwise asks the Overpass servers as before (section 06). A Find Help or Nearby tab lookup made near the edge of a covered region can need a square just outside it that the copy does not hold, such as open sea; that square goes to the Overpass servers (section 03).
• No new recipient: the copy holds nothing about you or your lookups. Geofabrik, whose OpenStreetMap extracts it is built from, and GitHub, which builds and hosts it, receive nothing about you: our server downloads the copy from GitHub when our server is updated or restarts, again if that download fails, or to replace a damaged copy, never for a lookup.
• Shorter caching: for the lookups our copy answers, our server holds what it has read from the copy in memory for up to 1 hour, keyed by fixed map squares about 2 km across, and keeps nothing by route box. Squares and boxes it fetches from the Overpass servers are still cached for up to 24 hours, as before (section 08).
• How up to date: the copy is usually between about 1 and 8 days old, older if a weekly update fails, and is never used once its data is more than 30 days old, so a place's 24-hour opening details can be about a week out of date, or more (section 03).
• When lookups in our covered regions can still go to the Overpass servers: our server can be set, or taken back to a version from before this update, so that lookups in our covered regions go to the Overpass servers again, and lookups there that our copy cannot answer go to them too if our server cannot read its own list of the squares in our covered regions (section 03). We will set our server, or take it back, in this way only if our copy turns out to be faulty. If, after the update, our server asks the Overpass servers for a map square or route box inside our covered regions, for any reason, we will add the dates to this note.

Update, 1 November 2026: the server update this note describes was made on 1 November 2026, at about 15:15.

Correction, 4 November 2026: our update of 1 November 2026 just above said that this server update was made at about 15:15. It was made at about 14:15 (19:15 UTC): the clocks went back an hour at 2:00 that morning, at the end of US daylight time, and we gave the time as if they had not.

The current version of this policy is always available at this URL.

14Contact

For privacy questions, data subject rights requests, or anything else covered by this policy:

Minhaj Khan
Email: minhaj@safe-route.app