Divemap — Privacy Policy
Effective date: 28 Sept 2026 Contact: [email protected]
Divemap is run by one person as a hobby project under the Tern Diving banner. This policy describes what it collects, who can see it, and what is done with it. It is written to be read, not to be skimmed past.
Most privacy policies exist to reassure you that your data is being kept to itself. This one is mostly about the opposite: what you contribute to Divemap gets shared, on purpose, because that is what the site is for. Your email address, your password, and your raw logs stay private. The dive data does not, unless you tell it to.
1. Who is responsible
Divemap is operated by an individual in Washington State, USA. For privacy questions, contact [email protected].
2. The premise: sharing is the point
Divemap is not a private dive log with a map bolted on. It is a shared chart that divers build together, and it only works because people put things into it.
Consider what the site is actually made of. Somebody had to go find that wreck. Somebody ran that line and came back to say where it starts. Somebody logged a hundred tracks across the same stretch of bottom so that the hundred-and-first diver could see which approach works and which one puts you in the silt at 140 feet with no reference. Somebody uploaded their calibration runs so that everyone’s headings could be corrected against a common reference. None of that has any value sitting on localhost. It has value when the next diver can read it.
So the default here is to publish. Data you contribute is expected to become part of the shared map — visible to other divers, folded into aggregate products, and used to make the chart better. And the divers who did the work get credit for it: reports, discoveries, and site observations are attributed to the diver who submitted them, under the display name they choose, because people who go out and run the lines should have their names on that.
Two things follow from this, and they’re both in the rest of this document:
- You have controls (Section 5). If there’s a dive you don’t want shared, log it and mark it private. That’s a supported, normal thing to do.
- Credit is not the same as surveillance (Section 4). Other divers see that a diver went somewhere. They do not get to browse where you have been.
3. What is collected
Account information. A username, a display name, an email address, and a password hash. Optionally, whatever you choose to put in a profile.
Contributed content. Wreck and obstruction reports, landmarks, lines, waypoints, site notes, photographs, and any descriptive text you enter.
Dive logs and tracks. Dive profiles, timestamps, headings, depths, positions, and dead-reckoning or sensor data, whether entered manually or uploaded from a device such as a DPV-Nav unit.
Sensor and calibration data. Raw and processed IMU, magnetometer, depth, and flow data uploaded from devices, including calibration runs.
Technical logs. IP address, browser user-agent, request timestamps, and error traces, kept in ordinary server logs.
There is no advertising, no ad tracking, and no sale of personal information to anyone, for any purpose. There are no third-party trackers or analytics beacons embedded in the site.
4. Who can see what
Data falls into three tiers.
Tier 1 — Public, and credited to your display name
- Wreck, obstruction, and hazard reports
- Named landmarks and waypoints you publish
- Lines, moorings, and permanent features
- Site notes, descriptions, and photographs
- Corrections and edits you make to shared features
Anyone who can see the map can see these, along with the display name of the diver who submitted them and when. This is permanent and public. Assume it is archived, scraped, and mirrored by third parties beyond our control.
Attribution here is the point, not a side effect. It gives credit to the diver who found the thing, it lets other divers ask them about it, it lets bad or stale entries be traced and corrected, and it lets contributions be weighted sensibly when the chart is built.
It also means a series of attributed reports says something about where you dive. That’s the deal you’re accepting when you publish a find under your name. Your display name is yours to choose, and you can change it at any time in your account settings: use your full name if you want to be recognized, or something that isn’t your name if you’d rather not be personally identifiable. A change applies to everything you’ve already published as well as what comes next, but copies of the map taken before the change keep the old name. Display names must be unique, so nobody can publish under yours.
Tier 2 — Pooled: a diver went there, not which diver
- Dive tracks and route data
- Depth profiles and time-in-water
- Navigation telemetry and derived position estimates
These are never shown to the general public in any form. Only signed-in, registered divers can see route data, and even they don’t see it as individual dives: no user can browse where a given diver has been. They are merged into aggregate products — heat maps, approach corridors, route profiles to known sites, bathymetric interpolation — in which individual dives are not separately identifiable.
This is deliberate, and it’s where the value actually is. Knowing that the route to a particular wreck runs along a certain bearing through certain landmarks is enormously useful. Knowing that it was you who swam it last Tuesday is useful to nobody and is nobody’s business. The aggregate carries the navigational information; the identity carries none of it, so the identity is dropped.
To keep aggregation from quietly becoming de-anonymization, an aggregate layer is only rendered where it draws on dives from at least three distinct contributors. Below that, a “heat map” is one person’s track with a blur filter on it, so it isn’t published at all.
If you want a specific route shown to other divers as its own track — because you’re documenting a route or an exploration and want other divers to see exactly where it went — you can force-share it. See Section 5.
Tier 3 — Not shown to other users at all
- Your email address
- Your password hash, session data, and device tokens
- IP addresses and server logs
- Raw uploaded sensor and calibration files
- Data-quality assessments (see Section 6)
- Anything you have marked private
Only the operator has access to these.
5. Controlling what you share
Sharing is the default. It is not compulsory.
Every dive, track, and report carries a visibility setting:
- Shared (default). Reports are published and credited to you. Tracks go into the pool and feed aggregate layers without your name attached.
- Private. The entry is yours alone. It appears on your own map, it is excluded from every public and aggregate layer, it is not used to build anything other divers see, and it is not counted toward the three-contributor threshold. You keep the full use of the site for your own navigation and logging.
- Force-shared. The opposite case: the route of the dive is drawn on the map as its own track for other registered divers to see, rather than absorbed into an aggregate. It is still not shown to the general public. Your name is not attached to it, but while only a handful of divers use Divemap, other people may well be able to tell whose it is — choose this only if you’re comfortable with that. A force-shared track is kept out of the heat maps, so that it can’t be subtracted from them to reveal what the other contributors did. Use this for a new route, a first exploration, or anything you want other divers to be able to follow.
If you’re diving a site you don’t want other people to know about — or don’t want them to know about yet — log it here anyway and mark it private. That is a normal and supported thing to do. You get your tracks, your profiles, and your own private chart; the community gets nothing until you decide otherwise, and you can flip an entry to shared at any later point.
Do not enter a deliberately wrong position to protect a site. A false hazard or a false landmark is dangerous to the next diver, and it is a violation of the Terms of Use. Mark it private instead.
Visibility can be changed after the fact. Note the asymmetry, though: switching an entry from private to shared is instant, while switching from shared to private stops future use but cannot claw back aggregate products already built, published, or downloaded by others. See Section 9.
6. Data-quality assessment
Building a usable chart from contributed data requires knowing how much to trust each input. Contributed data is therefore evaluated for internal consistency and systematic error — for example, whether a contributor’s positions tend to trend in a particular direction, or whether their stated position uncertainty tends to run optimistic or conservative relative to independent fixes.
These assessments are per-contributor, and they are used to weight data when building maps. They are internal and are not displayed to other users. If that ever changes — if contributor reliability becomes a visible, public feature — it will be announced in advance rather than switched on quietly, and you will be able to delete your account first.
7. Cookies and similar technology
Divemap sets a session cookie so that you stay logged in, and may set a cookie to remember display preferences. That’s it. No advertising cookies, no cross-site tracking.
8. Where the data lives, and who else touches it
Divemap runs on DigitalOcean infrastructure in the United States. DigitalOcean can technically access the servers as an infrastructure provider; they are not given the data for their own purposes.
Transactional email (password resets, account notices) may be handled by a third-party email provider, which will see your email address for that purpose.
Data is not sold, rented, or shared with advertisers, data brokers, or insurers. It may be disclosed if legally required by valid process, or if necessary to investigate abuse or protect someone’s safety.
If Divemap is ever transferred to another operator, or licensed as a dataset, content covered by the contributor license in the Terms of Use may transfer with it. Account credentials and email addresses would be handled under a policy no less protective than this one, and material changes would be announced.
9. Your choices — access, export, and deletion
You can:
- Set visibility on any dive, track, or report, at any time (Section 5).
- View and edit your contributions at any time.
- Export your own data, including private entries, in a machine-readable format.
- Delete your account. This removes your email address, password hash, profile, session data, and device tokens. Private entries are deleted. Shared contributions are detached from your username and display name.
One important limit, stated plainly: deleting your account does not remove your shared contributions from the map. Reports, tracks, and derived layers become part of a merged dataset that other divers rely on and that cannot be cleanly unwound after the fact — that’s the trade described in Section 2 and in Section 7 of the Terms of Use. Under the contributor license, shared content stays. Attribution is removed, but the data remains.
If you need a specific contribution removed rather than de-identified — because it was posted in error, reveals a protected site, or discloses something it shouldn’t — email [email protected] and it will be dealt with promptly. That process exists precisely because the blanket rule above is inflexible.
If you are in the EEA, UK, California, or another place with statutory data rights, those rights apply and you can exercise them by emailing [email protected]. Where required, the legal basis for processing is your consent for account data, and legitimate interest in maintaining a shared navigational dataset for contributed content.
10. Retention
Shared contributions are kept indefinitely — that’s the point of a chart. Private entries are kept until you delete them or delete your account. Server logs are kept for a limited period (target: 90 days) and then discarded.
11. Security, honestly
Passwords are hashed, traffic is served over HTTPS, and the database isn’t publicly exposed. But this is a hobby project maintained by one person. It has not been independently audited, it carries no security certification, and no promise is made that it cannot be breached.
This applies to private entries too. Marking a dive private keeps it out of the public map and out of every derived product; it is not a guarantee against a breach, a bug, or an operator mistake. Don’t put anything into Divemap that would harm you if it were disclosed or lost. If you use a password anywhere else, don’t use it here.
If you discover a vulnerability, please report it to [email protected].
12. Children
Divemap is not intended for children under 13 (or under 16 in the EEA and UK), and accounts are not knowingly created for them. If you believe a child has an account, email [email protected] and it will be removed.
13. International users
Divemap is hosted and operated in the United States. If you use it from elsewhere, your data is processed in the US under US law.
14. Changes
This policy may change. Material changes will be posted here with a revised effective date and, where the change affects how existing data is used or displayed, announced in the app before taking effect.