Privacy Policy
Last updated 2026-09-10
MoveDNA plans journeys. To do that it needs to know where you are going and, if you connect a calendar, when you need to be there. This page says exactly what it reads, what it keeps, what it never keeps, and how to get rid of all of it. Where a protection has a limit, the limit is written down.
What we collect
Your account: email address, and a name if you give one. Your password is stored only as a bcrypt hash and is never readable, by us or anyone else.
Journeys you plan: the start and end points, the time, and how you chose to travel. Start and end points are encrypted at rest under a key derived for your account alone.
Saved places: the name, address and coordinates you save. Encrypted at rest, the same way.
Your travel preferences: how much you weigh time against cost, walking, accessibility and reliability — either because you set them, or inferred from journeys you chose.
A record of access: which purpose read which of your data, and when. This is what lets you audit us.
If you connect a Google Calendar
We request one scope and only one: calendar.events.readonly. We never request calendar.readonly, and we cannot write to, change or delete anything in your calendar.
We do not read what your meetings are about. The request we send Google carries a field projection listing the fields we want, and the title, description, attendees, organiser, attachments and conference links are not on it — they never leave Google's servers. We also ask for at most one attendee record, which is yours, so other people's email addresses are never sent to us at all.
What we read is: when the event starts and ends, whether it is all-day, its time zone, a link back to it in your own calendar, and — only if you separately grant the location permission — the location field.
No calendar content is stored. Not one field, not one row. Event times live in the server's memory for at most fifteen minutes so that reloading the page does not re-query Google, and are then gone. Nothing about your calendar is written to our database, ever.
The location, if you grant it, is used in memory to work out roughly where the meeting is, by matching it against places you have already saved or travelled to. We do not send it to a geocoding service. If we cannot place it, the app says so and offers no route — it does not guess.
You can disconnect at any time from the Calendar screen, or withdraw the permission from the Privacy screen. Either one deletes our copy of the access and refresh tokens immediately.
What we never collect
Meeting titles, descriptions, attendees or organisers.
Your contacts, your email, your files, or any Google data beyond calendar event times and (optionally) locations.
Continuous or background location. MoveDNA does not track where you are; it plans routes between points you give it.
Payment card details. We do not process card payments.
Who else sees it
Google, when you connect a calendar — your OAuth tokens are exchanged with Google, and this is the connection you authorised.
A routing provider, when you plan a journey. Planning a route means sending the start and end coordinates to a mapping service to ask how to get between them. Your name, email and account are not sent; the coordinates are.
We do not sell your data, and we do not share it for advertising.
How it is protected
Journey endpoints and saved places are encrypted at rest with AES-256-GCM under a key derived per account, so one account's data cannot be read with another's key.
The database enforces row-level security: the connection serving your requests cannot read another account's rows even if the application asked it to.
One deliberate exception, stated rather than hidden: each journey also stores a coarse location cell — about a five-kilometre square — unencrypted, so that patterns can be recognised without decrypting anything. It is not precise enough to identify a building, and it is deleted along with everything else when you erase your account.
How long it is kept
You choose. Journey history defaults to 180 days and can be set between 30 days and 3 years. The access log defaults to 1 year and can be set between 1 and 10 years. Both are on the Privacy screen, and a sweeper enforces them.
Getting it back, and getting rid of it
Export: one button on the Privacy screen returns everything we hold about you as a JSON file — profile, settings, journeys with their locations decrypted, saved places, preferences, consent grants and the full access log.
Erasure: one button starts it. Your data is hidden immediately and permanently destroyed after thirty days; during that window you can cancel and get it back. After it, the key your data was encrypted under is destroyed, which makes the encrypted parts unrecoverable by anyone including us.
One thing does not wait for the thirty days. If a face template has been enrolled for your account, it is deleted the moment you request erasure, not after the window. Face data is biometric data, nobody meaningfully recovers a face template, and keeping one for thirty days after somebody has said delete me is a risk with no matching benefit. The consequence is that cancelling will not bring it back and it must be enrolled again.
Your rights
Under the GDPR and Thailand's PDPA you can access, correct, export, restrict and erase your data, and withdraw consent. Export and erasure are self-service buttons rather than a request you have to wait on. Consent is granular and per-purpose: granting calendar access does not grant location access, and either can be withdrawn on its own.
Contact
Questions, or anything on this page that does not match what you observe: [email protected].