Privacy

Nestra has no advertising, and you never need an account to read anything on it. If you choose to sign in with Google — only to save localities, keep notes and compare them — we store your Google account id, email, name and what you save, and nothing else. You can delete all of it yourself, at any time, in one step. If you never sign in, we keep a small cookie remembering the city filter you last chose, so your next visit opens there — and, only if you say yes to the banner that asks, we also keep that preference on our side against a private id. That id names no one, you can delete it in one tap, and if you say no we keep nothing on our side. On its own it stays with this browser; it follows you between devices only if you sign in. Details below.

It counts page views, so we can see which neighbourhoods people look up. That counter sets no cookies, stores nothing in your browser and keeps no identifier for you, so it can tell us a page was opened and never that you opened it. Details below.

A few things on the site accept something you type, and all of them are optional: the search box, which can look up a pincode or place to find the localities near it; a box that measures distances from an address you give; a question box on each locality page, answered by an AI model; a button to ask us to add a locality we don't cover, which stores the place and nothing about you; and a link to a form for reporting what you have seen in your area. None is required to use anything. Each is described in full below.

Nothing that identifies you, unless you sign in or type it in yourself. There is no newsletter, and signing in is optional. Without signing in we cannot identify you by name, and we build a per-person profile — your city preference and which localities you opened — only if you ask us to. The next two paragraphs are the whole of it.

A preference cookie, on your device. So the front page opens where you left off, we keep one small first-party cookie in your browser remembering the city filter you last selected — for example that you were looking at Hyderabad. It holds that one choice and nothing else, stays on your device, and identifies nobody: a note that says “show Hyderabad first” is not a profile. Choosing “All” or clearing your browser's site data removes it, and the site works exactly the same without it. This one is functional and needs no permission — it does nothing but remember a filter on the device it was set on.

A language cookie, on your device. If you pick a language from the switcher, we keep one small first-party cookie remembering that choice, so the site opens in your language next time. Like the city cookie it holds one setting and nothing else, stays on your device, is sent to no one, and identifies nobody. It is functional and needs no permission; clearing your site data removes it and the site falls back to English.

Keeping it on our side — only if you say yes. A banner asks, once, whether we may keep that preference for you on our server rather than only in this browser. If you say yes, we create a random id — a string like a3f1… that means nothing and is tied to no name, email or account — put it in a cookie your browser keeps, and store two things against it: your city choice, and a history of which locality reports you open (the locality and the time — nothing about where you are, your device, or anything else you do). That history is what the “Recently viewed” list on the front page shows you, and it is kept for at most 180 days and 500 entries, with older ones deleted automatically. Because the id lives in a cookie, on its own it keeps all this for this browser; it begins to follow you between your phone and laptop only once you sign in and it can be attached to your account. The id is set so that page scripts cannot read it and it never appears in a web address, and it is never joined to the page-view counter, the server logs, or a sign-in. If you say no, we set a plain “no” and create no id and no server record, and no history is kept. If you said yes before 24 September 2026, you agreed to the city preference only, so we record no history for you until you answer the banner again. You can withdraw and erase the whole thing — preference and history — in one tap, here:

If you sign in. Sign-in uses your Google account and asks Google only for your basic profile: your name and email. We store your Google account id (so we recognise you next time), that name and email, the localities you save and any private notes you write on them, and when you joined and were last seen. Nothing else — not your photo, contacts, location or browsing. Your shortlist and notes are visible only to you; they are never shown to anyone else, counted publicly, or used in any locality's score.

Signing in sets cookies that keep you signed in for up to 30 days and protect the sign-in form from forgery. They are set only when you sign in, and removed when you sign out. Comparisons are ordinary links and need no account.

Deleting your account. On your shortlist page, “Delete my account and everything saved” permanently erases your account, shortlist and notes from our database straight away. Nothing is kept or deactivated “just in case”. Copies may remain in the database provider's routine backups until those expire.

Page-view counting. Every page loads a small script from Vercel Web Analytics, which records that a page was opened, roughly where in the world the request came from, and which site sent you here if any. It sets no cookies, writes nothing to your browser, and assigns you no identifier — so it cannot follow you between visits, between pages in a way that builds a profile, or onto any other website. We use it to see which localities people look up, which is how we decide where to add data next.

It runs on every page. There is no way to switch it off from within the site, and we would rather say that plainly than offer a toggle that does nothing; a browser blocker or Do Not Track extension will stop it loading, and the site works exactly the same without it.

The search box and the address box. Searching a locality name is matched in your browser and sent nowhere. If you search a pincode we don't hold, or press Enter to find a place such as an apartment, road or landmark, that text is looked up so we can show the localities nearest to it. On the schools and connectivity pages you can also enter an address so distances are measured from there rather than from the middle of the neighbourhood. In both cases what you typed is sent to our server and on to Nominatim, the OpenStreetMap geocoding service, which turns it into coordinates. We do not store it, and it is not linked to anything else. It is sent in the body of the request rather than in the web address, precisely so it does not end up written into server logs.

The result is used in your browser and forgotten when you close the tab. Nominatim receives the text from our server, not from you, so your own IP address is not part of what it sees.

Asking us to add a locality. When a search doesn't find what you wanted, you can ask us to add it. We store only what you searched for, the city filter if you had one selected, and — if the place was found on the map — where that place is and how far it is from the nearest locality we cover. We do not store your name, email, IP address or anything else about you, and the request is not linked to any account. To stop the button being misused, our server counts requests per IP address in memory for an hour; that count is never written down. We use the requests, counted together, to decide which areas to add next.

The question box. Each locality page lets you ask a question about that neighbourhood. Your question is sent to our server, and from there to Groq, the company that runs the AI model which writes the answer, together with the public data we hold about that locality. We do not store your question or the answer. To stop the box being flooded, our server keeps a count of questions per IP address in memory for an hour; it is never written to a database or a file, and it is gone when the server restarts. Groq receives the question from our server, not from you, so your IP address is not part of what it sees, but its own terms apply to what it is sent — so please don't put personal details in a question.

The reporting form. Every locality page, and cards where we have little or no data, carry a link inviting you to tell us what you have seen. That link goes to a form hosted by Google Forms, outside this app, and what you submit is stored in the Google account of whoever runs this site — not in our database. It asks which neighbourhood, what category, what you saw, when, and how you know. An email address is optional and used only to ask you a follow-up question. Google's own privacy terms apply to that form, and the locality — and, from a category card, the category — is filled in from the page you came from.

Being honest about this matters more than the sentence above sounding absolute. Like any website, ours runs on hosting that keeps ordinary request logs, and those logs contain IP addresses:

• Vercel serves the site, records standard access logs, and runs the page-view counter described above. The counter's figures are aggregate — page, country, referrer — and are not joined to those logs by us.
• Render runs the data API and does the same.
• Neon stores the neighbourhood data and, for people who sign in, their account and shortlist. For everyone else it holds nothing personal.
• Nominatim, run by the OpenStreetMap Foundation, receives what you typed only when you look up a place in the search box or use the address box, and receives it from our server rather than from your browser.
• Groq receives a question only when you ask one, with that locality's public data, and receives it from our server rather than from your browser.
• Google handles sign-in if you choose to sign in, and hosts the reporting form, seeing a submission only if you choose to send one.

We do not read those logs to build profiles, and nothing in them is combined with anything else. They exist because servers keep them. The place lookup and the question box write no log of their own.

Nestra is also a native Android app on Google Play. It shows the same neighbourhood reports as the website and keeps the same posture: no advertising, no account needed, and no third-party advertising or analytics SDKs built into it — only the Expo/React Native framework it is written with. It does not read your contacts, photos, messages, call logs or device identifiers.

Location — optional, coarse, and it stays on your phone. The “Show my neighbourhood” button asks Android for approximate (not precise) foreground location, once, so the app can open the city you are in. Your coordinates are turned into a city name by Android on the device itself and never sent to us — only the resulting city name is used, exactly as if you had typed it into search. If you decline the permission, or never press the button, the app works the same; you just search by name instead. The app never tracks your location in the background.

What stays on your phone. Localities you save, the language you pick, and the localities you have opened recently are stored only on your device, in the app's own storage. They are not uploaded, not tied to any id, and not visible to us. The app has no sign-in, so it holds no account for you at all. Clearing the app's data or uninstalling removes all of it.

What the app sends to our server. Only requests for the public neighbourhood data you are looking at — the locality whose report you open, or the text you search. These carry no name, no account and no device identifier; like any internet request they reach our hosting (Render) with an IP address, which sits in ordinary access logs and is not used to build a profile. The app sends no analytics or usage events.

The Sun & Shadow map. A locality's sunlight map is drawn inside the app from map tiles loaded from an OpenStreetMap-based tile service. Opening it fetches those tiles from that external service, which — like any map — receives the request for the tiles it serves; nothing about you is sent with it.

Air quality from CPCB and community sensors via OpenAQ. Schools from UDISE and OpenStreetMap. Safety and water from published news coverage. All of it is public information about public places, and each figure on the site names its own source and date.

News headlines are read by an automated classifier to decide whether an article describes an incident in a particular locality. It reads published headlines only.

The app is not directed at children. Nothing is collected from anyone who simply reads it. The reporting form is open to whoever follows the link, so it asks for no more than is needed to check a report and makes an email address optional — but we cannot verify who fills it in, and we would rather say so than imply a check we do not perform.

This page was briefly wrong, and it is worth telling you rather than quietly fixing. On 6 September 2026 the address box and the reporting link went live while this page still said there was no form and that we collected nothing. That was untrue for a few hours until this update. Nothing was stored in that window — the address box has never kept anything, and the form was hosted elsewhere from the start — but the promise made here was that the policy would change first, and it did not.

On 8 September 2026 page-view counting was added — the wording above changed in the same commit as the script, which is the commitment working rather than being tested again. A cookieless counter was chosen over the usual analytics tools specifically so that the rest of this page stays true: no cookies, no identifier, no consent banner asking you to agree to something you did not want.

It was wrong again, from 12 to 13 September 2026. The question box on each locality page went live on 12 September, and this page did not mention it or name Groq until the next day. No question was stored by us in that window, but the page did not tell you where a question goes, and it should have said so before the box appeared. On 13 September the search box also began looking up pincodes and places, and this page was updated in the same change. On 15 September a button to ask us to add a locality was added, and this page was updated in the same change to say what it stores.

On 13 September 2026 optional sign-in was added — to save localities, write private notes and compare them. This page changed in the same commit as the code, before sign-in was switched on. Signing in is the “asking before anything about you is stored” this page promised: nothing is stored until you choose to sign in.

On 22 September 2026 a preference cookie was added — a single functional cookie that remembers the city filter you last chose, so a return visit opens there rather than empty. Until this, the app wrote nothing to the browser for signed-out visitors and said so on this page; the 8 September note above even gave that as the reason for picking a cookieless page-view counter. That is no longer true, so the wording changed in the same commit as the cookie, before it went live. It stores only a city name, is sent to no one, and identifies nobody — the dull, honest kind of cookie, chosen so that no consent banner is needed for it.

Also on 22 September 2026, opt-in personalisation was added — and this is the larger reversal, so it is worth naming plainly. For the first time the site can keep a per-person record for someone who has not signed in: if you accept the banner, a random id is set in a cookie and your city preference is stored against it on our server. (On its own that id stays with the browser it was set in; it spans devices only once it is linked to a sign-in.) This page said, for months, that we assigned no identifier and tied nothing to a profile without sign-in. That is no longer true for anyone who opts in, and the change — the banner, the id, the “forget me” button, and this note — all shipped in the same commit, before the feature went live. It is opt-in, it stores only the preference and never your movements, and it is erasable in one tap. We are telling you it happened rather than letting you discover it, which is the whole of the commitment below.

On 24 September 2026, opt-in view history was added — which takes back part of the note above, so it is named here too. That note said personalisation “stores only the preference and never your movements”. For anyone who accepts the banner, that is no longer true: we now also keep which locality reports you open, and when. It is still opt-in, and the banner was reworded to say so; people who accepted the older wording are asked again rather than being counted as having agreed. It is shown back to you as “Recently viewed”, pruned after 180 days, and erased with everything else by the same one-tap “forget me”. The banner wording, the storage, and this note shipped in the same commit.

On 4 October 2026 the native Android app (Nestra) was documented — and the app section above was rewritten in the same change. The old wording described an installed copy of the website that “requests no Android permissions — no location”. The native app does ask for one permission: approximate foreground location, used only for the “Show my neighbourhood” button, resolved to a city name on the device and never sent to us. Saying the app takes no location would now be false, so the section was corrected before the app's listing went live. The app has no sign-in, no cookies and no analytics SDK, so the rest of this page — which is about the website — still holds.

The commitment stands, and now has a record attached to it. If anything else about what is stored changes, this page changes first.

Questions about this policy, or a request about data you believe we hold, can be sent to the address on the listing page for this app.