CoveGuard Privacy Policy

Last updated: 29 October 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 anchor alarm and route guidance are computed on the device itself. A route to a destination (“Navigate here”, “Find shelter”, the way to a boat in distress) is computed by our server from the starting point (usually your position), the destination, your draught and mast height; it does not store them. Our server computes anchorage safety colours for whole areas — for that the app sends it only the rectangle of the areas you have subscribed to, not your position. On its own, without any step from you, your position leaves like this: (1) presence sharing — it is ON until you switch it off yourself (details below); (2) the data backup, while it is on (it is by default): logbook entries with your precise position — every hour while sailing, and on departure, anchoring, a stop, an alarm and man overboard — and, with the “Include GPS tracks” switch (on by default), whole voyage tracks too. This is a PRECISE record of where you have been, tied to your account, not a coarse anonymised location. Our server stores the tracks as compressed files in Cloudflare R2 storage; only you can get them after signing in — and the administrator, if you ask for it yourself in a support report (1.5); (3) the anchor watch, while it runs (details below); (4) position reports while sailing: when the app is open and the GPS has a fix, your precise position, course and the device's push token go out every 5 minutes (during navigation the planned route as well), so that the server can warn you about a change in the weather. The server keeps only the latest report and deletes it when you put the app in the background, at the latest about 6 hours after the last report. From every such report and from the anchor watch it also remembers the boat's last known position (rounded to about 100 m), speed and time for 12 hours, so it can warn you about storms and lightning even after you close the app; (5) weather and seabed queries for where you are: alerts about dangerous weather nearby and the wind forecast at the boat and for logbook entries (position rounded to 0.02°, about 2 km; precise for man overboard and when voyage recording resumes), the seabed slope under the boat (rounded to about 100 m, at most once per 50 m sailed; when our server has no seabed data of its own, it asks the EMODnet service about that point — without your account or your IP address) and the model pressure on the water (about 1 km). The server does not store these queries; their coordinates do remain in operational logs, though (see 4 and the retention table). None of points 4 and 5 can be switched off separately; switching notifications off stops only the message, not the sending. When you take a step yourself, your position leaves like this. Community reports, reviews, photos and place suggestions carry the place's position (reports on the map rounded to about 100 m); a review also stores whether you wrote it on site (within 300 m), and others see that. When you report a help request, your precise position goes with the report; the server works out your distance from the request so that misuse of reports can be detected. Searching for places and fuel stations, “Find shelter”, model wind at a point, the departure window, depths along a route and the AIS layer (an area around the boat) send your position only to compute the answer. When you answer an “Any space left?” query (you can only answer within 500 m of the place), your precise position is stored with the answer; it is deleted about 24 hours after the query was made, while the answer stays with your account for contribution points — and shows that you were nearby at the time. During navigation, or when you switch on watching for a saved route, the app sends the route (at most 24 points) with its name so the server can watch for bora on your way; it keeps it for about 48 hours after it was last sent. Private notes on places and on the map go out with their precise position and text; only you see them and they stay until the account is deleted. The manual “Sync” in the logbook sends fuel entries (place, amount, price) and voyage summaries with their start and end; it does not follow the backup switch, and they stay until the account is deleted. AIS sharing (off by default) sends the precise position of your receiver and of the boats it hears, yours included; the server keeps the position for 3 minutes. The live position link for family and friends is currently switched off in the app — a new one cannot be created; the position disappears from old links immediately when they are cancelled, and by the next day at the latest after they expire. Fuel prices and fuel station status: when you are signed in, you can report a fuel price per litre (diesel, petrol 95 or 100) and its currency at a fuel station, or the status there: no queue, queue, closed, out of fuel. Confirming a price someone else reported is a report too. The app attaches one point to the report — your phone's precise position and the time it was there: your current GPS position, or a point from the voyage track stored on your phone. The server only checks that the point is within 500 m of the station and at most 7 days old for a price (it is enough that you were there in the past week), at most 15 minutes for a status, and does not store it. What is stored is your account, the station, the fuel type, the price, the currency and the time of the report; for a status, your account, the station, the status and the time. With a price, others see your nickname and the day of the report, not the time; we show reports from the last 60 days, and they can be read even without signing in. A status is shown for at most 60 minutes, without any name, only with how many minutes ago it was reported. The report itself does show that you were at the station, though — for a price, within the week before you reported it (others can tell that from your nickname and the day), for a status, within the last 15 minutes. We delete price reports after one year and status reports after 7 days; if you delete your account, they stay until then without your account and nickname. Older price reports are not shown in the app (only the last 60 days), but we keep them for a year so that we can trace and remove abuse — made-up prices, for example — and compare prices between seasons. You cannot delete your own reports in the app; write to support at [email protected] and we will delete them. Presence: thanks to it, other CoveGuard sailors see your nickname and profile photo, your approximate position (the server rounds it to roughly 200 m before storing it) and how old it is, your course, heading and speed, your boat's name and type (its length only if you switch that on) and your account's technical identifier — the boat only to the extent you share it. Any signed-in user who has your area on their map (within 50 nautical miles of the map centre) can see you, and so can your friends — only those you have added each other with — anywhere; a signed-in sailor can also open your card with your nickname and boat by that identifier, for example after searching for your nickname, from anywhere. We show others your exact, unrounded coordinate if you switch on “Exact position” yourself under Menu → Profile → Presence & sharing, and in an emergency — distress (SOS), man overboard and a help request — ALWAYS, even if you have presence switched off or set to “Crew only”. Otherwise “Crew only” hides you from everyone — the app cannot yet tell who your crew is. Presence positions are not stored permanently on the server — the live one disappears on its own within 3 minutes of the last update. When you are on the water or within 50 m of it, the server keeps showing others your last position (rounded just like the live one) for at most 5 hours after you close the app, labelled with how old it is (“last online”); switching presence off removes both as soon as the server learns about it. To check for impossible position jumps, the server also keeps each device's last unrounded position for 5 minutes; it shows it to nobody. You switch all of this off with one switch under Menu → Profile → Presence & sharing — even without a signal: the app remembers the change and sends it at the next start at the latest. There you can also keep your position on and hide just the boat's name or type, or your course and speed. You switch the backup off under Menu → Settings & Account → Devices / Active sign-ins — all of it, or just the tracks (the “Include GPS tracks” switch); this deletes the server copy. Anchor watch: when you start it, the server receives the precise anchor position, an approximate radius, the chain length and the device's push token, and throughout the watch, roughly every minute, the boat's position, its distance from the anchor, the zone radius, whether it is muted and after how many minutes of silence the shore watch should alert (a choice in the watch menu), the shape of the watched zone (a sector or a drawn shape), the new anchor position if you move the anchor during the watch, and the state of the boat: whether an alarm is sounding or silenced on it and why, whether it is near the edge of the zone, the GPS state (accuracy and how long it has been without a position) and the phone battery (percentage and charging); the server keeps the state of the boat only for 5 minutes after the last report — every 30 seconds while you have the app open on another device. In addition, roughly every 10 minutes the watch asks the server for the weather at the anchor (forecast, radar, lightning and the nearest weather station) and sends the anchor position with it; the server does not store this query, and the phone uses the answer to decide how long it may wait for the position to return in calm weather. This is used to watch the weather and storms at your anchor, to warn you and your other devices, for the shore watch — if the anchor drags or the boat loses connection, we alert your other devices and the crew you have paired via Telegram, including the boat's last position — and so that an “Any space left?” query from sailors nearby can reach you. It cannot be switched off separately; it runs with every anchor watch. The service administrator can also see running watches in the operations console: your name and nickname, a shortened account identifier, the precise anchor position, the radius, the chain length, times and the number and age of push tokens, not your email; who opened the console and how many watches they saw is recorded. We delete the watch record — including the boat's last precise position — at the latest 31 days after the watch ends, and the boat track disappears on its own 48 hours after its last point. After an anchor watch and after a passage of at least half a mile — and when you report the weather yourself from the menu — the app sends a weather observation: the precise position (of the anchor, of where the passage ended, or of where you are), for a watch also the nearest anchorage, when the watch or passage started and ended, and what the forecast showed; if you fill in the questionnaire, your answer is added. It is used to improve storm and wave forecasts and cannot be switched off separately — the “Ask about forecast accuracy” switch controls only the questionnaire. After 90 days the server unlinks the observation from your account and rounds its position to a tenth of a degree (roughly 10 km); the anchorage, times and answers stay in it permanently, because we tune the wave and storm forecast with them. When you report that a storm is approaching, boats within 15 nautical miles get an alert with the precise place you are reporting from (for an anchor watch, the anchor position). When a phone with a barometer detects falling pressure and you have presence switched on, it sends the pressure, its trend, its position (rounded to roughly 200 m, exact with “Exact position”) and the app's installation identifier; from reports from several boats the server recognises an approaching storm, sends boats within 15 miles an alert with the place of the report and deletes the report after about 7 hours at most. In an emergency: a help request (all three levels) sends your precise position, the kind of emergency, a note, the number of people on board and possibly a photo. Boats with presence switched on within 10 nautical miles get an alert with your precise position; for distress, if there is nobody in range, it widens step by step to 20 and 30 miles. The list of requests around any place (within 60 miles) can be viewed by any signed-in sailor — including the kind of emergency, the note, the number of people, the precise position and the photo — and the request detail, even after it is closed, by anyone who knows its number (it comes with the alert); the detail also shows the positions of those coming to help you. When you set out to help someone from an alert (“I'm on my way”), your precise position and estimated arrival go out every 30 seconds (once from the request card, “I'm coming to help”), and anyone who knows the request number can see them. The server keeps requests and responses for as long as the account exists. A position you send in a message is seen by the recipient; when dealing with a report, the administrator can open the last 10 messages of a conversation, and this is recorded. Private messages and messages in area, group and help-request chats are deleted after 180 days. After a night with the anchor watch, the app sends which bay and when you anchored — without coordinates; only the month is stored in the night record (see 1.2a). And after a stay of at least 30 minutes at an anchorage, buoy or marina, it sends which place it was and on which day and hour you arrived and left — without coordinates; the server only adds it to the boat counts for that place (see 1.2b). Nights and stays are controlled by one switch, on until you switch it off on that device. The anchor watch analysis (1.2c) carries no geographic position — the boat appears in it only in metres relative to the anchor. After a voyage of a boat with a draft in its profile, it sends which cells of roughly 25–30 m the boat passed through while moving, with the draft and the month — without point coordinates or times (see 1.2d); this has its own switch, on until you switch it off. The app shares depths from the boat's echo sounder with the community until you switch off “Share anonymous depth data with the community” under Menu → Instruments (NMEA) (it is on by default): the precise position of each point goes out, with the depth, fix quality, draught, where you measure from and the transducer depth. The points are stored without an account and permanently, and of the time only the day they were stored; they follow one another, though, so they can be joined into a stretch of track — which is why we do not call it anonymous ourselves. For rewards, the account keeps a list of the roughly 150 m cells where you measured, with the day each was first sent; it disappears with the account. While the account exists, that list can reveal your points in a cell where nobody else measured that day. Switching the switch off still sends a batch that is already waiting on the phone.

1.2 Usage analytics

We do NOT collect usage analytics — which features you open, how long you use the app, how you move around in it. The app does not call any analytics, and automatic collection by the bundled Firebase Analytics library is switched off. For an operational overview (how many people used the app that day and how many of them were at sea), the server remembers a shortened fingerprint of your account (SHA-256) for at most 15 minutes on every signed-in request, and it also computes the same counts from data it already holds under the account (the device's version stamp, anchor watches, voyages and backed-up tracks, alarms and mutes from the logbook backup, the safety alert log). Only numbers are stored, without the account — five-minute counts for 90 days, daily counts permanently. The fingerprint is not anonymous — we can match it to the account. What does leave are crash and error reports (Firebase Crashlytics, Google) — including errors that do not crash the app, such as unavailable map tiles. Without them we would never learn about an error that crashes the app in the middle of a passage. A report contains a technical description of the error and the place in the code where it happened, plus the device model, OS version and an installation identifier, all of which Firebase adds itself. We do not attach your account, position, logbook or message content to it; we strip the map tile address, which would reveal the map area, from the error text. Apart from that, the only diagnostics that leave on their own are those of the anchor watch: after every watch, its analysis — how it worked, how long it ran and how the crew reacted to an alarm (1.2c). To improve the information about anchorages, a summary of a night with the anchor watch (1.2a) and stays for place occupancy (1.2b) also leave on their own, and for the “Where boats go” map so do the cells a boat with a draft filled in passed through (1.2d); what leaves on its own because an app feature needs it (backup, position while sailing and at anchor, weather queries, weather observations, app version) is described in 1.1 and 1.6. Any other diagnostics are sent only by you: when you write to support — and you see the exact content first (see 1.5) — or when you export the logbook files in Settings and pass them on.

1.2a Nights at anchor

After a night with the anchor watch, the app sends a summary of that night under your account: which bay and which night it was, roughly when you anchored and weighed anchor, how far the boat swung on the chain, how reliably the watch measured, whether and which alarm went off or nearly went off, whether you left or moved during the night, and which colour and hourly forecast we showed for that bay when you anchored. No coordinates or track are sent. It serves a single purpose — to find out whether our bay colours match reality. The legal basis is our legitimate interest in bay colours that do not mislead; it is not used for advertising or profiling. Only a coarse result is stored in the night record: the bay and the month, the forecast model and app version (without the build number), the colour we showed, where according to that forecast the wind mostly came from and into which bands its gusts and waves fell, whether you left before dawn or moved, into which bands the boat's swing, the length of the night and the reliability of the measurement fell, how many times an alarm went off (in total, for anchor dragging and for the zone) or nearly went off — three or more are not told apart — and how the night turned out. Your account, device, coordinates, exact date and the hourly forecast values are not stored in the record. Apart from checking your sign-in (and what applies to every signed-in request — recording the app version in 1.6 and the operational overview in 1.2), the server uses your account for two things only: so that the same night is not counted twice — for that it keeps, for 8 days, a fingerprint of the account, the bay and the date of the night that only the server can recompute — and so that one account cannot send too much; it remembers the number of sends per account for one day. The night record is deleted no later than 91 days after the night. Before that it is added to a summary that is kept permanently: counts of nights per bay by wind direction, gust and wave band, colour and outcome — with no date and no month. If a night is the only one in its combination, the summary still reveals that one such night happened in that bay. It is not fully anonymous, though. The server holds other records under your account of where and when you anchored — the logbook and track backup (on by default), the anchor watch record, the weather observation after the watch (with the precise anchor position and times, for 90 days), the boat's last known position for 12 hours and, for 8 days, the duplicate-check fingerprint — and the night could be matched with them. That is why we do not call it anonymous. Nights already sent, however, we cannot show you, correct or delete: they are not kept under your account and we cannot trace them back to it. If you do not want this, turn off “Help improve anchorage safety” in Settings → Data & Privacy; the choice applies only to that device and account, and after reinstalling the app it is on again. Nights not yet sent from that device will then not be sent even if you switch it back on. The same switch also covers stays for place occupancy (1.2b).

1.2b Place occupancy

After every stay of at least 30 minutes at an anchorage (within 500 m), a buoy or a marina (within 300 m), the app sends under your account which place it was, on which day and in which hour the boat arrived and left, whether it was anchoring with the anchor watch or a stop recorded in the logbook, and whether your boat is “new” at that place — that is, whether it has not stayed there from this device in the same period (in season, out of season, and separately for the day of the week) for a year. From this the server estimates how many different boats visited the place. Where your boat has already sent a stay is remembered in the long run only by your device. It is sent only after you leave, together with a fingerprint of the exact arrival and departure times (by which the server recognises the same stay sent twice); no coordinates or track are sent, and a stay for which the app finds no known place is not sent at all. It serves a single purpose — to find out when and how busy places get, and to show it at the places on the map. We show how busy each hour is, when the place usually fills up and how it compares with places nearby — never the number of boats — and we show it even without signing in; only for a place and period (season, off-season, day of the week) that has, over the last three years, at least 20 stays on 5 different days, at least 5 of them arrivals of a “new” boat. The same boat may be counted more than once — from another device, after reinstalling the app or under another account. The legal basis is our legitimate interest in sailors knowing when a place tends to be full; it is not used for advertising or profiling. The server does not store the stay as a record: it only adds it to the counts of boats at the place per day, hour and type of stay (anchoring with the watch, or a stop) — how many boats stayed there in a given hour, how many arrived, how many left and how many of them were “new”. Your account, device, coordinates and exact time are not stored, and no row about an individual boat is created. Apart from checking your sign-in (and what applies to every signed-in request — recording the app version in 1.6 and the operational overview in 1.2), the server uses your account for two things only: so that the same stay, the same hour of your boat at a place and the same boat as a new one (say from your phone and your tablet) are not counted twice — for that it keeps, for 8 days, fingerprints of the account with the stay, with the place, day and hour, and with the place and season (and day of the week), which only the server can recompute — and so that one account cannot send too much; it remembers the number of sends per account for one day. The counts are kept permanently. It is not fully anonymous, though: when a single boat stayed at a place in a given hour, the count can be matched with your logbook and track backup or with the anchor watch record the server holds under your account, and during those 8 days with the fingerprints too. Stays already counted, however, we cannot show you, correct or delete: in the counts they are not kept under your account and we cannot trace them back to it. This falls under the “Help improve anchorage safety” switch (1.2a) in Settings → Data & Privacy; switching it off stops this too. Stays from a time when it was off, or from before the app version that sends stays, are never sent — not even via the logbook backup from another of your devices: the app records with every anchoring and stop whether the switch was on, and sends only stays recorded with it on. Stays from the shore watch demo or from an anchor watch test are not sent.

1.2c Anchor watch analysis

After every anchor watch, the app sends under your account an analysis of how the watch worked: how it was set up (the mode, how the anchor position was set and how far from the boat its pin was, where the anchor went down according to the approach track and around which point the boat swung (both in metres from the pin), the radius and shape of the zone, chain and boat length, depth, whether it was a buoy and whether it was a test), how many GPS positions came in, how accurate they were and for how long they were missing, how far and in which direction the boat moved from the anchor, every alarm (the reason, the detector's confidence and flags, the score, the distance, when it happened after the watch was started, how long it lasted and how it ended, silencing — from ashore too —, the siren delay and your answer to “Did the anchor drag?”), stretches when the earlier analysis of the boat's movement would have reported dragging (the minute after the watch was started, the length and the farthest distance from the anchor — it does not sound the siren), every GPS dropout and the hourly wind forecast the app showed when you anchored (if it has one; only as bands of speed and gusts — under 15, 15–22, 22–34 and from 34 knots — and the direction to the nearest eighth of the compass). Further, the battery level at the start and at the end, whether the phone was charging, the state of the permissions the watch relies on (battery optimisation exemption, notifications, full-screen notifications, precise location), the phone's manufacturer, model and Android version, and the app version (without the build number). For alarms, dropouts and moments when the boat came close to the edge of the zone it adds a piece of the track from ten minutes before to ten minutes after. The boat appears in it only in metres north and east of the anchor — no coordinates, bay or date are sent; of the time, only the month and the hour the watch was started. It is sent at the earliest about half an hour after you weigh anchor, and if “Did the anchor drag?” has not been answered yet after an alarm, it waits for the answer for one day at most. It serves a single purpose — so that the watch raises fewer false alarms, does not stay silent when the anchor really drags, and lasts the whole night on different phones. The legal basis is our legitimate interest in a reliable anchor watch; it is not used for advertising or profiling. Everything listed above is stored; your account, a device identifier and the number by which the server recognises a repeated send are not. Apart from checking your sign-in (and what applies to every signed-in request — recording the app version in 1.6 and the operational overview in 1.2), the server uses your account for three things only: so that the same analysis is not counted twice (for that it keeps, for 8 days, a fingerprint of the account and the analysis that only the server can recompute), so that one account cannot send too much (it remembers the number of sends per account for one day), and so that our own tests can be left out: for an analysis from our own accounts only a flag saying it is ours is stored, not whose it is. The analysis is deleted no later than 12 months after the watch. It is not fully anonymous, though: the month, the hour the watch was started and its length could be matched with the logbook and track backup, the anchor watch record or the weather observation after the watch, which carries its exact start and end — all of which the server holds under your account (1.1). With a forecast archive, the hourly wind bands could also be used to estimate the day; and analyses the app sends together can be recognised in the database as one batch. That is why we do not call it anonymous. Analyses already sent, however, we cannot show you, correct or delete: they are not kept under your account and we cannot trace them back to it. If you do not want this, turn off “Help improve the anchor watch” in Settings → Data & Privacy; the choice applies only to that device and account, and after reinstalling the app it is on again. Watches from a time when it was off, or from before the app version that sends analyses, are never sent. Your answer to “Did the anchor drag?” stays in the logbook either way.

1.2d Where boats go

If a boat has a draft filled in its profile, after a voyage the app sends under your account which cells of a roughly 25–30 m grid the boat passed through while moving — only where it was going faster than 1.5 knots and the GPS was more accurate than 10 m; points you trimmed off, removed or moved in the voyage editor are not used. It sends this at the earliest half an hour after the voyage ends and at the latest within 14 days; a voyage from the previous month, however, the server accepts only until the 14th of the new month. With that it sends the draft of the boat that was active when the voyage ended, rounded to 0.1 m, the month of the voyage and a random voyage number, created on the phone when the voyage ends, by which the server recognises a repeated send of the same voyage. The cells go out as a set sorted by number, not in the order they were passed — the coordinates of individual points, the order, times, speed and the boat's name are not sent. A drive recorded in the in-car test recording mode, a track restored from a backup and a voyage split or merged in the editor are not sent. A boat without a draft sends nothing; the substitute draft that route planning works with is not used. It serves a single purpose — the “Where boats go” map, which shows sailors where at least five boats passed and with what draft (in half-metre classes). The legal basis is our legitimate interest in sailors knowing where boats usually go; it is not used for advertising or profiling. Only an account with a verified email address that is at least 7 days old can contribute; otherwise the server does not accept the voyage and the app tries to send it later. One account contributes at most 20,000 cells a day — a voyage above that limit the app sends another time, and from a voyage with more cells it sends only the first 20,000 by cell number. A voyage that fills an area instead of a line (more than a quarter of its at least 30 cells have all eight neighbouring cells occupied) is rejected by the server as a whole. The server does not store the voyage as a record. For each month it keeps, for each cell, only 16 slots holding the largest draft that fell into them that month; which slot your boat falls into is decided by a fingerprint of your account and the cell made with a random key for that month. That key is kept only in the memory of Redis on our server and in its working file on the same disk (it is not part of the nightly backup; the database holds only a fingerprint of it, from which the key cannot be computed). The month's cells are kept with the month, but without your account, device or time. On the 15th of the following month we close the month: the cells at least five boats passed through in it — near a marina (reaching at least about 1.5–2 km from it, up to about 5.7 km depending on its position in the grid) at least three — go into the map; all the cells of that month and its key are deleted (the key disappears from Redis's working file at most about a quarter of an hour later), and after that not even we can tell which slot belonged to whom. If the key disappears earlier (for example in a server outage), we accept nothing more until the end of the month, so that the same boat is not counted twice. Apart from checking your sign-in, verified email and account age (and what applies to every signed-in request — recording the app version in 1.6 and the operational overview in 1.2), the server uses your account for three things only: so that within one month your boat always takes the same slot in a cell (ten voyages along the same route, or a phone and a tablet under the same account, count once), so that the same voyage is not counted twice (for that it keeps, for no more than 15 days, a fingerprint of the account and the voyage number that nobody can compute without the month's key), and so that one account cannot send too much (it remembers the number of sends and cells per account for one day). For a cell, the map shows the draft at least five boats (three near a marina) passed with in that month, not the largest one, and only in half-metre classes rounded down (a draft of 2.4 m falls into the 2–2.5 m class): a single deeper boat thus does not give its route away by colour, and the map never shows a larger draft than passed there. A cell from several months carries the highest of the monthly classes. Cells that look forged can be removed from the map by an administrator, reversibly; until they are restored the map does not show them, and months that were running when they were removed do not bring them back. Cells whose draft does not match the depth map — the draft class is more than 0.5 m greater than the greatest EMODnet depth around the cell — do not go into the map until a person checks them; until then they are kept aside with the month, without an account. In the tidal areas of the Atlantic, where the depth map refers to the lowest low tide, and where we do not know the depth, this is not checked. The map changes when a month is closed, so once a month, so that it cannot reveal when a given boat sailed; in between only by an administrator's action (removing, restoring or approving a cell), which reveals nothing new about voyages. Anyone can see it, even without signing in. The map's cells are kept permanently, without an account, time or month. It is not fully anonymous, though. Until the month is closed, in the stored data the cells of one voyage in a remote place where nobody else went form a stretch of the track of a boat — just as with echo-sounder depths — and the map's cells where only a few boats went that month form a stretch of their shared track. Someone who gets four verified accounts at least a week old (two near a marina) in the same month and sails them — or sends made-up voyages for them — through a place where another boat sailed can read part of its route — and the class of its draft (to the half metre) — from the next map; the daily limit and the shape check only make that harder. In the same way, five accounts acting together can write a passage that does not exist into the map — which is one more reason the map never claims the water there is safe. While the month's key exists, the server can check for a cell whether your boat could have fallen into it; and the logbook and track backup the server keeps under your account if you have it on (1.1) carries the same voyage precisely. That is why we do not call it anonymous. Cells already sent, however, we cannot show you, correct or delete: they are not kept under your account and we cannot trace them back to it. If you do not want this, turn off “Contribute to the ‘Where boats go’ map” in Settings → Data & Privacy; you will also find it under Menu → Instruments (NMEA). It is on by default, applies only to that device and account, and after reinstalling the app it is on again. Before the first voyage is sent, the app tells you once, with a “Turn off” button. Voyages that ended while it was off, or before the app version that sends them, are never sent.

1.3 Vessel data

Vessel details you enter (name, type, dimensions, engine, tanks, cruising speed and consumption, MMSI, IMO, call sign, flag) are stored on the device. They reach our server with the data backup (on by default) and are tied to your account. For the presence card, the app also sends the name, type and length of your ACTIVE boat — but only the fields you let others see: name and type by default, length only if you switch it on (Menu → Profile → Presence & sharing, where you can also hide just the name or just the type). With presence switched off or “Crew only” selected, nothing is sent. Beam, draught, engine and MMSI are never shared this way. The active boat's draught does show with an anchorage or buoy review, though, and its type and length with a shore-place review, when you switch it on for that review (off by default); the boat name goes into alerts to your devices and to your crew via Telegram (see 4), and the active boat's name, type and dimensions go into the state snapshot when you attach it to a support report (1.5). 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, a nickname (required) and, optionally, your name; with Google sign-in the name comes from your Google account and is overwritten at every sign-in. 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. Under the account we further keep your profile photo (others see the nickname and the photo), the creation date, whether your email is verified and whether you have a password, your Firebase identifier, whether you can be found by nickname, the weight of your reports (moderation adjusts it), any block, your plan and, for beta testers, since when and from which app build they have been testing the beta; if the administrator grants you a rank, also who granted it, when, and their note. Of the account details, only a record that an account with a given technical identifier was deleted, and when, remains after deletion — without the email address; what else stays without your name is described under the right to erasure in section 5.

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); the email support receives from it also carries your account's internal identifier, the kind of report and the time it was received. Sent only if you switch it on yourself on that screen (everything is off by default): a snapshot of the app and device state — version and build stamp, operating system and its version, installation identifier, battery and connection type, permissions, the active boat's name, type and dimensions, chosen weather areas, anchor watch settings (chain length, radius, start time, without the anchor position), backup status with sync times and the size of offline data —, a coarse position rounded to roughly 11 km, and the app activity log (a timeline of app starts and switches, errors and the addresses of map tiles that failed to load — these can reveal the map area, including the area around the anchor). 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 (the activity log may, however, contain addresses of map tiles from around it, see above). 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 stored in Cloudflare R2 storage, are served only through our server after signing in, and 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 five values for your device: the version number, the app build stamp, 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 and are written at most once a day (once more after an app update). The last contact is stored only as a day — the stored state therefore cannot tell what time of day you set out; the build stamp carries the time we built the app, not when you use it. Why: so a warning can be aimed at a faulty version instead of everyone, so we can tell when it is safe to stop supporting an old version, to count how many accounts opened the app that day (the operational overview, 1.2), and to send safety and distress alerts in your app's language; the administrator sees an overview of devices by version in the console. 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 signed-in 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. For a signed-in device we further store the app installation identifier (a random number the app creates on first start), the operating system name and version (for example “Android 14”), sign-in and sign-out times and the reason for signing out, and the push notification token (see 6); you can see your devices in Menu → Settings & Account → Devices / Active sign-ins. Neither position nor IP address is stored in the device record. 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 version values 90 days after the device was last active; the device record (even a signed-out one) stays until the account is deleted, which removes it 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; the exceptions are the night-at-anchor summary, which is kept permanently and is not fully anonymous (1.2a), the boat counts for place occupancy, which are kept permanently and are not fully anonymous either (1.2b), weather observations, which after 90 days stay without the account but with the anchorage and time (1.1), and echo-sounder depths, which stay permanently without an account but can be joined into stretches of track (1.1). A copy may survive longer in backups, but for 168 days at most: the rotation keeps 7 daily, 4 weekly and 6 monthly sets, older backup sets and archives are deleted by date, and the 168 days also cover the copies held by our provider — the daily backup of the server's whole disk, which Hetzner keeps for 7 days, and the daily snapshots of the backup storage, which are kept for 10 days. Backups sit unencrypted on our own server, with an encrypted copy on a Hetzner Storage Box; they also include copies of the files from Cloudflare R2 storage (photos, report screenshots, tracks) — a file deleted in R2 disappears from the copy at the next nightly backup and lives on in older sets for those 168 days at most. Hetzner's daily disk backup also includes the in-memory database with live presence positions, so these too may remain in it for at most 7 days.

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 — you can be seen by any signed-in user who has your area on their map (up to 50 nautical miles) and by your friends (only those you have added each other with) anywhere: your nickname and profile photo, your approximate position (rounded to roughly 200 m) and how old it is, your course, heading and speed, your boat's name and type if you share them (its length if you switch that on), and your account's technical identifier. A signed-in sailor can also open your card with your nickname and boat by that identifier — for example after searching for your nickname — from anywhere. Your exact, unrounded coordinate is sent to them if you switch on “Exact position” yourself, and in an emergency (distress, man overboard, a help request) ALWAYS — even if you have presence switched off or set to “Crew only”. After you close the app on the water or within 50 m of it, they still see you for at most 5 hours as “last online”. You can switch it off in Menu → Profile → Presence & sharing.
• Service providers: the server and database run on Hetzner Cloud in Nuremberg (Germany); files (photos, report screenshots and backed-up GPS tracks) sit in Cloudflare R2 storage in the EU jurisdiction; an encrypted copy of the backups (on our own server they are unencrypted) sits on a Hetzner Storage Box; and transactional emails 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. Google sees the content of a notification in readable form: for an anchor alarm sent to your other devices, the boat name and its exact position; for the shore watch, the boat's last exact position (without the name); for a help request, the exact position, the kind of emergency and the text of the person asking (sent to boats nearby); for a storm cell from the radar, its position and its distance and direction from the boat (from which the boat's position can be worked out); for bora and strong wind, the coordinates of your position; for a weather change during a passage, the boat's exact position; for a confirmed storm, the place of the report; for an “Any space left?” query, the place name and the answer including the responder's note; for a message from another sailor, the sender's nickname and the beginning of the text; for a friend request and its acceptance, the nickname; and for system messages, their full text. Your email, password and optional name go to Google when you register, and your email and password on every sign-in. When the app crashes or runs into an error, the error description goes there too (we remove the map tile address from it). Our server's operational log is stored there as well: it contains the coordinates of weather, seabed and route queries and, for individual events, the account's technical identifier. Recognising the boat name, MMSI and call sign from a photo of a document runs on your phone with Google ML Kit — the photo isn't sent anywhere. It starts only with a step of yours: scanning a document. ML Kit then sends Google operational data: the phone's manufacturer, model and OS version, the app's name and version, an installation identifier, and processing speed, size and error codes. After a quiet night at anchor or after a passage, the app asks you to rate it on Google Play at most three times, at least four months apart. The window is shown by Google; the app does not learn whether or how you rated it.
• 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 pair a chat under Menu → Safety & distress → Telegram for crew. Then a message goes there on every anchor alarm (with the boat name, if the app knows it) and when the watch loses connection, always with a link to the boat's position. That link points to Google Maps: whoever taps it sends the boat's position once more, to Google, together with their own IP address. We keep copies of the sent messages for 30 days; for a paired chat we remember its numeric identifier (for a private chat, that is the identifier of that person's Telegram account) and its title, which is often the name of the person you share it with.
• 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, and the encrypted connection (HTTPS) ends there: it sees the content of every request and response — including your email and password at sign-in, messages, positions and the backup — and your IP address; it passes each request on to our server encrypted again. For some queries the coordinates are in the address itself. And files sit there too: its R2 storage (in the EU jurisdiction) holds place photos, photos attached to community reports, profile pictures, screenshots attached to support reports and backed-up GPS tracks; Cloudflare also keeps public photos in its cache for up to 7 days. The server and database stay at Hetzner in Nuremberg.

Which countries these companies process the data in is something I do not have confirmed for all of them, and I am not going to make it up. What is verified: our server and database stand in Nuremberg, Germany, transactional emails go through Seznam.cz, and files (photos, screenshots and tracks) sit in Cloudflare R2 storage in the EU jurisdiction — Cloudflare does not guarantee a specific data centre and I will not invent one. 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; the account and the data kept under it are removed immediately and irreversibly — including the logbook and track backup, devices, friends, help requests, community reports on the map (obstacles, storms, fuel…), depth credits, barometer reports, notes, fuel entries and voyage summaries and private messages (the whole thread, so for the other person too); a group you created disappears for its other members too. What remains: photos, reviews (without boat details), comments, place problem reports, place suggestions and Discover error reports — without your name —, fuel price and fuel station status reports without the account (prices for a year, statuses for 7 days after they were made), messages in area, group and help-request chats without an author (until 180 days after they were sent), weather observations without the account (their position is coarsened 90 days after the observation), echo-sounder depths (they carry no account), records under 1.2a–1.2d, which we do not keep under your account, a record that an account with a given technical identifier was deleted, and when, report emails in the support mailbox (we delete them on request) and copies in backups (168 days at most). The boat track from the anchor watch is deleted immediately (should that fail, it disappears on its own within 48 hours), the night and stay fingerprints live on for at most 8 days, the voyage fingerprints for the ‘Where boats go’ map for at most 15 days and technical keys with the account identifier, without any position, for at most 30 days.
• Right to data portabilityExport your logbook and GPS tracks — in Menu → About & legal → Data & Privacy → Export my data; you get their database files (SQLite). Saved routes can be exported as GPX in the route detail. Boats and crew are not in the export yet; if they are backed up on the server, ask us at [email protected] and we will send them to you.
• 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 of the backup (what remains is described in 1.1). 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]. In the app, you will find export and account deletion in Menu → About & legal → Data & Privacy, presence sharing in Menu → Profile → Presence & sharing, the backup in Menu → Settings & Account → Devices / Active sign-ins, and the switches for night summaries, stays and anchor watch analyses in Settings → 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. We store your device's push notification token under your account and send it along with the anchor watch and your position while sailing, even if you do not allow notifications.

7 Security

The app always talks to our server over an encrypted connection (HTTPS/TLS). The encrypted connection ends at Cloudflare, which passes each request on to our server encrypted again (see 4). Private data is tied to your account: without signing in, nobody can reach it through our API. Published content — reviews (with the nickname and, if you show your boat, its draught for an anchorage or buoy and its type and length for a shore place), place photos, community reports, fuel prices (with the nickname and the day), fuel station status and profile photos — can be read without signing in. The web operations consoles require a separate operations account with its own password and a one-time code from an authenticator app, and their sessions can be revoked at any time. Part of the same tasks — an overview of accounts with their email addresses, support reports including a look into your data under 1.5, moderation and blocking — can also be done in the in-app administration, though; a regular account with the administrator flag signs in there, so far without a second factor. What we do NOT claim: we do not encrypt your data on the server — it sits in the database in readable form, protected by server access control rather than by a cipher. Files (photos, screenshots, tracks) sit in Cloudflare R2 storage, protected by access keys rather than by our cipher, and private files — GPS tracks and support report screenshots — are served only through our server after signing in. 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