Map For Us — privacy policy

Effective date: 17 October 2026

Applies to: the Map For Us app for iOS and Android, and the Map For Us web client.

Verification status

Derived, not composed. Every factual claim below is taken from one of three places in this repository, and where the wording differs from the in-app screen the screen wins, because the screen is the one users read:

What this document is. A truthful description of what the software does, written under India's Digital Personal Data Protection Act, 2023 (the DPDP Act), under which we are the data fiduciary. It has not yet been reviewed by a lawyer, and it makes no statement about the law of any other country.

Who "we" are is settled in §1: the same party publishes the app and runs the service it talks to.

1. Who we are

Map For Us is published by AEVORIS CLOUD LLP, a limited liability partnership registered in India, the entity that submits it to the App Store and Google Play. We also run the only Map For Us service the app talks to, at https://www.mapforus.com — the address is built into the published app, and the server there holds the ciphertext and the metadata described in §4.

So "we", "the server" and "the operator" in this policy are the same party, in two roles: the publisher of the software, and the operator of the service that stores what it encrypts.

Registered office: I-1401 Olive Greens, B/S Vodafone Tower, Gota, Daskroi, Ahmedabad 382481, Gujarat, India.

Contact: support@aevoriscloud.com, or by post to the registered office.

Grievance Officer: Dhaval Sutariya — see §14.

We have not appointed a data protection officer or a representative in the EU or the UK. Every request, from any country, goes to the Grievance Officer.

2. The short version

Map For Us shares your location with the people you have chosen, and encrypts it on your phone first, with a key that belongs to your circle and that the server has never held.

That has two consequences and both are worth stating in the same breath:

• The operator cannot read where you are, where your saved places are, what your circle is called, or what any of your messages say. Not with a court order, not with a support ticket, not with a database dump. There is no escrow and no reset.
• The operator can still see who shares with whom, and how often. Encryption does not hide the fact that a message was sent, or when. That is a real disclosure and §4 sets it out in full.

"We cannot read your data" must never be allowed to imply "we know nothing about you". It does not.

One more thing said early because it matters most: Map For Us is not an emergency service. Fall detection, crash check and SOS are best-effort alerts from a phone; if someone is in danger, call your local emergency number.

3. What the app collects on your device

No account, in the ordinary sense. Signing up asks you for no email address, no phone number, no password and no name. The app generates 32 random bytes on first launch, sends them once, and the server stores only a hash of them. What that does and does not buy you is in §5.

There is no analytics, no advertising, and no crash reporting service of ours. We have added no analytics, advertising or crash-reporting SDK to the app. Two Google components inside it collect diagnostics of their own under Google's terms, and §7 names them: the Google Maps SDK that draws the map, and, on Android, the ML Kit scanner that reads QR codes. Diagnostic logging is written to the device's own console; a rule in the code refuses to log a location, a key or a message, and that rule is itself tested. The app has no way to send those lines to us, and our server has no endpoint that would accept them. The only time any of them reach us is when you choose Send feedback and attach them yourself.

If the app closes unexpectedly it writes a crash report to this phone's cache. On the next launch you are shown the whole report — the exception, the stack, the app and OS version, the device model, free disk — and you choose whether to send it to us, save it somewhere else, or delete it. Nothing is sent unless you tap send. Coordinates, place names, message bodies, tokens and file paths are removed before the report is written down. If you do send one, we store the text and nothing beside it: no user id, no device id, no address. That means we cannot tell you afterwards that your report fixed something, and we accept that cost, because a list of who crashed and when would be a record of when your phone was awake. You can turn crash reports off entirely in Settings.

4. What the server necessarily sees

For every location or event your phone uploads, the database holds one block of ciphertext and the labels needed to file it:

• which circle it belongs to;
• which member and which device sent it;
• which key era it was sealed under, and its sequence number;
• the moment it arrived;
• its size — which is always identical, on purpose.

Alongside that: your account and device identifiers, your devices' public keys, who is in a circle with whom, when each of your devices last reached the server and last accepted a notification, and — if you turn notifications on — the push token Apple or Google uses to reach your phone. Members of your circles see the first of those times as "Last seen" beside your devices, because a phone that has stopped reporting has to look different from one with nothing new to say.

Names, photos, saved places, circle names, sharing schedules, a walk-home session in progress, tasks, work rotas and policies, automations and wellbeing settings are encrypted too, in a second kind of block. Beside each one the server holds only whose it is, which circle, which kind of block it is, which key era, how many times it has been edited and when — and, for a sharing schedule only, which member it is about.

Updates are a fixed size. Location messages are 297 bytes and events 553, whatever they say, so a cry for help and a routine update cannot be told apart by length. Sealed blocks of one kind are all the same size too — a profile is the same size with a photo or without. Pictures, voice notes and files come in a few fixed size classes, so their size tells the server roughly what kind of thing was sent, never what it shows or says.

What the operator's own console records

Whoever runs the server can open a console that shows exactly what §4 above describes — accounts, devices, circles, subscriptions — and can do seven things from it: give an account a plan by hand and end one, sign out one device or all of them, create and retire a discount code, and delete an account. None of that is new: anybody holding the database password could always do it.

What is new is that the console writes down every one of those acts — which operator, which account, at what instant, with what arguments — in a log that can only be appended to, and that is chained so that editing a past entry breaks every entry after it. That log holds no free text: there is nowhere in it for somebody to write a note about you.

Two counters exist beside it: how many rows the nightly clean-up deleted and when it last ran, and how many purchase receipts each app store sent and how many were refused. Neither names an account.

The three inferences that survive encryption

1. The social graph. Who is in a circle with whom is stored in the clear, because the server has to know it to decide who may fetch which ciphertext.
2. Timing. When your phone uploads is itself a signal: a dense run of updates means you are moving, a gap means you are still or your phone is dead. The operator can see that somebody started moving at 08:12 and stopped at 08:47, without knowing where they went. This is the leak we cannot close. Closing it would mean sending fake updates around the clock so the real ones are hidden in them, which no phone battery survives. We chose battery life and are telling you rather than choosing it and not.
3. Your IP address, visible to the machine that terminates the connection for as long as the request takes. It is stripped before anything is written to a log.

5. Identity: what there is instead of an account

There is no username and no password, and signing up asks for no email address. What identifies you is:

• a user identifier — a random UUID the server assigns at enrolment and keeps;
• a device identifier and an X25519 public key per device, which is what other members' phones seal your circle's key to;
• an authentication secret, 32 random bytes generated on your phone. Only a hash of it is stored (SHA-256 with a fixed label), and 32 random bytes cannot be guessed back from it, so a full database dump does not yield a working login for anybody;
• a recovery code, 24 characters from your phone's random generator, which has never been sent to the server and cannot be worked out from anything the server holds.

This is pseudonymity, not anonymity, and the distinction matters legally. The user identifier is stable, it is attached to every row you upload, and it is what makes your history yours. Under the GDPR and under both stores' definitions, data carrying it is personal data linked to you — the reasoning is written out at length in store-submission.md §3. Nothing here is claimed to be anonymous.

6. What we do with it, and what we never do

The only purpose is to make the app work. Deliver your location to the circles you chose; deliver notifications; keep sessions and devices straight; stop abuse of the enrolment and recovery endpoints with rate limits.

Never, and there is no setting that changes it:

• no advertising, no advertising identifiers, no ad SDK;
• no profiling, and no automated decisions about you. We do not score you. The app can work out a 0–100 score for a single drive, on the phone that shows it, from positions that phone already holds; it is never sent to us. Anyone in your circle who opens one of your drives can see that drive's score, with every point it lost listed beside it. Your score over days, weeks and months is shown only to you, and nobody is ranked against anybody;
• no sale of data, and no sharing with data brokers;
• no read receipts for location. Nothing in this app reports that you opened it, looked at the map, or checked on a particular person. In the wrong household that is a surveillance feature wearing a product's clothes, and it is not built and will not be.

Messages are different, and the difference is worth being exact about. A message can show ticks: one when your phone sealed it, two when everybody else's phone has fetched it, and two in a different colour when everybody has had it on screen. Read receipts can be turned off under You → Notifications → Read receipts, and turning them off also stops you seeing everybody else's. Delivery ticks cannot be turned off. None of this applies to the map: nothing reports that you looked at where somebody is, and nothing ever will.

• no typing indicators. Nothing is sent while you are writing. Your circle can see when each of your devices last reached the server (§4), which is not the same as when you opened the app: a phone in a pocket reaches it all day.

If you pay us

Nothing about a payment reaches the parts of this app that hold your family's data, because there is no connection between them to make. What the server stores when you subscribe is a purchase record held against your account number: which plan and term, bought through which store, in which country, until when, a change the store has scheduled for your next renewal, whether the store reports a payment problem, and the store's own reference for the subscription. Beside it, one line per charge: the amount and currency as the store reports them (Google reports none, so a Play charge is recorded at the list price). Not your name, not your email, not your card, not your address — those stay with Apple or Google, who are the ones actually taking the money (§7). Plans are sold only through the App Store and Google Play; the web app sells nothing. Both store consoles count this as purchase history collected for the app's own functioning, and that is how it is declared.

A plan changes what the server will do — how many people can be in a circle, how long it keeps your encrypted history, whether it accepts pictures — and it changes nothing about what the server can read, which is still nothing.

If you stop paying, nothing changes for thirty days. Not your history, not your circle, not one person in it. After that the circle stops accepting new positions and the app shows the plan screen in place of the circle; anyone in the circle can still raise an SOS from that screen, and the server keeps 90 days of history instead of the plan's window, for when the plan comes back. If you cancel, everything already on your phones stays on your phones.

7. Who else is involved

There are no other recipients. No analytics vendor, no advertising network, no crash reporting service, no CRM. A crash report you choose to send goes to the same server as everything else, and to nobody else.

Support conversations are the one thing we hold that is not encrypted end to end. What you write to us from You → Additional settings → Contact support, a report you make about a person or a message (in your own words, since we cannot read the message), an email address if you choose to give one, and a diagnostics report if you attach one (it contains no locations and no messages) are stored readable on our server, against your account, so that we can answer.

8. What the encryption does not do

This section exists because a privacy policy that lists only the protections is a marketing page.

• A stolen key reads everything from that era. Your circle has one key at a time, and anyone who obtains it can read every message sealed under it, old ones included. Messaging apps avoid this by changing the key with every message, which makes old messages permanently unreadable — and that is incompatible with what a family expects here, because somebody who joins tomorrow can read last week. We chose readable history, and this is what it costs.
• Removing somebody does not un-tell them. When a member is removed the server stops answering their requests and the circle moves to a new key, so nothing sent afterwards is readable to them. Neither step reaches backwards: they keep the old key, so anything they had already downloaded stays readable to them, for ever. There is no undo.
• Everyone in your circle can see everyone in it. A circle is the boundary, not a person. Every member holds the same key. Accepting an invitation is a decision about trust rather than a setting, which is why the app asks you to compare a safety number with the person who sent it.
• Anyone holding your phone unlocked holds the keys. They have to be usable while the screen is locked, or your phone could not encrypt a location at 3am after a restart. If your concern is a person with physical access to your device, encryption is not the thing that protects you.
• In a browser, your keys are protected from a stolen disk and not from the page. A browser has no keychain. Keys are stored encrypted under a key the browser will not let anything read, so a copied profile yields ciphertext — but any code running on the page can ask that key to decrypt. A malicious extension, or a successful attack on the site, would have your keys.

9. Sharing is consensual, and the app is built so it cannot stop being

A location-sharing app is a stalking tool when the sharing is not consensual, and encryption does nothing about that: it protects the family from the operator, not a member from the circle. Three things follow, and none of them is a policy promise — each is a fact about what the software can do.

• Pausing sharing cannot be taken away from you. There is no server call in the pause path and no per-member sharing column anywhere in the database, so a circle owner cannot re-enable your sharing from their side. Not out of restraint — there is nothing to enable it with.
• Pausing is visible, not a ghost mode. The rest of your circle sees a member whose location has stopped updating. A hidden pause invites "why was your location hidden" coercion.
• Leaving a circle and deleting your account need nobody's approval. Leaving deletes your own membership row and consults no role.

If you are in a household where somebody has your unlocked phone and does not have your consent, please read §8 again. This app cannot help with that, and it would be dishonest to imply otherwise.

10. Retention and deletion

Location and event history is deleted by your own phone, on the schedule you set in the app, and by the server on its own schedule as well — see the retention table below.

Deleting your account asks the server to remove everything you have sent, revokes your devices, and destroys the keys held on that phone. There are two ways to ask. From inside the app: You → Account & security → Sign out or delete → Delete my account. And, for somebody who has already uninstalled it, from a browser at https://www.mapforus.com/delete, using the recovery code you wrote down — the page turns the code into a lookup key on your own machine and sends only that, never the code. Both do the same thing: everything you sent is deleted, every device is revoked for good, your recovery blob goes, and a circle you were the only member of goes with you. A circle other people are still in stays with them, because their history is not yours to delete; you are removed from it and, if you owned it, somebody who is still in it becomes the owner.

What deletion keeps, and why. The bare account row stays, holding no data, so that the same secret can never sign up again as somebody new. Purchase and charge records stay, because the stores and the tax authorities expect them. Support conversations stay until twelve months after they were closed, so a complaint can still be followed up. Signed visit receipts other people hold stay with them.

The honest description of what that guarantees: the deletion is a request made to a server, not something you can check from your phone. Ciphertext the operator failed to delete stays unreadable, which is the only part of this that mathematics enforces rather than good behaviour.

One copy survives an account deletion. The background part of the app keeps its own keys in your phone's secure hardware and offers no way to read or erase them — a rule that exists to stop malicious code extracting them, and which stops the app tidying them up as well. Uninstalling the app is what removes them on Android. On an iPhone they can outlast the app as well, because iOS keeps an app's keychain entries after the app is deleted; erasing the phone removes them.

How long the server keeps ciphertext nothing has asked it to delete. It is a fixed number per plan, applied by the server itself once an hour, and it is enforced in code rather than promised here: locations and events older than the circle's window are deleted whether or not any phone asks.

The window is the server's copy. Your own phone's history is a separate setting and is deleted by the phone on its own schedule, which is why a history longer than the plan's window can still exist on the device that recorded it. Sealed blobs — your profile, your places, your schedule — are not swept: they are current state rather than history, and they go when you delete your account.

Access logs. The API writes no request log at all — server/src/metrics.ts explains why. The web server that hands out the web app's files logs each request it serves (the time, the page and the browser's description of itself) to a log that is rotated by size, at 50 MB, rather than by date, so how many days it covers depends on traffic. It sits behind our TLS proxy, so the address it records is the proxy's own, not yours, and the proxy is not configured to log anything.

Support conversations are deleted twelve months after they are closed. One still open is kept until it is answered.

Backups. The database is backed up every night and encrypted a second time before it leaves the server; the copies on the server are deleted after 14 days. A further copy goes to Cloudflare R2 (§7) and one to our own computer, and both of those are deleted after 30 days. So an account you delete leaves the next night's backup, and every backup within 30 days.

11. Your choices and your rights

In the app, without asking anyone: pause sharing globally or per circle; set quiet hours; coarsen the position a circle sees; revoke a linked device; leave a circle; delete your account; turn notifications off; turn Bluetooth Nearby off; turn the web basemap off.

Your rights under the DPDP Act. You can ask us for a summary of the personal data we hold about you and what we do with it; ask us to correct, complete, update or erase it; have a grievance heard by our Grievance Officer (§14); and nominate someone to exercise these rights for you if you die or become unable to. Where we rely on your consent you can withdraw it as easily as you gave it — leaving a circle, turning sharing off or deleting your account all work without asking us. If you are not satisfied with how we handle a grievance, you can complain to the Data Protection Board of India.

Two limits on any access or portability request, which are properties of the design rather than excuses. The operator cannot export your history in readable form, because the operator cannot read it — what it can hand over is ciphertext, and only your circle's key opens it. And it cannot identify you from a name or an email address, because it holds neither for your account (an email you gave in a support conversation sits with that conversation); a request would have to be authenticated from the device or the recovery code.

12. Children

Map For Us is built for families, and a family includes children. Under the DPDP Act a child is anyone under 18, and processing a child's personal data needs the verifiable consent of a parent or lawful guardian.

What the app does today. It asks for no date of birth, has no age check, and does not itself verify a parent's consent. Nobody can join a circle without an invite, and only the circle's owner or an adult member can create one; the inviter chooses the new member's role, and a limited member cannot invite anyone else.

What our terms require. A person under 18 may use Map For Us only in a circle that their parent or lawful guardian invited them to, with that parent's or guardian's consent.

We show no advertising, build no profiles and sell no data — about anybody, children included (§6). If you are a parent or guardian and believe your child is using Map For Us without your consent, write to the Grievance Officer (§14) and we will delete the account.

13. Security, stated as narrowly as it should be

Locations, events, profiles, places, schedules and journal files are sealed with XChaCha20-Poly1305 under a key generated on a member's device and delivered to other members' devices as a sealed box addressed to their public key. The server has never held one. Keys live in the iOS Keychain or the Android Keystore (hardware-backed where the device offers it), and in a browser under a non-extractable WebCrypto key. Transport is TLS, over ciphertext that is already encrypted.

This has now run on physical phones, not only in automated tests.

Development device-verification sessions in September 2026 ran the sealing described above on two real Android phones — a OnePlus 8 Pro and a OnePlus 5T, both release builds, not an emulator — and confirmed it working end to end: location shared between the two devices, text messages and read receipts, voice notes recorded, sealed, uploaded and played back, pictures sent and rendered, in-app SOS, the "walk with me" escort guard, schedules and quiet hours, errands, and private threads. The same sessions also ran the app's Bluetooth presence radio on real hardware — both phones transmitted and received genuine BLE traffic, and one phone correctly recognised the other as nearby, though two-way discovery between this specific pair of handsets is not yet confirmed. This is real evidence the encryption above runs correctly outside a test double, not only under the automated tests.

Since then it has also run on iPhones and on more Android phones, with push notifications delivered on Android; delivery to iPhones has not yet been verified. No part of this app has been independently audited, and it is not yet listed in the App Store or Google Play. The in-app transparency screen does not make this claim — it lists what the operator can and cannot see, a different question from what has run where, and the two should not be conflated.

14. Grievance officer

Dhaval Sutariya, AEVORIS CLOUD LLP, I-1401 Olive Greens, B/S Vodafone Tower, Gota, Daskroi, Ahmedabad 382481, Gujarat, India.

Email support@aevoriscloud.com with "Grievance" in the subject. We acknowledge a grievance within 24 hours and resolve it within 7 days. If you are not satisfied with the answer, you can complain to the Data Protection Board of India.

15. Where this is published

Both stores require a privacy policy at a URL that resolves, and both check it.

The web build serves this document as a static page. public/privacy.html is copied into the export by expo export, so it is live at /privacy.html wherever the web client is deployed — see architecture.md, "The privacy policy is a static page in the build". tools/store/privacy-page.test.ts renders this file and asserts the committed page matches it byte for byte, so the hosted copy cannot drift from the one a reviewer reads here.

The URL, for both store consoles: https://www.mapforus.com/privacy.html

It resolves today — curl -sI https://www.mapforus.com/privacy.html answers HTTP/2 200, and docs/store-submission.md's "Still open" section records the check.

16. Changes

When we change this policy we publish the new version at this address and change the effective date at the top. The app has no way yet to show you a notice inside it; until it does, we will announce a material change on www.mapforus.com before it takes effect.