Privacy Policy

Who we are

near & here. society is a federally incorporated not-for-profit organization (under the Canada Not-for-profit Corporations Act), based in Toronto, Ontario, Canada. We build and operate near & here. (bundle identifier com.nearandhere.app), a free app that helps people find nearby places, transit, events, and community services around Toronto. The same app also runs in a web browser, at map.nearandhere.ca; this policy calls that the web version.

This policy describes how the near & here. app — on your phone, or as the web version in your browser — and our website at nearandhere.ca collect, use, disclose, and protect information. It covers the app, its web version and that website — including its support page, where you can send us a message — but not any other website, such as the ones the app links to. Everything it says about the app applies to the web version too, except where it says otherwise, and the differences are gathered under The web version. Our Terms of Use cover everything else about using the app, and the two documents go together. Questions, requests, or concerns about this policy can be sent to hi@nearandhere.ca at any time.

Information we collect, and why

Location

We ask for your location so the app can centre the map on you, find places and transit near you, and give you directions.

Showing you on the map happens entirely on your device. Directions do not. When you ask for a route from where you are, your coordinates are sent to our own routing server at nearandhere.ca, which calculates the route and returns it. Those coordinates are used to answer that one request and are never written to disk — our routing server keeps no request log at all. If you stray more than about 100 metres from a walking, cycling or driving route while you're following it, the app sends where you are to our routing server again, in the same way, to work out a new route from there. Cycling and driving directions also ask our data server for the bike racks or car parks around where you're going, to find one near the end of the route; it keeps no record of that either, unless the request fails. The search boxes are similar. As you type, what you've typed so far goes to our own geocoding service, to look for matching addresses, and is not retained there either; it also goes to our own data server, to look for matching listings by name or address, which keeps no record of it — unless the request fails, in which case it may be logged, as described under Where information is stored and processed.

The map asks our server for an area, not for your position. The listings on the map come from our own data server: as you move the map, the app asks it for those in the area on screen, plus a margin around it, with the edges rounded outward to a fixed grid. The area is wherever the map is looking — but when the map moves to show where you are, it is looking at you, so that request tells our server roughly where you are, and more closely the further you zoom in. It moves there when you tap the button that shows where you are, and, in versions after 1.1.1, as soon as the app opens, if you've already let it use your location.

Near You rounds your position first. On the Events, Drop-Ins, Programs, Eats and Sips pages, a Near You section lists what's close by. Before it asks our server for anything, your position is rounded to the middle of a grid square about 450 metres across, and the search is made around that point, never around you. The distances and the order you see are then worked out on your device, from your real position — so the handful of listings the section goes on to load are the ones nearest you, which our server could use to narrow down where in that square you are. If you've already let the app use your location, this happens as soon as you open one of those pages; if you haven't, the section offers to ask, and asks only if you tap it. For the map and Near You alike, our data server uses the area only to answer that request and keeps no record of it — unless the request fails, in which case it may be logged, as described under Where information is stored and processed.

A pin you drop is sent exactly where it is. When you press and hold on the map to drop a pin, the app sends that point to three of our own services: our geocoding service, to find its address; our data server, to list what's nearby; and our Street View service, to find a street-level photo of it. The same goes for a spot you open from a link, an address you pick from search results, a pin you've saved, and any of My Locations that is an address rather than a listing — except that the address isn't looked up again when the app already knows it. None of these requests includes your own position, but a pin is wherever you put it: one dropped where you're standing, or on your home, tells our servers that place as precisely as your position would. Our geocoding service keeps no record of the point, and neither does our data server unless the request fails; our Street View service does note it in a log. Both logs are described under Where information is stored and processed.

During active turn-by-turn navigation, the app keeps your screen on. What happens if you lock it, or switch to another app, depends on your phone. On Android, navigation carries on: the app keeps using your location while your screen is locked, so directions keep working, and Android shows an ongoing notification while it runs, unless you have turned the app's notifications off. On iOS, it does not: the app stops receiving your location once it is no longer on screen, and guidance picks up again from wherever you are when you come back to it. Neither needs the "Always" location permission, and the app never asks for it — "while using the app" is enough. In the web version, navigation is offered only on a phone or tablet, and it pauses as soon as the page is no longer on screen, until you come back and resume it. Outside of an active navigation session, the app only ever uses location while you have it open in the foreground.

Your coordinates are never included in analytics events. If the app finds that your device is outside the area it covers, analytics records only that fact (e.g. "outside service area") — never the coordinates themselves. The same goes for the app's offer to pass on a request for somewhere we don't cover yet: analytics records only what prompted it — your own position being outside the area, a pin you dropped outside it, or the first-run screens — never the place. Separately, and only if you have turned analytics on, our analytics server records the rough country, region and city your IP address resolves to; that is described under Usage analytics below and never involves your device's location.

Usage analytics — off by default

The app can optionally tell us how it gets used, so that we can see what works and fix what doesn't:

• What gets opened — which screens, which listings and how long they stay open, which sections of a list come into view and how far down it someone scrolls, and panels such as Nearby and Near You
• What gets tapped — categories and filters, the map's modes and base map and how far it is zoomed in, a listing's buttons (calling, its website, directions, saving, sharing), and a pin dropped on the map, recorded only as "a dropped pin"
• How searches and routes go — roughly how many results a search found and which one was picked, never what was typed; for a route, the way of travelling, whether it was finished or stopped, and roughly how far along
• The rest of the app — Passport stamps earned, notices read, notifications opened and notification settings changed, the categories chosen during setup, the app's offer to pass on a request for somewhere new, your answers when the app asks about location, notifications or analytics, and your answers to occasional short feedback prompts (a rating or a multiple-choice answer — never anything you type)
• How well it works — how long things take to load, screens that came up empty or failed to load, and which errors happen

Each of these arrives with the app's version, your platform, the major version of its operating system (e.g. "iOS 18"), and your device's language setting. From the web version, it arrives instead with the app's version, the fact that it's the web version, the kind of operating system your browser runs on (e.g. "Windows"), whether that's a computer or a mobile device, and your browser's language setting — never which browser it is, or the version of either. This is opt-in and off until you say yes, in the same onboarding step where we explain it — or, in the web version, in a pop-up that explains it the first time you visit — and you can turn it off again at any time in Profile → Settings, with immediate effect.

This is enforced in the app's code, not just its settings screen: no analytics event of any kind can be created or sent while consent is off, and every event that is sent has the following stripped out first, before it ever leaves your device:

• Your location, or anything that could reconstruct it (coordinates, postal codes, neighbourhood names)
• Anything you type
• Your name or email address
• Whether you viewed a sensitive category of content — health, faith and religious services, 2SLGBTQ+ services, and similar support services are specifically excluded before an event is ever created, regardless of your consent setting

We run this analytics ourselves, on our own server in Toronto, using an open-source, self-hosted tool called Umami — not Google Analytics, and not any advertising or marketing platform. See How long we keep information for how long this data lasts.

How events are grouped into a session. So we can tell "one person opened the app and looked at four things" apart from four unrelated events, each event carries a random number your device makes up when the app starts. It exists only in the app's memory, is never written to your device's storage, is different every time you open the app, and is gone when you close it. It is not derived from your IP address, your device, or anything about you, and it cannot connect one session to the next: two visits from the same phone are, to us, two unrelated visits. In the web version, the app starts afresh every time the page loads, so reloading it starts a new session too.

One thing is added on our side, rather than sent from your device: a rough location. Every connection to any web server reveals an IP address, and our analytics server looks that address up in a local database to record the country, the province or state, and, where the lookup can tell, the city — for example "Canada, Ontario, Toronto". Your IP address itself is not stored, no coordinate from your device is involved, and the result is city-level at best: it is the same approximate location that any website can infer from a visit. We record it so we can tell how much of the app's use comes from people living in Toronto rather than visiting it, which is the question that decides what we build next. It is kept with the rest of the analytics for the same 400 days and deleted with them. With analytics off, none of this is recorded at all — no event is created, so there is no session for a location to be attached to.

Crash and error reports — same on/off switch as analytics

If something goes wrong, the app can optionally tell us what type of error occurred and roughly where in the app it happened, so we can fix it. This runs through the same consent-gated pipeline as analytics above (same redaction, same on/off switch) rather than a third-party crash-reporting SDK — deliberately, so that no persistent device identifier or full request details are collected the way a service like Crashlytics or Sentry would by default. Separately, Apple and Google give app developers crash reports from phones whose owners have allowed it in their device settings (on iPhone, "Share With App Developers"; on Android, sharing usage and diagnostics), so if this app crashes on such a phone, a report of it can reach us that way too, under Apple's or Google's privacy policy. Those reports come from your phone's own system, not from the app.

Information stored on your device

The following is kept on your device, never on our servers. Where using any of it involves our servers or analytics, the item says so:

• Search history — the results you've picked from past searches. The searches themselves are sent to our servers as you type, as described under Location above.
• My Locations — the Home, Work and School places you set, with their addresses and positions. Opening one that's an address, rather than a listing, sends its point to our servers the way dropping a pin does, as described under Location above; asking for directions to or from any of them sends it as part of that route.
• Pins you've saved — the spots you dropped a pin on and saved, with their addresses. Opening one sends its point to our servers the way dropping a pin does, as described under Location above; so does asking for directions to it, as part of the route.
• Your Passport — the app's record of how you've used it, which its stamps are counted from: every listing you've opened; the categories, neighbourhoods and map modes you've tried; counts such as how often you've opened the app, searched or dropped a pin, and how far you've travelled with directions; the seasons, weather and times of day you've used it in; the stamps you've earned and when; and an optional name you can give it. If usage analytics are switched on, earning a stamp is recorded like any other tap — which stamp it was, never the record behind it.
• Which in-app notices you've read — see In-app notices and announcements below
• When you've opened the app, and which notifications it has sent you, so that it can space them out — though not in the web version, which sends no notifications
• Your settings — which categories you show or hide, your answers to the app's questions, and the like
• Copies of what the app has loaded — photos, map files and other data, kept so they aren't fetched again: some for up to 60 days, and some until a newer copy replaces them. Clear cache in Profile → Settings empties the photos and map files. In the web version, photos are held by your browser's own cache instead, for as long as the server each one came from allows, and only your browser can clear them.

All of it lives in the app's own storage on your device. On Android, it's specifically excluded from automatic cloud backup and — in versions after 1.1.1 — from phone-to-phone transfer too, so it stays only on the device that created it; with version 1.1.1 and earlier, Android's tool for moving to a new phone can still copy it across. On iPhone, like most apps' data, it's part of your iCloud or computer backups, so a backup or a move to a new iPhone carries it with you. Those backups are yours, kept by Apple or on your own computer, and we can't see them. Uninstalling the app — or, on Android, clearing its storage from your device's settings — permanently deletes all of it from the device. In the web version, it lives in your browser's own storage for our site instead (its local storage and IndexedDB), so it stays with that browser: it isn't shared with the app on your phone, or with another browser. Clearing our site's data in your browser's settings deletes all of it, and a private window deletes it by itself when you close it.

Saved listings are different. Your list of them is kept and deleted the same way, but it holds only which listings you saved and when, not the listings themselves. Their details — hours, dates, photos — change, so whenever the app shows or uses your saved places, it asks our own data server for the current details of every listing on the list: when you open your Saved page or start a search, when you choose where a route starts or ends, when you save or unsave something, and, if you've allowed notifications, each time the app opens, so that a reminder for a saved event goes off at the right time. That lookup tells our server which listings you've saved, though not when you saved them, and like any request it reveals your device's IP address. Our server uses it only to answer the lookup and keeps no record of it — unless the request fails, in which case it may be logged, as described under Where information is stored and processed.

What analytics sees of your saved places. If usage analytics are switched on, saving or unsaving a listing counts as ordinary app activity and is recorded the same way as any other tap — which listing it was, never who saved it. Opening a listing from your Saved page is recorded too, along with roughly how long ago you saved it (e.g. "1 to 7 days"), so we can tell whether people come back to what they save, and how long after. Saving or unsaving a pin you dropped on the map is recorded only as a dropped pin — never where it is. With analytics off, none of this is recorded at all.

Calendar

If you tap "Add to calendar" on an event, the app hands that event to your device's own calendar: your phone opens its usual screen for adding an event, already filled in, and nothing is added until you confirm it there. On Android, and on iOS 17 or later, that needs no permission at all. On iPhones with iOS 13 to 16, iOS first asks whether the app may access your calendar, because those versions have no permission that only lets an app add events; the app uses that access only to open the adding screen, and never reads what's in your calendar. If you say no, nothing is added. In the web version, "Add to calendar" downloads the event as a calendar file instead, and nothing is added unless you open that file in your calendar yourself. We don't see, store, or otherwise access your calendar.

Notifications

The app can send you notifications of its own, but only if you say yes: it asks you at most once, and they stay off until you agree. You can change your answer at any time in Profile → Settings → Notifications, which has a switch for each of three kinds:

• Event reminders — the evening before an event you saved (or on the day, if that's too late), and now and then a place you saved but haven't opened in a long time.
• What's on — a few times a month, never more than twice a week: what's on this weekend or today, somewhere to go on a fine Sunday afternoon, a new season, a tip about something in the app you haven't tried, and, if you stop opening the app, a note on the 5th, 16th and 50th day, after which it stops.
• Passport — when a stamp is within reach, or the light is right for one.

Every one of these is written and scheduled on your phone, from things the app already has — your saved places, your Passport, and the events and weather it loads for its own pages — and which ones you are sent is never reported to us. If usage analytics are switched on, opening a notification, changing these switches, and your answer when the app asks count as ordinary app activity and are recorded like any other tap. The web version sends no notifications at all, and never asks to.

The app also uses a local notification to show you're in an active turn-by-turn navigation session (on Android, so you know it's still running with your screen locked). We don't use push notifications at all — we cannot send a notification to your phone, for marketing or for anything else; every notification above is created by the app itself. The app has no push token, and we've deliberately kept it that way: a push token is a permanent identifier for your specific device, and we'd rather not have one.

In-app notices and announcements

The app has a notices area (the bell on the map) where we post occasional announcements, planned-maintenance warnings, and service-status updates. These appear only inside the app, when you open it.

Everyone gets the same list. We publish one set of notices and your device fetches it exactly as it fetches map content — anonymously, with nothing about you attached. We don't send your platform, your app version, your city, or any identifier with that request.

Some notices are meant for a subset of people — for example "Android only", or "only versions older than X". Those checks happen on your phone, not on our servers. Your device downloads the whole list and decides locally what applies to it. We deliberately built it this way rather than the usual approach of telling the server about your device and letting it choose, because that would mean sending us a per-request description of your device that we don't want and don't need.

Which notices you've read is stored on your device, not by us, and that record is never sent anywhere. There is no read receipt. We can see how many notices we've published; we cannot see who has read them.

If usage analytics are switched on, opening the notices area and reading a notice count as ordinary app activity and are recorded the same way as any other screen — which notice, and what type it was, never its contents alongside anything about you. With analytics off, nothing is recorded at all. This is the same single on/off switch described above.

Two related details, for completeness:

• If the app can't reach our data server, it explains that to you on the spot — that message is written by the app itself, on your device, and needs no network at all. It will also check a small status file on nearandhere.ca to see whether we've posted anything about the outage. That request reveals your IP address to our website host in the same way visiting any web page does, and it happens only when something is already failing — never during normal use.
• Very rarely, an update may be required. If a version of the app can no longer work correctly with our data, it will ask you to update before continuing. This is a functional safeguard, not a data-collection mechanism: the decision is made on your device by comparing your app's version number against a number we publish, and nothing about you is sent to us in the process.

Reports, support messages, and other things you send us

You can report a problem with a listing or a route, or send us a support message, from inside the app or from our website's support page. When you do, we receive the reason you pick, anything you choose to type, and — for a report about a specific place, event, stop, or station — which listing it was, along with basic technical context (the app version, your platform, and the major version of your operating system, e.g. "iOS 18"; from the web version, only the app version and that it's the web version). We use this only to find and fix the thing you're telling us about. From the web version, a report can be sent only once Cloudflare Turnstile has checked that it comes from a person rather than an automated program, as on our website's support page.

A report is not linked to your identity. We don't attach your name, your analytics session, any device identifier, or your location to it — so a report about a sensitive listing, such as a health or faith service, does not tell us who sent it. A report about a route records only its rough shape (the travel mode and a coarse duration and distance) — never your start point, your destination, or the path between them.

Asking us to cover somewhere new. If you point at a place outside the area we cover, the app offers to pass on a request for it. What we receive is the name of the city, town, or area — the one you tap, or the one you type — plus anything else you choose to add. We do not keep the point on the map you touched: to save you typing, the app asks our own geocoding service which municipality that point falls in — the same lookup it already makes whenever you drop a pin anywhere else — and the request we store records only the place name you confirmed before sending. Where you ask for is never attached to an analytics event, so it stays unconnected to anything else about your use of the app. We count these requests to decide where to go next.

Giving us your email is optional, separate, and only offered on our website's support page — the app itself never asks for or collects an email address for a report. On the website, you provide it only if you'd like a reply, and only alongside a clearly-unchecked box confirming we may contact you about that report; the form sends your email only once you've ticked it. When you do, it's stored apart from the report itself, used solely to reply to you about that report, and never for anything else — and you can have it deleted at any time by emailing hi@nearandhere.ca. We ask you not to include personal or sensitive information in the free-text part of a report.

If you email hi@nearandhere.ca directly instead, we receive whatever you choose to include in that message, and use it only to respond to you.

The web version

The web version, at map.nearandhere.ca, is the same app running in your browser, and everything in this policy applies to it, apart from the differences described here and in the sections they belong to. It sends no notifications, and it offers turn-by-turn navigation only on a phone or tablet. It is hosted by Cloudflare, which sees each visit the way any web host does, and it runs the same bot check as our website (see Our website). It sets no cookies of its own, and it loads nothing from Google: its fonts and the rest of its files come from our own site. What it remembers is kept in your browser, as described under Information stored on your device.

Your browser asks for your location. The first time the web version needs your location, it explains why, as the app does; then your browser asks you, and treats your answer the way it treats any site's, which you can change at any time in your browser's settings. Working out where you are is your browser's job: depending on the browser and your device, it may use a location service run by the company behind your browser or your operating system, under that company's own privacy terms.

Analytics are asked about in a pop-up. The web version has no first-run screens, so the first time you visit, it asks whether to turn on usage analytics in a pop-up, with the same explanation and the same two answers as the app. Your answer is kept in your browser, so another browser, a private window, or clearing our site's data means you'll be asked again; nothing is sent until you say yes.

The address in your browser shows what you have open. As you use the web version, the address bar follows along — a listing, a page, a neighbourhood, a pin you dropped, to within about a metre, and, once you move the map yourself, where it's looking — so that your browser's Back button, a bookmark, or a link you share can bring you back to it. Like any site's addresses, these can stay in your browser's history, and Cloudflare, which hosts the web version, sees one whenever your browser loads our site with it, such as when you open a link or reload the page. The address isn't sent with the web version's requests to other services, though Cloudflare's own scripts in our page — its bot check, and Turnstile when you send a report — can read it.

A few of the services under Who else may see limited information work a little differently in a browser — Cloudflare Turnstile checks a report before it's sent, the full-screen Street View is shown in a frame, and the City's traffic-camera images and satellite tiles, and TicketWeb's event artwork, are handled the way your browser handles any other site's images — and each is described there.

Our website

Our website, nearandhere.ca, has a few pages about the app, this policy and our Terms, and the support page. It has no accounts, no ads and no analytics, and it sets no cookies of its own. It is hosted by Cloudflare, which sees each visit the way any web host does, and which adds a small script to every page that checks, in your browser, whether the visitor is a person or an automated program; that check can leave Cloudflare's own short-lived security cookies behind, which Cloudflare uses for that purpose. On the support page, Cloudflare Turnstile makes a similar check before a message can be sent. What you send through the support page is covered under Reports, support messages, and other things you send us.

What we don't do

We do not, under any circumstance:

• Sell, rent, or otherwise disclose your personal information to any other company for their own marketing or commercial purposes
• Show ads, or share information with any advertising network or data broker
• Use advertising identifiers (like Apple's IDFA) or any cross-app/cross-site tracking technology
• Build an advertising or marketing profile of you
• Require an account to use the app

Our basis for processing information

Where your location and other information are needed to directly provide a feature you've asked for — showing the map, finding nearby content, giving directions — we process it because it's necessary to provide that specific feature, for the moment you're using it.

A small amount of information is kept in the app's own storage on your device because the feature you asked for cannot work without it — which notices you've already read, so we don't show you the same announcement twice, and your saved places and preferences. This is stored on your device, not by us, is never transmitted — apart from the lookups of your saved places described under Information stored on your device — and is not used to recognise or track you across apps, sites, or sessions.

Where information is not necessary for the app's core functioning — analytics and crash reports — we rely on your freely given, specific, informed consent, which you can withdraw at any time with immediate effect and no consequence to any other part of the app.

When you send us a report or support message, we process what you include in order to handle the request you've made. If you add a contact email on our website's support page, we use it to reply to you on the basis of the consent you give by ticking that box. And we process a small amount of technical information — such as the short-lived log of requests that fail — where it's necessary for our legitimate interest in keeping the service working, secure and free from automated abuse.

Who else may see limited information

We operate almost everything ourselves. A short, complete list of everyone else involved, and why:

• Cloudflare — sits in front of our own server for domain name service, encryption, and protection against automated abuse. Cloudflare may process connection-level information (like your IP address) as part of that role. On our website's report form, and for reports sent from the web version, we also use Cloudflare Turnstile, a privacy-preserving check that confirms a submission comes from a person rather than a bot, without tracking cookies or building an advertising profile. Cloudflare also hosts our website, nearandhere.ca, and the web version, map.nearandhere.ca, and runs its bot check on every page of both (see Our website and The web version); the website is also where the app looks for a service-status file if it cannot reach our data server — so in that situation Cloudflare sees that connection too. Governed by Cloudflare's own privacy policy.
• Oracle — our server and our file store run in Oracle Cloud Infrastructure's Toronto region (see Where information is stored and processed). Oracle provides the machines and the network they sit on, and processes what they hold only to run that service for us; we stay in control of it. Your device also downloads the map's files straight from that file store, which shows Oracle your device's IP address — and because the base map arrives in pieces, the pieces your device asks for show roughly which area you're looking at, the same way the City's satellite tiles do, as described below. Governed by Oracle's own services privacy policy.
• Google — stores the encrypted copies of our daily backup on Google Drive (see Where information is stored and processed). Our server encrypts them before uploading them, file names included, with a key only we hold, so Google can see that the files exist, how big they are and when they arrive, but not what is in them. Governed by Google's own privacy policy.
• Spaceship — hosts our email, through its Spacemail service. A message you send to hi@nearandhere.ca, and our reply — including a reply to an email address you left on our website's support form — are handled and stored by Spaceship, Inc., a company based in the United States, as any email provider does with the mail it carries. Governed by Spaceship's own privacy policy.
• ntfy.sh — a public notification service our server uses to alert our own phone. When a report, support message or request to cover a new area arrives, our server sends ntfy.sh a short notice saying which form it came from — a listing, a route, a support message, or a request to cover a new area — with its reference code: nothing you chose or wrote, no email address, and nothing about your device, since the notice comes from our server, not from you. Once an hour, while any "This photo is mine / wrong credit" reports are waiting for us, the same service also carries a count of them. By its own account, ntfy.sh keeps each notice for about 12 hours. Governed by ntfy.sh's own privacy policy.
• Mapillary — many photos in the app are Mapillary street-level imagery, and those are collected by our server and served to you from data.nearandhere.ca, so your device never contacts Mapillary to see them. The Street View panel works the other way round: our server asks Mapillary which photo is nearest — the coordinates in that request are those of the listing or pin you're looking at, not your own position — but the picture itself is then loaded directly from Mapillary's image servers by your device, and the full-screen view keeps loading from them as you look around. That exposes your device's IP address, and which street-level photo you asked for, to Mapillary — in the same way as any image on any web page. Mapillary is part of Meta, so those requests reach a Meta-operated service. They carry no account and nothing you have typed; the full-screen view's requests do carry our app's Mapillary access key, which tells Mapillary they come from this app, but nothing that identifies you. The full-screen view is a small web page shown inside the app, which could keep cookies the way a browser does, but Mapillary's servers set none when we checked. In the web version, the same page from our Street View service is shown in a frame, and your browser sends Mapillary none of its cookies with any of these requests.
• Open-Meteo and Environment and Climate Change Canada (ECCC) — the app's weather and air-quality readings are fetched from these two public services directly by your device. It asks each of them for the same thing, whoever and wherever you are: Open-Meteo for the weather at four fixed points across Toronto, and ECCC for the air-quality readings in one fixed area covering the city. It asks when the app starts, and again from time to time while you're using it — every 10 to 15 minutes while the weather on the map is on screen. Like any request on the open web, these reveal your device's IP address, but they say nothing about where you are or which part of the map you're looking at, and they carry no account, no identifier, and nothing you have typed. ECCC is the Government of Canada. Open-Meteo is run by OpenMeteo GmbH, a company in Switzerland, whose servers are in Europe and North America; we use the free service it offers for non-commercial use, and its terms say it keeps web-server logs, which can include IP addresses, for up to 90 days.
• Toronto Transit Commission (TTC) — live vehicle positions, arrival predictions and service alerts come from the TTC's public feeds, but your device fetches them from our own server, not from the TTC. Every 15 seconds our server copies each feed in full, and the app reads those copies, so the TTC sees one visitor — our server — however many people are using the app. The feeds cover the whole network, so fetching them tells neither the TTC nor us which stop or vehicle you are looking at. Version 1.1.1 of the app and earlier fetch the same feeds from the TTC directly, which reveals your device's IP address to the TTC, in the same way as loading any feed on the open web.
• Bike Share Toronto and the City of Toronto’s traffic cameras — these live feeds are fetched directly by your device. Bike Share dock availability comes from a public feed at toronto.publicbikesystem.net, run by Lyft Urban Solutions (formerly PBSC Urban Solutions, and part of Lyft) rather than by Bike Share Toronto itself; it covers every station at once, so fetching it doesn’t tell them which one you’re looking at. The RESCU traffic-camera images on the driving map come from the City’s own open-data server, which refreshes them about once a minute. These requests carry no account, no identifier, and nothing you have typed — but, like loading any image or feed on the open web, they do reveal your device’s IP address to Lyft Urban Solutions or the City, and, for a camera, which one you asked for. Unlike the event artwork below, the camera images come with cookies from the City’s server, one of them a web-analytics cookie that lasts a year; the app doesn’t keep them, so they go no further. In the web version, whether they’re kept is up to your browser, as it is for any image from another site: many browsers refuse cookies like these, but one that keeps them sends them back with later camera images, which lets the City tell they come from the same browser.
• Ticketmaster — event listings are fetched by our server, but the event artwork you see is loaded directly from Ticketmaster's image servers by your device, not copied onto ours — or, for events sold through TicketWeb and Universe, Ticketmaster's other ticketing services, from theirs. That request exposes your device's IP address, and which event's image is being loaded, to Ticketmaster or that service — in the same way as any image on any web page. We do it this way because the artwork isn't ours to copy — it belongs to the event organiser or to Ticketmaster, and their terms let us hold their content only briefly, and only to run the service. No cookie is set by those image servers, and no identifier of ours is sent with the request. In the web version, TicketWeb's artwork appears only on an event's own page and in its full-screen view, and your browser loads it the way it loads any picture on a web page: it goes out with any cookies your browser already keeps for TicketWeb, if your browser allows that, which could let TicketWeb connect it with your visits to its own site. Ticketmaster's and Universe's artwork goes out with no cookies at all.
• City of Toronto — satellite base map — the map can be switched from the drawn map to aerial photography, which the City publishes as open data. It is off unless you turn it on. Those imagery tiles are loaded directly from the City's mapping servers by your device, not copied onto ours. A map arrives as many small square tiles rather than as one picture, so these requests reveal your device's IP address and roughly which area you are looking at to the City, and they keep doing so as you pan and zoom. That is more than a single image discloses, and we would rather say so plainly than describe it as just another picture on a page. The requests carry no account, no identifier, and nothing you have typed, and your device keeps each tile it has already fetched for up to 30 days — in the web version, for as long as the City's server allows, currently one day — so the same streets are not asked for again every time you look at them. Unlike the event artwork above, this imagery is the City's own and its open licence expressly permits copying it, so loading it from the City is a choice rather than a constraint: it means the photography you see is always the most recent year the City has published.
• Open data sources — OpenStreetMap, Overture Maps, Wikimedia, Wikipedia, Pexels, Pixabay, Flickr, Openverse, Open Charge Map, the Toronto Public Library, the Government of Ontario, Metrolinx’s GO Transit and UP Express timetables, and the City of Toronto’s open datasets other than the live feeds and satellite imagery described above. These are one-way: our server collects them and serves them to you from data.nearandhere.ca, so your device never contacts the original source and we send it nothing about you. Photographs from these sources are stored on our own server, not linked from theirs: street-level photos from Mapillary, mostly of bike racks, transit stops, car parks, places and venues; encyclopedia photos from Wikimedia, of places and stations; stock photos from Pexels and Pixabay, which are the main picture on nearly every drop-in and program, most restaurants and bars, and the City’s festivals; and a few Creative Commons photos from Wikimedia Commons and, found through Openverse, from Flickr. Full attribution and licences for every source are listed in-app under Data & Map Attributions.

None of the above are paid for access to your information, and none of them receive it for their own marketing use.

Where information is stored and processed

Everything we control runs on infrastructure we operate ourselves, all of it in Toronto, Ontario, Canada (Oracle Cloud Infrastructure, ca-toronto-1 region): one server that runs the app’s data, routing, geocoding, Street View and analytics, plus a file store in the same account and region holding the large static files the map is built from — the base map itself and the outlines it draws for parks, wards, neighbourhoods, cycling and transit routes, and the rest. Your device downloads those map files from that file store directly, which reveals its IP address to it in the same way as loading any file on the web; the files are identical for everyone and nothing about you is attached to the request, though the base map arrives in pieces, so which pieces your device asks for shows roughly which area you're looking at (see Who else may see limited information). We do not route app data through Google Firebase, AWS, or a similar big-tech backend. Our data server logs requests that fail — an error, an answer of "not found", or a request our rate limit turned away because too many arrived from one place too quickly. Each entry holds the address that was asked for, including anything in it, such as a search, a map area or the listings being looked up; the IP address the request came from; the name the app or browser gives itself; and, for a browser, the page it was on. We use this log only to find out what went wrong and to spot automated abuse, such as spam sent to our report form. Requests that succeed are not logged at all, and each entry is deleted automatically after about three days. We keep no other persistent log of visitor IP addresses. If you have turned analytics on, the country, region and city an address resolves to are recorded on the analytics session as described under Usage analytics — the address itself is not kept. We never connect this log to a report's contents, to analytics, or to anything else we hold. The web server in front of our services also logs its own errors, so we can fix them: which address a failed request was for, without the part that carries a search, a map area or a point, and never the IP address it came from; those entries are deleted after about a month. Our Street View service keeps a log of its own. It notes each point it's asked to find a photo for — a listing's location, or a spot you've dropped a pin on or opened — with the time, and, if you open a photo full-screen, which one. It records no IP address of yours: requests reach it through Cloudflare, so the only address in that log is Cloudflare's.

Our backups are the one exception. Once a day, our data server backs up its database: the listings, together with the reports, support messages, requests to cover somewhere new, reply emails and short-lived log of failed requests described on this page. The two most recent backups stay on the server. The three most recent are also stored on Google Drive — outside our own infrastructure, and possibly outside Canada — but only after our server has encrypted them, file names and contents alike, with a key that only we hold. Google stores those files without being able to read them. Our analytics database is not part of these backups.

How long we keep information

• Location from your device: not retained at all beyond the moment it's used — never written to disk on our servers, including the coordinates sent to our routing server to work out a route, or a new one when you stray from it. The areas the map, Near You and directions ask our data server about are not kept either, unless a request fails and is logged (see Where information is stored and processed).
• What you type to search: not retained — our geocoding service and our data server use it only to find the results and keep no record of it, unless a request to our data server fails and is logged (see Where information is stored and processed).
• Where you drop a pin: not kept by our geocoding service, or by our data server unless a request fails and is logged. Our Street View service's log keeps the point, without any IP address of yours, for about a month, then deletes it automatically (see Where information is stored and processed).
• Rough location from your IP address (country, region and city, analytics only, and only with your consent): kept with the analytics events it belongs to, for the same 400 days, then deleted with them.
• Analytics and crash/error events: kept for 400 days, then automatically and permanently deleted by a scheduled process built specifically to enforce this window.
• Information stored on your device (saved listings and pins, My Locations, search history, your Passport, which notices you've read, your settings, and cached copies): kept until you remove it yourself. In Profile → Settings, Reset Passport, Clear saved items (listings and pins), Clear search history (in versions after 1.1.1) and Clear cache each remove their own part. Each of My Locations can be cleared where you set it, in Profile, and in versions after 1.1.1, Clear saved items clears all of them at once. The rest — which notices you've read, the app's record of notifications and app opens, and your settings — goes only when you uninstall the app or, on Android, clear its storage in your device settings; either removes everything from the device at once, though on iPhone a copy lives on in your own backups until they're replaced. In the web version, clearing our site's data in your browser does the same, and a private window's copy goes when you close it. Read-notice records are also pruned automatically by the app as older announcements expire.
• Reports, support messages, and requests to cover a new area: kept for up to 180 days and then permanently deleted by the same kind of scheduled, enforced process as our analytics window. A report we've marked resolved is deleted sooner — about 90 days after we resolve it — and anything identified as spam is removed within about 30 days. A contact email you attached to a report on our website's support page is deleted together with that report, or sooner if you ask.
• The log of failed requests (the address asked for, the IP address it came from, and the app or browser): kept about three days, then automatically deleted (see Where information is stored and processed).
• The web server's error log (which address a failed request was for, without its search, area or point, and never the IP address it came from): kept about a month, then automatically deleted.
• Backups: everything above that lives on our data server — reports, support messages, requests to cover somewhere new, reply emails and the log of failed requests — is also in its daily backup. The two most recent stay on the server, and the three most recent, encrypted, on Google Drive. So anything deleted from the server can survive in a backup for a few more days, until that backup is replaced.
• A message you email us directly: kept as long as reasonably needed to address it, then deleted.

Security

All connections between the app and our servers use HTTPS/TLS encryption. Our infrastructure is self-hosted rather than shared with, or resold through, a third-party data or advertising platform, and access to it is restricted to the small team operating near & here. society. Our backups are encrypted before they leave our server, and only we hold the key.

Your choices and rights

Regardless of where you live, you can:

• Turn analytics off at any time in Profile → Settings. This takes effect immediately; nothing further is sent afterward.
• Turn off location access at any time in your device settings (iOS: Settings → Privacy & Security → Location Services → near & here.; Android: Settings → Apps → near & here. → Permissions), or, for the web version, in your browser's settings for our site. The app keeps working — map centring, nearby search, and turn-by-turn directions simply won't use your device's location anymore.
• Delete what's stored on your device — Profile → Settings can reset your Passport, clear your saved listings and pins, clear your search history (in versions after 1.1.1), and clear the cache, each on its own. Each of My Locations can be cleared in Profile, and in versions after 1.1.1, clearing your saved listings and pins clears all of My Locations too. Uninstalling the app — or, on Android, clearing its storage from your device's settings — removes all of it from the device at once (on iPhone, your own backups keep a copy until they're replaced). In the web version, clearing our site's data in your browser removes all of it.
• Ask what we hold, correct it, or ask us to delete it — because there's no account and analytics isn't linked to your identity, in practice this mostly concerns any direct correspondence you've had with us, or a contact email you chose to leave with a report. Email hi@nearandhere.ca and we'll respond within 30 days.
• Lodge a complaint with your local privacy regulator — see Regional disclosures below for how to reach the one that covers you.

Children's privacy

near & here. is not directed at children, and we do not knowingly collect personal information from children. The app requires no account and no age-identifying information, so we have no way to knowingly identify a child user. If a parent or guardian believes a child has used the app and has a concern, please contact hi@nearandhere.ca.

International data transfers

Everything we control is stored and processed in Ontario, Canada, apart from the encrypted copies of our backups described under Where information is stored and processed, which Google may store elsewhere, and our email: messages to and from hi@nearandhere.ca are kept by our email provider, Spaceship, a company based in the United States. Quebec's Law 25 treats a transfer of personal information outside Quebec — including to another Canadian province — as something that needs assessment. Ontario is subject to the federal Personal Information Protection and Electronic Documents Act (PIPEDA) and comparable protections to Quebec's own law, and we do not transfer personal information to any jurisdiction with materially weaker protection than that. Our backups and our email are the only copies of what we hold that may leave Canada, and the backups leave only in a form Google cannot read.

Cloudflare, our network and security provider, operates a global network, so connection-level information (like your IP address) may transit or be processed outside Canada as a standard part of that service — see Cloudflare's privacy policy for details. The services your device contacts directly, listed under Who else may see limited information, are run by others, and some of them are outside Canada — Open-Meteo's servers, for example, are in Europe and North America — so the IP address those requests reveal can reach them there.

Automated decision-making

We do not use automated decision-making or profiling that produces legal or similarly significant effects on you. Route and search results are computed from what you ask for and public map/transit data — not from a profile built about you.

Changes to this policy

If we make a material change — for example, introducing accounts, or a new category of data collection — we'll update the "Last updated" date above and, where appropriate, call it out in the app itself.

Regional disclosures

The sections above apply to everyone. The notes below map our practices to the specific rules of a few regions — they don't add new practices, they point at the ones above using each region's own terms.

European Economic Area & United Kingdom (GDPR / UK GDPR)

near & here. is a Toronto-focused civic app and does not direct itself at, or market to, people in the EEA or UK. If you use the app from there anyway, we extend the same rights described in Your choices and rights to you: the right to access, correct, delete, or restrict use of your information, to object to processing, to data portability, and to withdraw consent at any time. Our basis for processing is set out in Our basis for processing information. You can lodge a complaint with your national Data Protection Authority, or with the UK Information Commissioner's Office if you're in the UK.

Canada (PIPEDA) and Quebec (Law 25)

We handle personal information according to PIPEDA's ten fair-information principles — accountability, identifying purposes, consent, limiting collection, limiting use/disclosure/retention, accuracy, safeguards, openness, individual access, and the ability to challenge our compliance. Our privacy contact is Vladislav Grigorev, President, reachable at hi@nearandhere.ca, and you can complain to the Office of the Privacy Commissioner of Canada at any time.

For people in Quebec specifically: under Law 25, the person responsible for the protection of personal information is, by default, the person with the highest authority in the organization — for near & here. society, that's Vladislav Grigorev, President, reachable at the same address, hi@nearandhere.ca. As described in Your choices and rights, you can deactivate location use at any time from your device settings, or, for the web version, your browser's. You may lodge a complaint with the Commission d'accès à l'information du Québec (CAI).

California (CCPA / CPRA)

near & here. society is a Canadian non-profit and does not meet the CCPA's applicability thresholds for a covered business (revenue, or volume of California consumers' data) — but we extend the substance of these rights to everyone regardless of legal threshold. In the categories the CCPA defines: we collect geolocation data in three forms — precise location from your device, used live and never stored; the approximate area the map and Near You search around you, used live and not kept unless a request fails; and, only with your opt-in consent, coarse country-, region- and city-level location inferred from your IP address and kept with analytics for 400 days (see Information we collect, and why); internet/device activity information — the text of your searches, used only to answer them, and, only with your opt-in consent, the analytics described above; and identifiers only in narrow forms — an email address, if you choose to give one to receive a reply; a short-lived log of failed requests, with the IP address each came from, kept only to fix problems and block automated abuse; and, with analytics on, a random per-session number that is never stored on your device and cannot recognise a consumer or device over time or across services. We do not sell or share personal information as those terms are defined by the CCPA/CPRA. Precise geolocation is processed only to the extent necessary to provide the feature you asked for in the moment. You have the right to know, access, correct, and delete your information, to limit use of sensitive personal information, and to be free from discrimination for exercising any of these rights — contact hi@nearandhere.ca to exercise any of them.

Contact us

near & here. society
Toronto, Ontario, Canada

Vladislav Grigorev, President — hi@nearandhere.ca
Responsible for the protection of personal information under applicable Canadian privacy law.