Privacy Policy

Navner is open-source software that is self-hosted. Each deployment is operated by the individual or organisation who installed it, using their own Google Cloud project, their own Supabase database and their own hosting account. The maintainers of the open-source project do not operate a shared service, do not host your data, and have no access to any deployment other than their own.

“We” below means the operator of the deployment you are signing in to.

Signing in asks you to grant exactly these two things, and nothing else:

• openid · userinfo.email · userinfo.profile

  Your email address and basic profile, used solely to create and identify your account. This is the same information any “Sign in with Google” button receives.

• calendar.events.readonly

  Read-only access to your Google Calendar events. We request only the reservation events Google itself creates from your travel confirmations, and we read only what is needed to identify a flight: airline, flight number, departure airport, destination and departure time. Google does not expose the booking’s confirmation code through the Calendar API, so you supply that yourself. We cannot create, edit or delete anything in your calendar.

Signing in never requests Gmail access, and the default installation cannot read your mail at all. Some self-hosted deployments may additionally offer a read-only Gmail source (gmail.readonly) to find airline confirmations that never became a calendar event. It is off by default and is never part of signing in: it is asked for separately, only after you turn it on, and it can be revoked at any time without affecting the rest of the app.

Calendar reservation data is parsed to extract flight details, which are stored so the application can open your airline’s check-in page at the moment the check-in window opens and complete the check-in on your behalf. That is the only purpose.

Google user data is not used for advertising, not sold, not used to build profiles, not used to train machine-learning models, and not used for any purpose unrelated to checking you in to your flights.

Navner’s use and transfer to any other app of information received from Google APIs will adhere to Google API Services User Data Policy, including the Limited Use requirements.

To complete an airline check-in, the application needs the same details an airline would ask you for at the counter. You enter these yourself; they do not come from Google:

• Traveller name, date of birth and gender
• Contact email and phone number
• For international itineraries: passport number, issuing country and expiry date, and nationality
• Optionally: Known Traveler Number, redress number and seat preference
• Airline confirmation emails you choose to forward to the private address the app issues you, from which the flight details and the confirmation code are extracted

Forwarded messages are read once, at the moment they arrive, and the message body is never stored: what is kept is the flight the parser found plus a receipt showing the sender, subject, arrival time and outcome, so you can see what the address received. Message content is sent to a third-party AI service only when the deployment operator has configured one, which is off by default; see “Who your data is shared with” below.

Passport numbers, Known Traveler Numbers and redress numbers are encrypted with AES-256-GCM before they are written to the database, using a key held only by the server. Once saved they are never displayed back to you in full and never sent to your browser — only the last four digits are shown so you can tell which document is on file. They are decrypted in memory only at the moment a check-in runs, and they are redacted from every log the application keeps.

All data is stored in the deployment operator’s own Supabase (PostgreSQL) database. Google OAuth tokens are encrypted at rest with the same AES-256-GCM scheme as your documents. Database access rules restrict every row to the account that owns it.

Data is retained until you delete it. Deleting a flight removes it and its check-in history; deleting a traveller profile removes it and the encrypted documents on it.

We do not sell or rent your data. It is disclosed only:

• To your airline, at the moment of check-in — the same details you would type into their website yourself.
• To infrastructure the operator has configured in order to run the service: the database and hosting providers, and — if configured — a remote headless-browser provider used to drive the airline check-in page.

Some deployments may optionally enable an AI service to help interpret a confirmation the built-in parsers could not read. This is disabled by default. When it is disabled, no message content ever leaves the deployment.

You can disconnect Google at any time from your Google Account permissions page, which immediately ends this application’s access to your calendar. You can delete individual flights and traveller profiles from within the app, and deletion there is immediate and permanent. To remove everything, delete your flights and profiles, revoke access on your Google Account permissions page, then ask the deployment operator to delete your account record — there is no self-service account deletion button today, and this page will say so until there is.

Sensitive fields are encrypted at rest, secrets are redacted from logs, and the database enforces per-account row-level access. No system is perfectly secure, and because each deployment is operated independently, the security of a given instance also depends on how its operator has configured and maintained it.

This application is not directed at children under 13 and is not intended for their use.

If this policy changes materially, the updated date at the top of this page will change. Because the project is open source, the full history of this document is publicly auditable in the repository.