CoveGuard Privacy Policy

Last updated: 7 September 2026

CoveGuard ("we") is committed to protecting and respecting your privacy. This policy explains how we collect, use, disclose and safeguard your data when you use the CoveGuard mobile app and related services (together, the "Service"). Please read this policy carefully. If you do not agree with it, please stop using the Service.

1 What data we collect

1.1 Location data (GPS)

The calculations run on the device itself — navigation, the anchor alarm and bay ratings. Location reaches our servers in four cases: (1) backed-up sailing tracks, when track backup is on — this is a PRECISE record of where you have been, tied to your account, not a coarse anonymised position; (2) community hazard reports and contributions you submit yourself; (3) a live position link for family and shore watch, while they are switched on; (4) presence sharing — the only one that runs without you switching it on: it is ON until you switch it off. Through it, other CoveGuard sailors see your nickname and profile photo, your approximate position (the server rounds it to roughly 200 m before storing it), your boat's name and type, and whether you are under way or stationary. We send the exact, unrounded coordinate in ONE case only — when you trigger distress (SOS) yourself: the rescuers around you receive it, because otherwise they could not find you. Boat length, destination and crew count are not shown unless you switch them on yourself. The presence position is not stored permanently — it disappears within 3 minutes of the last update. You can switch all of it off with one toggle in Menu → Profile → Presence and sharing, where you can also keep the position but hide just the name or the type. Track backup is switched off in Settings → Devices; that deletes the server copy of your tracks.

1.2 Usage analytics

We do NOT collect usage analytics — which features you open, how long you use the app, how you move around it. There is no code for it in the app and Firebase Analytics automatic collection is switched off. What does leave the app are crash and error reports (Firebase Crashlytics, Google). Without them we would never hear about a bug that takes the app down mid-passage. A report contains a technical description of the error and the place in the code where it happened, plus the device model and OS version that Firebase adds itself. We do not attach your account, your position, your logbook or the contents of your messages. This is the only diagnostic that leaves on its own. Everything else you send yourself, by writing to support — and you get to read the exact text first (see 1.5).

1.3 Vessel data

Vessel details you enter (name, LOA, beam, draught, engine type) are stored on our servers so we can personalise calculations and keep your data available across devices. This data is tied to your account. Two of them — the boat's NAME and TYPE — are additionally shown to nearby sailors when presence sharing is on; it is on until you switch it off, in Menu → Profile → Presence and sharing, where you can also hide just the name or just the type. Boat length and crew count are shown only if you switch them on there yourself. Beam, draught, engine type and MMSI are never shared this way. Vessel and crew documents, including scans and photos (insurance, licence, certificate, passport), are the exception: they stay on the device. They are never sent to our servers and are not backed up — we deliberately do not collect such files. That also means we cannot restore them: reinstalling the app, clearing its data or losing the phone deletes them for good.

1.4 Account data

When you create an account we collect your email address and, optionally, your name. Your password is not stored on our side in any form, not even hashed — accounts and passwords are handled by Firebase Authentication (Google), see section 4. On our side the account holds only the email address and, optionally, a name and a nickname.

1.5 Support reports

When you write to support (Menu → Help & support → Write to support), the report does not leave from your own mailbox — our server receives it and sends it on. Always sent: your message, the report number, the email address of your account (that is how we match the report and can ask follow-up questions), the address you type into the “Where should we reply” field, and technical app details (version, beta/release channel, language). Sent only if you switch it on yourself on that screen: an app state snapshot (version, permissions, free disk space), a coarse position rounded to roughly 11 km, and the app activity log. You can expand and read the exact text before sending — the preview is the same text that reaches us. Reports go to [email protected]. You get a copy by email at your account address so you can verify it really went out; it contains only your message and the report number — we do not send the snapshot or the activity log back to you. If you type a different address into “Where should we reply”, the copy still goes to the account address — we deliberately do not send confirmations to a third-party address. A report NEVER contains: crew, the contents of messages, logbook or notes, MMSI, call sign, vessel flag, or the anchor position. Credentials and tokens are filtered out at write time, before anything is stored. That covers what the app adds to a report BY ITSELF. A screenshot you attach yourself (at most three per report) is the exception: it leaves exactly as you see it — we blur nothing in it and the password and token filter cannot look inside an image. It usually shows your position, and often crew names or the text of messages, so look it over before you attach it. Screenshots are wiped after 90 days, the same as the state snapshot and the activity log. AT YOUR REQUEST WE MAY LOOK INTO YOUR DATA ON THE SERVER. When you tell us your logbook or an export looks wrong, we need to see that data — and the report itself does not carry it (see above). Four conditions apply at once: we only look when you agree in writing; only for that one report, never for the account in general; only while the report is open (closing it ends the access); and every access is recorded — who looked, when, and for which report. You can withdraw the consent at any time, just write to us. That opens up the logbook, the voyage list and GPS track points. It does NOT open notes, crew, vessels or routes. Data obtained this way is used SOLELY to resolve your report — not to analyse how the app behaves in general; that would need your separate consent or data with no link to you.

1.6 Technical app and device data

So we can tell which app version a device runs, the server stores four values for your device: the version number, the channel (beta or release), the app language (only “cs” or “en”) and the day we last saw the device. They come from the headers of an ordinary request, are written at most once a day, and the timestamp has DAY resolution — the stored state therefore cannot tell what time of day you set out. Why: so a warning can be aimed at a faulty version instead of everyone, and so we can tell when it is safe to stop supporting an old version. The legal basis is legitimate interest — running and securing the service. These values are never used for advertising or profiling. For a signed-in device we additionally store one technical FINGERPRINT that lets us tell it is the SAME device after you reinstall the app or update Android. It is not a readable number: we take a system identifier that on Android 8 and later is unique to the combination of our app, the user and the device (another app gets a different one) and store ONLY its irreversible SHA-256 fingerprint, never the original value. It serves nothing but pairing your own sign-ins — without it the app would tell you "too many devices" after a system update and you would have to sign one out by hand. It is not linked across accounts and is never shared; it is not shown under "My devices", because it would tell you nothing you cannot already see. Apart from it we do not store your position, IP address, or any further device identifier beyond the device name and type you can see under "My devices". No usage history is built: every later contact OVERWRITES the previous record, so the database only ever holds the latest state, never a row per day. We delete the values 90 days after the device was last active, and deleting your account removes them immediately.

2 How we use your data

• To provide and improve the CoveGuard Service, including navigation aids, weather integration and safety features.
• To personalise content, calculations (fuel, tides, provisioning) and recommendations based on your vessel profile.
• To detect and fix bugs, crashes and performance issues.
• To send transactional emails (e.g. password reset).
• To comply with legal obligations and enforce our Terms of Service.
• To handle your support enquiries.

We do not use your data for targeted advertising and we do not sell your personal data to any third party.

3 Data retention

Once the retention period expires, data is permanently deleted or irreversibly anonymised. A copy may survive longer in backups: the rotation keeps 7 daily, 4 weekly and 6 monthly sets, so the oldest copy can be up to 168 days old. Backups sit on our own server, with a copy on a Hetzner Storage Box.

One thing that is easy to leave unsaid: the copy of your report went out by EMAIL and sits in the support mailbox at our email provider. When the report disappears from our database after 12 months — or when you ask us to erase it sooner — THAT EMAIL IS NOT AFFECTED. It has to be deleted by hand in the mailbox. If you want it gone too, write to [email protected] and quote the report number.

4 Data sharing and disclosure

We do not sell, trade or rent your personal data. We may share data only in these limited cases:

• Other CoveGuard sailors: with presence sharing on — and it is on until you switch it off — boats around you see your nickname and profile photo, your approximate position (rounded to roughly 200 m), your boat's name and type, and whether you are under way or stationary. Your exact, unrounded coordinate is sent to them only if you trigger distress (SOS) yourself. You can switch it off in Menu → Profile → Presence and sharing.
• Service providers: the server and database run on Hetzner Cloud in Nuremberg, Germany, and transactional e-mails go through Seznam.cz. A detailed list of everything that leaves our server follows right below these points.
• Legal requirements: where required by a valid court order or government mandate, or to protect the rights and safety of users.
• Business transfer: in the event of a merger or acquisition, your data will be transferred with equivalent privacy protection.

Where your data goes

Some of your data has to leave our server — without it the alarm would not arrive and the map would not draw. Here is the honest list. We established it by measuring our own code, not by copying someone else's policy.

• Google (Firebase). Delivers push notifications and holds accounts. We put the boat name into the notification, and for an anchor alarm its exact position; for a message from another sailor, the sender's nickname and the beginning of the text — Google sees all of this in readable form. Your e-mail and password go to Google when you register and on every sign-in. When the app crashes, the error description goes there too, and so does our server's operational log, which today contains the coordinates of weather queries.
• Map layers: Esri, OpenStreetMap, OpenSeaMap and EOX. When you look at the map they receive the tile number and your IP address. That is not your GPS fix but the viewport you are looking at — and that is usually where you are; at the closest zoom it is enough to identify the pier. When you download an area for offline sailing, those tiles reveal the whole area you plan to sail.
• Overpass (OpenStreetMap). Fetches buoys, lighthouses and wrecks nearby. It receives a rectangle around the map centre, rounded to a grid, and your IP address. It stops when you turn the seamark layer off.
• Wikimedia. Place photos. It receives the file name — indirectly, which place you are looking at — and your IP address.
• Telegram. Only when you turn on the shore watch. Your crew receives a message with the boat name and a link to its position. That link points to Google Maps: whoever taps it sends the boat position once more, to Google, together with their own IP address.
• Open-Meteo and EMODnet. Marine weather and seabed information. They receive the coordinates of your query.
• Cloudflare. All traffic between the app and our server passes through it. For some queries the coordinates are in the address itself, so Cloudflare sees them. Place photos and sailed tracks are NOT stored with them — those sit directly on our own server in Nuremberg.

Which countries these companies process the data in is something I do not have confirmed yet, and I am not going to make it up. What is verified: our server and database stand in Nuremberg, Germany, and transactional e-mails go through Seznam.cz. For the other recipients I will add the country once I have it confirmed by them — not guessed.

What never leaves the app: scans of the vessel documents and the photo album. They stay on your phone.

5 Your rights under GDPR

If you are located in the European Economic Area, the United Kingdom or Switzerland, you have the following rights:

• Right of accessRequest a copy of all personal data we hold about you.
• Right to rectificationCorrect inaccurate or incomplete data at any time in your account settings.
• Right to erasureRequest deletion of your account and associated data. You start it in Menu → Profile → Account settings → Danger zone; it happens immediately and irreversibly.
• Right to data portabilityExport your logbook, vessel data, routes and crew as a JSON archive — in Menu → Data & Privacy → Export my data.
• Right to restriction of processingRestrict processing of your data while your complaint is being investigated.
• Right to objectObject to processing based on legitimate interests.
• Right to withdraw consentWhere processing rests on consent (logbook and track backup, presence sharing, the optional parts of a support report), you can withdraw it at any time in the Menu — withdrawing deletes the server-side copy. Withdrawal does not affect processing that already took place.
• Right to lodge a complaintContact a supervisory authority — in the Czech Republic that is the Office for Personal Data Protection (Úřad pro ochranu osobních údajů, Pplk. Sochora 27, 170 00 Prague 7, uoou.gov.cz). You may go to them directly, without writing to us first.

To exercise any of these rights, email us at [email protected] or use the in-app controls in Menu → Data & Privacy.

6 Local storage and device permissions

CoveGuard stores settings, cached tiles and your offline logbook in the device's local storage. We do not use any tracking cookies. Push notification tokens are stored only when you grant notification permission.

7 Security

The connection between the app and our servers is always encrypted (HTTPS/TLS) — an unencrypted request is refused and redirected to the encrypted one. Your data is tied to your account: without signing in, nobody can reach it through our API. Our operations consoles cannot be opened with a regular user account — they require separate operations accounts with their own password and a one-time code from an authenticator app, and their sessions can be revoked at any time. What we do NOT claim: we do not encrypt your data on the server — it sits in the database and in file storage in readable form, protected by server access control rather than by a cipher. We do not run regular penetration testing and we have no separate roles for operations access. No system can guarantee absolute security. If any of this changes, this text will change with it; we will not promise it in advance.

8 Children's privacy

CoveGuard is not intended for children under 16. We do not knowingly collect data from children. If you believe a child has provided us with personal data, email [email protected] and we will delete it.

9 Changes to this policy

We may update this privacy policy from time to time. We will announce material changes with an in-app notice at least 14 days before they take effect. By continuing to use the Service after the effective date, you agree to the revised policy.

10 Contact