Privacy Policy
Effective date: 13 September 2026
Last updated: 13 September 2026
This policy describes how Aevamo (“we”, “us”) handles personal data when you use the Aevamo mobile app and related services (the “Service”). If you only want the summary, read the TL;DR at the bottom.
Aevamo is operated by Kerr Campbell, who is responsible for how the Service handles your personal data (the data controller).
Privacy enquiries: [email protected].
1. What we collect
1.1 Account information
When you create an account we ask for your email address and you choose how to sign in: a passkey, an account password, or both. Your name and other profile details are stored only inside your encrypted records (see §1.2), not as readable account data.
For a password, the app derives a sign-in proof on your device and we hold a salted hash of that proof, never the password itself. For a passkey, we hold its public key, the name you gave it and when it was last used. We also keep the names, public keys and timestamps of the devices you have approved, the short-lived codes and requests used for sign-in, recovery and device approval (as hashes, expiring within ten minutes), and encrypted copies of your record key that your passkey, password or recovery kit can open. An approved device can also provide an encrypted key transfer to another device you approve.
When you choose an account password, the app checks it against Have I Been Pwned’s Pwned Passwords service. The check can run while you type a password that meets the minimum length. It sends only the first five hexadecimal characters of the password’s SHA-1 hash, not the password or full hash. The request goes directly from your device to that service, which also receives the network information needed to answer it, such as your IP address.
Earlier accounts can retain a salted hash of their old password during the move to encrypted records. That hash is removed when the password has been carried into the encrypted-account sign-in system; moving the records alone does not always remove it.
1.2 Travel data you enter
The Service brings your travel history and relevant day counts together. The app stores the trip records, stay-limit settings, and passport details that you choose to enter. Without an account, these records stay on your device. With an account, records saved to that account sync automatically with our backend so you can access them on another device. They are encrypted on your device before they are sent, with a key we never receive in readable form: our servers hold the encrypted copies, their opaque identifiers, version numbers and sizes, and, for migrated accounts, counts of records by type used to check a restore. We cannot read the contents of your encrypted trips, notes or passport details. Information you deliberately send to support is separate (see §1.7). The one detail kept readable is the nationality of the passports you hold, because the rules that apply to you depend on it. We do not scan your passport, read NFC chips, or access border records.
Accounts created before encrypted records were introduced hold their trips and passport details in our database until they move to encrypted records. Some sensitive fields and file contents are encrypted with our own key, so we can read them; not every legacy database field has application-level encryption.
1.3 Optional attachments
If you attach a photo or file to a trip (for example, a boarding pass screenshot), the app keeps an encrypted local copy and, if you have an account, syncs an encrypted copy with that account. We hold neither the file’s name nor its type in readable form. You can delete it at any time. When an earlier account moves to encrypted records, the old readable copies are removed as part of that move. Original files retain their contents and embedded metadata, which can include location information; that metadata is inside the encrypted copy and is restored with it.
1.4 Diagnostic data
The app keeps diagnostic logs on your device to help reproduce problems for support. There is no automatic app analytics or session-replay uploader.
Crash reports. When the app logs an error or a warning, it sends an anonymous crash report: what went wrong, where in the app’s own code, the app and operating-system version, and the last 50 lines of the app’s log, redacted on your phone in the same way as a feedback log. A report carries no account, no device or install identifier and none of your travel records, and our backend does not store the IP address it arrived from. Each fault is sent at most once each time the app runs. Crash reports are on by default; you can switch them off in Settings > Support > Send crash reports, and reports still waiting on your phone are then not sent.
When you choose Send feedback, the recent app log is included by default if it is not empty. You can preview it and untick the option before sending. The app redacts sensitive patterns before sending this log; review what will be sent. Support receives it as described in §1.7.
Separate background-detection logs can include precise coordinates and timestamps. They are not automatically attached by the feedback form. If you copy and share them yourself, we receive what you send.
Our backend also records operational logs, including request and account identifiers and errors, to operate and troubleshoot the Service. These are separate from the diagnostic logs kept on your phone.
1.5 Device-local data
The app stores travel records, preferences and detection logs on your device so it can work offline. Personal rows of the local database, cached records and attachment files are encrypted by the app with a key held in the platform’s secure storage; detection logs are not encrypted by Aevamo.
Authentication tokens and your record key are kept in the platform’s secure storage (Android Keystore / iOS Keychain). Tokens are sent to our backend to authenticate requests, including automatic account sync and token renewal. The record key leaves your device only in encrypted form, wrapped for your passkey, password or recovery kit, or through an encrypted transfer to a device you approve.
1.6 Location and border detection
With your phone’s location permission, Aevamo accesses location data, including precise coordinates, to identify your country and suggest stays when you cross a border. Background location permission enables these checks even when the app is closed or not in use, with notifications if allowed. Your phone’s location services provide the readings; Aevamo resolves them to countries on-device.
Detection records, including coordinates, timestamps and accuracy, are kept in an on-device log. Precise coordinates from border detection are not included in account sync. Original attachments can contain location metadata as described in §1.3. With an account, we automatically sync country/day readings, their detection source and an app-generated device identifier to help reconcile travel records across your devices. These readings are associated with your account and are inside your encrypted records once the account uses end-to-end encryption.
On Android, the app can also read the country of the connected mobile network, including while the app is closed, without GPS or location permission. This provides country-level crossing suggestions when a location fix is unavailable.
You can change or revoke location access in your phone’s app permissions. Revoking background location stops background coordinate checks, but does not erase existing detection records or stop Android’s mobile-network country checks. Location is not used for advertising.
1.7 Feedback and support
If you tap Yes on “Was this helpful?”, the app sends one anonymous “helpful” count: no text, no account, no device ID. We store the count with a random record ID and timestamp. Our backend temporarily holds your IP address in memory to limit abuse. Request logs record random request and trace IDs, the request path, status and timing, but not your IP address. The IP rate-limit window lasts one hour; expired entries are cleared within a minute.
Now and then the app asks Google Play to show its rating box. Google handles your rating; we receive nothing from it.
When you send feedback, we receive your message, any contact email you provide, and the account and travel-record context associated with the report. In-app feedback, its included log and any image you attach are stored on our backend in a form support can read. A summary, which can include your email, relevant travel dates and the calculation you reported, is also sent to our support inbox through Brevo, with the included log and image as email attachments. These reports are not end-to-end encrypted travel records.
The feedback image is rebuilt as a JPEG without the original file’s embedded metadata before upload. Its visible contents still go to support. This preparation is specific to feedback images; it does not apply to all trip attachments. If you email support directly, we receive the contents of that email and any attachments you send.
1.8 Website tools and waitlist
The website processes the passport country, destination, dates and previous stays you submit to answer your question or calculate a plan. Previous-stay inputs are used for that request, rather than saved as an account record. Your browser can retain form values within the current tab. Website hosting and request handling also process technical information such as IP addresses for delivery, troubleshooting and abuse prevention.
If you join the waitlist, we store your email and any optional name, use case or message you provide in our backend. Joining does not create an app account or automatically send an email.
If you ask us to email you a stay plan, your email address and the plan pass through our backend to Brevo once to send it; we do not store either. To limit abuse, our backend temporarily holds a hash of your email address and your IP address in memory, in a one-hour rate-limit window; expired entries are cleared within a minute. Delivery logs contain a redacted address and delivery metadata, not the plan. Brevo’s delivery-log retention is described in §6.
1.9 Other data
The app does not access your contacts, calendar entries, microphone, camera streams, advertising identifier or browser history, and does not request payment details. If you choose Take a photo for a trip attachment, the app opens the system camera and receives the photo you take. Files and messages you choose to provide can contain other personal information. We do not buy personal data or sell it.
2. How we use your data
| Purpose | Lawful basis (UK/EU GDPR) |
|---|---|
| Operate your account and sync your trips and country/day readings | Contract (Art. 6(1)(b)) |
| Use device location for optional location-based border detection | Consent (Art. 6(1)(a)) |
| Use Android’s mobile-network country for crossing suggestions | Legitimate interest (Art. 6(1)(f)) |
| Support sign-in, recovery and device approval, including verification and security emails | Contract / legitimate interest |
| Diagnose crashes and improve the app | Legitimate interest (Art. 6(1)(f)) |
| Provide requested website answers and calculations | Legitimate interest (Art. 6(1)(f)) |
| Keep and respond to a waitlist request | Consent (Art. 6(1)(a)) |
| Comply with legal obligations (e.g. tax) | Legal obligation (Art. 6(1)(c)) |
We do not use your data for advertising or for automated decision-making that produces legal effects.
3. Who we share data with
The following services support the operation of Aevamo:
| Provider | Role | Region |
|---|---|---|
| Railway Corp. | Backend, database and attachment hosting; the support mailbox, stored encrypted | US / EU |
| Brevo (Sendinblue) | Transactional email, including password resets and feedback notifications to support | EU |
| Cloudflare | Website hosting and request delivery; routing email sent to support | Global |
| Have I Been Pwned (Pwned Passwords) | Password-breach checks using a short hash prefix, sent directly from your device | See §1.1 |
| Apple / Google | App distribution, device location services and OS-level crash reports | Global |
App and website display fonts are bundled with the app or site rather than fetched from Google’s font service at runtime.
We do not share your data with any advertiser or data broker.
4. International transfers
Data may be processed in the United States by Railway. Where that happens, the transfer relies on the EU Commission’s Standard Contractual Clauses (SCCs) and the UK Addendum.
5. Your rights
Under UK / EU GDPR you have the right to:
- Access the personal data we hold about you
- Correct inaccurate data
- Delete your account and associated data (“right to erasure”)
- Export your data in a machine-readable format
- Restrict or object to certain processing
- Withdraw consent for device location access in your phone’s app permissions (see §1.6)
- Complain to your supervisory authority, in the UK that’s the Information Commissioner’s Office (opens in a new tab).
To exercise any of these, email [email protected] from the address on your account. We respond without undue delay, normally within one calendar month. Where the law permits an extension for a complex request, we will explain it within the initial response period.
6. Data retention
- Account, trip and synced country/day readings: kept until you delete your account. Deleting the account removes your encrypted records, wrapped keys, passkeys and device records together.
- Sign-in codes and device requests: expire within ten minutes. Expired challenge rows become eligible for cleanup one day after expiry. Cleanup runs when another challenge or device request of the corresponding kind is created, so expired rows can remain longer when those requests do not occur.
- On-device detection records: retained in the app’s local storage; there is currently no automatic expiry. Revoking location permission does not erase these records.
- Backups: encrypted copies of the account database, attachments and the support mailbox are kept on the operator’s computer and in a Railway-hosted store for recovery. Each copy is deleted 90 days after it was made, whether or not later backups succeed. Deleting an account does not rewrite existing backups, so its data leaves them within 90 days. The deletion runs on the operator’s computer; if that computer is off, it happens when it next runs.
- Hosted server logs: Railway keeps the hosted operational-log history for seven days under the current hosting plan.
- Transactional email logs: Brevo is configured to retain delivery logs for one month. New transactional-email previews are not stored. These settings do not delete the copies of messages delivered to the support inbox.
- In-app feedback: the backend report, included log and stored feedback image are deleted with the associated app account. Copies already delivered to the support inbox are separate.
- Crash reports: deleted 90 days after they arrive. They carry no account, so deleting an account does not remove them; they leave within 90 days.
- Anonymous helpful counts: stored without an account, with no automatic expiry. Deleting an account does not remove these counts.
- Support correspondence: messages to and from the support inbox, including copies of in-app feedback, are deleted two years after the last message in their conversation. Deleting your app account does not remove them sooner; contact [email protected] to ask for earlier deletion.
- Waitlist requests: stored separately from app accounts and deleted 12 months after Aevamo’s public launch. Contact [email protected] to withdraw your request or ask us to remove it sooner.
7. Children
Aevamo is designed for adult travellers and is not directed at children.
If you are a parent or guardian and believe a child has provided personal data without the consent required by applicable law, contact [email protected] so we can review the information and take appropriate action.
8. Security
The mobile app connects to our production backend over HTTPS. Travel records saved to an account are encrypted on your device with a key we never receive in readable form. This protects the contents of those encrypted records; account metadata and information you deliberately send to support remain readable to operate the service. The same design means we cannot restore your encrypted records if you lose all ways to open them: passkeys, your account password, approved devices and your recovery kit. For earlier accounts that have not yet moved to encrypted records, the backend uses application-level encryption for sensitive passport fields, synced country/day reading payloads and attachment contents; this does not mean that every database field is encrypted by Aevamo. On-device protection is described in §1.5.
Backup archives are encrypted before they are written to local disk or uploaded to the Railway-hosted store. Their recovery key is stored separately from the stored archives.
No system is perfectly secure. If you believe you have found a vulnerability, please email [email protected].
9. Changes to this policy
We update this policy when our data practices change. The effective date and last-updated date appear at the top. The current version is available at https://aevamo.com/privacy. If a change requires new consent, we will request it before using your data for that purpose.
TL;DR
Your travel records work locally without an account. With an account, they sync across your devices as encrypted copies we cannot read. Border detection uses device location with your permission, including while the app is closed if you allow it, and Android can also use the mobile network’s country. Border-detection coordinates are not synced; country/day readings are. Original files can contain location metadata. Anonymous crash reports, which you can switch off in Settings, tell us what went wrong but never who it happened to. We do not sell your data, share it with advertisers, or use location for ads. You can delete your account in Settings or request deletion by emailing [email protected].