Privacy Policy

1. Introduction

OpenDiving is open-source software for logging dives. Anyone can download it and run their own copy, and this page describes this copy — the one you are reading it on.

So “we” and “our servers” on this page mean whoever runs this copy of OpenDiving. Writing the software and running a copy of it are two roles rather than necessarily two parties: the OpenDiving project is the author of the software always, and is an operator only of the copies it runs itself. Authorship on its own carries nothing across — for a copy the project does not run, it runs no servers for that copy, receives no data from it, and never sees what you log there. Where the project does run a copy, it is that copy’s operator as well, and every commitment this page makes of the operator is one it makes in that role, exactly as any other operator does. Under data-protection law the operator of this copy is the controller of your data, and they are who is answerable for it.

Because the software is public, so is every claim on this page. What it says is collected is what the source code collects, and you are free to go and check.

2. Information We Collect

2.1 Information You Provide Directly

When you create an account or use the Service, you may provide:

• Account Information: Name, username, email address. There is no password — see section 5
• Profile Information: Diving certifications, including any images or PDFs of the cards themselves, the training courses behind them, and a profile picture
• Check-in Details: What a dive shop asks for at the desk, all of it optional: a portrait, meaning a photo of your face cropped like a passport photo; your date of birth and phone number; the email address you enter for check-in, which need not be the one you sign in with; emergency contacts, meaning other people’s names, phone numbers and relationships to you, which you enter; and your dive insurance policies — for each, the provider, the policy number and when it expires. A check-in link you make shows them to whoever holds it, as section 4.9 describes
• Dive Logs: Dive location, depth, duration, the kind of dive it was, conditions, the boat you dived from, gas mixes, species seen, each with a count and a note, your own rating of the dive, the tags you file it under, and your notes; and, where your dive computer measured it, your heart rate through the dive, with its highest and average figures. Your heart rate is data about your health: it is stored with the dive, shown to you alone, and included when you export your logbook
• Dive Drafts: A dive you save before logging it, here or in the OpenDiving app — whatever of the dive log above it holds so far, and on the app the gear set you loaded and the items you ticked off it. A draft is kept until you log it, which makes it a dive, or discard it
• Dive-Computer Files: When you fill a dive in from a dive-computer file, that file itself is kept alongside the dive — on the recording it came from, under the filename it arrived with, and a dive keeps every one you upload. A dive-computer or logbook file you import in another format than DiveJSON is kept the same way when it is one dive: on the dive it becomes, under the filename it arrived with. A logbook of several dives, and a DiveJSON document, leave no file here, and importing a full archive puts back the files it carries. The files of an import are held on the server from the upload until you apply or discard it, or until the limit whoever runs this copy has set, if there is one, runs out, so that you can finish it on another device; only files the app could read are held, and they are deleted once the import is applied. An import’s review and log stay readable after that, for as long as whoever runs this copy keeps them, which may be until you delete them. A dive the OpenDiving app downloads from a dive computer over Bluetooth keeps the computer’s original download the same way, on the dive it becomes. A file from a computer with a wrist sensor or a heart-rate strap switched on carries your heart rate, which is read into the dive log above
• Equipment Data: Diving equipment details and service records
• Contacts: The dive centers, schools, shops, clubs and places you stayed that you record, to name them from your dives, courses, certifications, service records and trips — a name, what each one is to you, and, if you add them, its phone number, email address, website, postal address, where it is on a map and your notes. A contact can be a person rather than a business — the friend whose flat you stayed in — and what you record about them is then somebody else’s data, which you enter
• People: The buddies, guides, instructors, fellow students and companions you record, to name them from your dives, trips, courses and certifications — a name, the role each had on a dive, a trip or a course, and, if you add them, an email address, a phone number and your notes. What you record about a person is somebody else’s data, which you enter. You can link a person to their account on this copy by typing its username, and section 4.10 says what that shows, and to whom
• Proposals for OpenDiving Commons: A dive site of yours, or a change to a Commons site, that you propose: its shared facts, which follow your edits while a new site waits, the words you ticked and when, and any message you add for the reviewer. Who reads that, and what is published, is section 4.14
• Support Requests: Whatever you write on the support page, if this copy has one configured, and the address you give to reply to

Both pictures are kept as the file you picked — or, for the portrait, the one a full archive carries, if you take it in the import — so that you can change how either is cropped later, with the location and camera details a phone photo carries removed by this server before the file is stored; what the app shows is drawn from that file at the crop you chose. Your portrait is shown to you where you edit it and on your check-in page, and to whoever holds a check-in link you made (section 4.9), and never where your profile picture appears. The full archive export carries both files, and both are deleted with your account.

One thing arrives without you typing it. If you create your account by signing in with Google, your Google profile picture is fetched by this server and stored here as your avatar — once, when the account is made, and never again afterwards. That only happens on instances with Google sign-in turned on; section 4.12 describes it if this one does.

Two more addresses can reach this copy before any account exists, and both belong to whoever is running it rather than to a directory of any kind. If this copy is not taking new accounts on its own, its home page offers a form for asking to be invited: the address you type there is stored while the request is pending, for up to 90 days, or until whoever runs this copy invites you or removes the request, or an account is created here with that address. Being invited does not erase it — it becomes an invitation instead, which records the address invited, the account that sent it, whether it came by that account’s invite link, whether it has been used, and, until it is used, whether it answered a request to be invited; it is what lets you create an account here. Where this copy is invite-only, every account can also make an invite link, a token kept on that account’s record until its owner resets or removes it. Section 4.8 is about all three, and section 7 says how long each is kept.

There are no photos of dives, no bio, no experience level, and no comments or posts, because there are no community features to put them in. The one message here is the word you may add to a proposal for OpenDiving Commons, and the reason a reviewer gives for declining one, which pass between you and the reviewer and go no further.

2.2 Automatically Collected Information

Seven things are recorded without you asking for them, and all seven are ordinary machinery. Two of them — signed-in devices and account security events — are also counted, into daily totals that name nobody, which the end of this section describes:

• Server logs: Your IP address and browser user agent, and the address of each request, written by the web server the way every web server writes them. For a search of the dive site map, that address carries the centre of the map and, when you search the area on screen, its edges, each cut to about a kilometre, as section 2.3 describes. How long those are kept, and whether they are kept at all, is a question about the operator’s deployment rather than about this software. The next two entries are a different matter: there the app stores the IP address and the user agent itself, in its own database, and section 7 says for how long
• Signed-in devices: Each time you sign in, this copy writes down the session — the IP address the sign-in came from, your browser’s user agent as it sent it, when the session was made and last used, and how long it stays signed in while unused — a browser’s window or the OpenDiving app’s longer one, which section 10.1 describes. That record is what makes the list in Settings possible, and it is the only reason signing another device out can work at all. It is also counted into the day’s total of active accounts, below. It holds nothing from the sign-in cookie itself
• Account security events: A record of things that happen to accounts on this copy, and this is the whole list — a sign-in link requested; an invitation asked for; an invitation sent; an invite link made; an invite link removed; a sign-in succeeding, or a sign-in code got wrong; a verified sign-in being offered a new account to make, or a deleted one to bring back; an account created or restored; a second way of signing in attached to an existing account; a passkey added or removed; an API key made or revoked; a passkey reporting a use count that suggests it has been copied; an email address change asked for or completed; an account asked to be deleted; a sign-out; one device signed out, or every other one at once; and a spent sign-in cookie turning up again. Each entry holds what happened and when, the IP address and user agent it came from, which way into the account it was about — email, Google, a passkey or an API key — where that applies, and the account it was about, or, for something that happened before any account existed, the email address that was typed. An invitation sent is the one entry that carries both, because both are the point of it: the account that sent the invitation, and the address it went to. Never a link, a code, a token or a key itself, only the fact that one was issued or used. Nothing in the app shows these to you; they are there for whoever runs this copy to look into a break-in or a burst of sign-in attempts, and section 6.2 says what that means for asking for a copy. The successful sign-ins among them are also counted into the day’s total of accounts that signed in, below
• Rate-limit counters: To stop sign-in, the support form and the invite-request form being hammered, this server counts recent requests in a short-lived store. The counters are keyed three ways — by IP address, by the email address a sign-in link, a support request or an invitation was requested for, and by account id for things you can only do signed in, such as exporting your data, importing a logbook, changing your username or email, linking a person to an account, registering a passkey, making an API key, inviting somebody, proposing for OpenDiving Commons, looking up place and species names, and searching the dive site map. Each counter is a number and expires by itself: after 5 minutes on dive site map searches, after 15 minutes on the sign-in and account paths, after an hour on the support form, the invite-request form, exports, logbook imports, and the place- and species-name lookups; and after a day on proposals for OpenDiving Commons. Other counters exist that hold no identifier at all — they cap how often this server as a whole may call an outside provider, and are keyed on the provider, not on anyone
• Passkey labels: If you register a passkey, a coarse label worked out from your browser — something like “Chrome on macOS” — is saved with it, so a list of passkeys tells you which is which
• Retry records: When the OpenDiving app on a phone creates something — a dive, a dive site, a person — it sends a one-off key with the request, so that sending it again after a reply was lost on a bad connection cannot create it twice. For each key this copy keeps the account it came from, the key, which kind of thing was being created, a digest of what was sent from which the request cannot be read back, the outcome, the identifier of the record it made, and when. Nothing of the record itself is copied into it. A tool of your own calling this copy with an API key, as section 4.11 describes, may send one too and leaves the same record. A browser sends none, so using this site adds none. Section 7 says how long they are kept
• Replaced sites: When a dive site of yours is replaced with a Commons site, this copy keeps the removed site’s identifier with your account, pointing at the record that took its place. Nothing else of the site is kept in it. Section 3 says what it is for and section 7 how long it stays

What is kept in your browser is a separate matter, and section 10 lists all of it. No usage data about you is collected: nothing here measures which pages you visit, which dives you open, or how long you spend, and none of the seven above is compared or profiled. The security record names things that happened to your account — not what you were doing in the app.

What is counted is a set of daily totals, each a number per day for this copy as a whole: how many accounts were created, and through which door — an invitation, an invitation answering a request to be invited, signing up where this copy lets anyone in, or being the first account on a new copy; how many accounts signed in; and how many were active, meaning a signed-in session of theirs was used that day. No account is named in any of them. They are not anonymous in every case, though, and this page will not claim they are: on a day when only one account was created, that day’s total and the account’s own creation date together show which door it came through. Section 7 says how long the totals are kept.

2.3 Location Information

Location reaches this server five ways, and all five start with you:

• Coordinates you place yourself — a pin on the map, or a pair of coordinates typed into a dive site, trip or contact form, or into a change you propose to a Commons site. Choosing a Commons site, which section 4.2 describes, sends no position of yours: the position is the site’s own, and what is recorded is that you used it
• GPS positions recorded inside a dive-computer file you import, which are where you actually were rather than which site you picked
• Coordinates carried in a logbook you import — a logbook file can record where a dive entered and left the water, where a dive site is and its entry in a registry such as OpenStreetMap, where a trip went and where a contact is, and those are written as the file gives them
• GPS positions inside a photo you pick as your profile picture or portrait, or inside the portrait carried by a full archive you import, which travel with the upload and are removed by this server before the photo is stored — an archive’s only if you take it in the import
• The centre of the dive site map in the Sites section and in the dive form’s Find a dive site, sent with each search of it, and the edges of the part on screen when you search that area — each cut to two decimal places, about a kilometre, whatever moved the map: you dragging it, a place you picked, the dive, its sites or the trip it opened on, or the answer to Use my location from your browser or your phone

The app asks your browser where you are in one place, the Use my location button on the dive site map, and only when you press it — never as a page opens — and your browser asks you before it answers. The answer moves the map and nothing is sent when it arrives: what reaches this server is the map’s centre with your next search, rounded to about a kilometre like every other search’s. The app stores it nowhere. Because the centre travels in the request’s address, it is in the server logs section 2.2 describes, for as long as those are kept. The page is served with a header that lets only this app’s own pages ask the browser where you are, so nothing embedded in one can. What the basemap provider sees when a map is on screen is a different question, and section 4.4 answers it.

The OpenDiving app on a phone has the same dive site map, in its Sites tab and in the dive form, and asks the phone where you are the first time that map opens, through the phone’s own prompt. Whatever you answer, it does not ask again. If you allow it, the Sites tab opens on where the phone is, and so does the dive form’s map when the dive has no site with a pin and no GPS position to open on; Use my location moves the map there too. The position stays on the phone: what reaches this server is the point the list is measured from — the map’s centre, where the phone shows a map — sent as the map opens and with every search after, rounded to about a kilometre like every other search’s, and in the server logs for as long as those are kept. The app stores it nowhere. If you refuse, Use my location says where in the phone’s settings to allow it. The app also uses the phone’s location when you ask it to place a dive site or a trip where you are, which puts a pin there as one you placed yourself.

3. How We Use Your Information

We use your information to:

• Provide the Service: Store your dives, dive drafts, sites, trips, gear, courses, certifications, contacts, people, tags and check-in details, show them back to you, answer a tool you gave an API key as it would answer you, within what that key allows, show you the current username of an account you linked a person to, show your check-in page to whoever holds a check-in link you made, and, where this copy is invite-only, show your name to whoever opens your invite link
• Account Management: Sign you in, keep you signed in, and let you change or delete your account
• Email: Send you a sign-in link and code, confirm an address change, confirm a deletion, tell an address that it has been invited here, tell you when a passkey is added to or removed from your account and when an API key is made or revoked on it, tell your old address when your email address is changed, remind you when gear you have set a service schedule on comes due and when a certification or one of your insurance policies nears or passes its expiry date, and send you your year of diving in figures each January. If you use the support form, deliver what you wrote to whoever runs this copy. Section 6.3 lists all of these and says which arrive without you asking
• Decide who may create an account: Where this copy is invite-only, keep its invitations and the requests waiting on them, so that the address that was invited is the one that gets in, and so that whoever runs this copy can see who has asked; keep each member’s invite link, and let in whoever follows one. Section 4.8 says what that shows to whom, and section 7 how long either is kept
• Keep the instance standing: Apply the rate limits described in section 2.2
• Keep your account secure: Keep the record of signed-in devices from section 2.2, so you can see them and sign one out, and keep the record of account security events, so whoever runs this copy can look into a break-in or a burst of sign-in attempts. Both expire on a schedule — section 7
• Create things once: Keep the retry records from section 2.2, so that something the OpenDiving app, or a tool of yours, sends again after a lost reply is created once rather than twice
• Follow a replaced site: Keep the identifier of a site you replaced with a Commons site, from section 2.2, so that a write the OpenDiving app queued against the site, or a dive draft naming it, still lands on the record
• Keep OpenDiving Commons: Show what you propose for OpenDiving Commons to whoever reviews it, tell you what became of it, publish what is accepted, without your name, and keep the proposal as the evidence of what you affirmed. Section 4.14 says exactly what that shows and publishes
• Count how this copy is used: Keep the daily totals from section 2.2 — accounts created and through which door, accounts that signed in, accounts that were active — so whoever runs this copy can see how many people it serves and how they got in. They name nobody

And nothing else. Your data is not profiled, not used to personalise anything, not used to pick content for you, not sold, and not fed to advertising. There is no advertising here to feed. A record accepted into OpenDiving Commons is a different thing, being no longer your data: it is in the public domain, so anyone may use it for anything, and this page cannot promise otherwise.

4. Information Sharing and Disclosure

4.1 What Is Public Here

Nothing you enter is published unless you propose it for OpenDiving Commons and a reviewer accepts it. There are no public profiles, no public dive logs, no feeds, no forums, and no public ratings or reviews: the rating you give a dive is part of your own log. Every dive, trip, gear item, course, certification, contact, person and tag is kept for one account and shown to that account alone, and a dive site you add yourself is too, until you propose it. A Commons site belongs to no account, as section 4.2 says, and your notes, tags and dives on one are as private as the rest. No setting publishes anything: the one way something you entered becomes public is a proposal a reviewer accepts, one site at a time. You make every other exception yourself too: a check-in link shows your check-in page to whoever holds it, for a day, and section 4.9 says exactly what that shows; where this copy is invite-only, an invite link shows your name — and nothing you entered — to whoever opens it, until you reset or remove it, as section 4.8 says; an API key you make lets whatever holds it read your account as you — and change it, if you let it — until it expires or you revoke it, as section 4.11 says; and a dive site or a change you propose is read by whoever reviews it and, once accepted, is public for good, as section 4.14 says.

4.2 What Other Divers Can See

What you enter stays in your account unless you propose it for OpenDiving Commons. There are no groups, nothing one diver can post for another, and no shared logs, and the people you record are your own notes about them rather than a connection between two accounts. Another diver with an account on this same copy sees no dive, trip, gear item, course, certification, contact, person or tag of yours, and no dive site you added unless it has been accepted into OpenDiving Commons. The account that reviews proposals does read a site you propose, as section 4.14 says. What does cross between accounts, when you link a person to one, runs towards you and is small: that an account with the username you typed, or with the identifier a file you imported carried, exists here; what its username is now; and, in your own export, its identifier.

There are four exceptions. The first is not about anything you entered: inviting somebody shows them your name, and shows you whether they went on to register; and, where this copy is invite-only, an invite link you make shows your name to whoever opens it, and shows you the name on the account of anyone who creates one through it. Section 4.8 sets out exactly what that discloses, in both directions. The second is exactly about what you entered: a check-in link you make shows your check-in page to whoever holds the link, another diver included, until it expires or you revoke it. Section 4.9 sets out what that shows. The third runs the other way and is about another account rather than yours: linking a person you recorded to an account here shows you that account’s current username, and tells the account nothing. Section 4.10 sets out what that discloses. The fourth is about what you entered too, and you choose it each time: a dive site or a change you propose for OpenDiving Commons is shown to whoever reviews it, with your name, and what is accepted is public, without it. Section 4.14 sets out what that shows and publishes.

Two things every account on this copy does draw on belong to no one diver. The first is the catalogue of species — the fish themselves, saved here once. It records what a species is, never who saw it; section 4.6 explains how it fills up.

The second is OpenDiving Commons, a pool of dive sites this copy carries: its name, position and the other facts of the place, drawn from open sources such as OpenStreetMap and Wikidata, and from what divers have proposed on this copy. A Commons site is one record every account can use, marked Commons in your list of sites, on its own page and in the searches that find it, and it is not copied into yours when you log a dive there or save it to your sites. The notes, tags and dives you add to it are yours alone: they are kept apart from the record, and no other account can see them. Nor can another account see that you use the site, apart from whoever reviews a change you propose to it. Removing a Commons site from your sites deletes your notes and tags on it and takes it off your dives, which stay in your log, and leaves the record as it was.

4.3 Hosting and Email

This copy of OpenDiving runs wherever its operator put it — their own hardware, or a hosting provider of their choosing. That provider necessarily holds the machine your data sits on, and which provider it is, if any, is the operator’s decision rather than the software’s.

Email reaches you through whatever mail server the operator configured, so that server handles the address a sign-in link or a reminder is sent to. There is no customer support desk and no third party doing support on anyone’s behalf. The rest of section 4 covers every outside service this software genuinely contacts, and it is a short list.

4.4 Map Tiles

Seven places in the app show a map your browser draws itself, and for those your browser fetches the map’s tiles directly from a third-party basemap provider. That provider therefore sees your IP address and which part of the world the map is showing — which is, roughly, where you dive. It does not receive your account, your dive log, or the name of anything on the map.

Your browser does this whenever one of those maps is on screen, whether or not you interact with it: the Sites section, which loads its map of dive sites as soon as it opens; the form to add or edit a dive, whose site field opens that same map in Find a dive site when you ask for it; the form to add or edit a dive site and the form to add or edit a trip, which load a map as soon as they open — one to place a pin on, one to show you the places you pick — the form to add or edit a contact, which loads one only when you ask it to show the map, the step that checks a site of yours before it is proposed, which loads one when it opens, and the screen where this copy’s operator reviews what divers propose for OpenDiving Commons, which loads one when a proposal is opened. Apart from those seven, no page has your browser contact the provider.

Those maps name places in English and, where the map has a name for a place in the language your browser is set to, in that language as well. Your browser picks that language itself, and the app adds it to nothing it sends. The provider learns it all the same: like every browser, yours names the languages it is set to in each request it makes, to this provider as to any site.

The cards that list your dives and trips carry a map too, and so does the head of the page of a dive, a trip and a dive site. On this copy this server draws those maps rather than your browser, in tiles — squares of the world map with nothing of yours in them. The first time anyone on this copy is shown a part of the world, the server fetches what that tile needs from the same provider, draws it and keeps it; your browser fetches the tiles from this server and puts the pins on them itself. So for those maps the provider sees this server’s address rather than yours, once for each tile rather than for each picture or each time you look. That is every card in the list of your dives, Home’s recent dives and the dives listed on the page of a dive site, a trip, a piece of gear, a species, a course or a person; in the list of your trips and Home’s recent trips; and the head of a dive’s, a trip’s and a dive site’s own page. A dive or a dive site with no position shows no map, and a trip’s shows the whole world until it has a place on it. A dive has a position from the site it was logged at, from the GPS reading in the dive-computer file it was imported from, or from a logbook file that carried the position itself; where its map shows a recorded position, that is where you actually were rather than only which site you picked.

Each of those tile requests carries the language your browser is set to. The server reduces it to a language — German, say, for a browser set to Austrian German — and draws the tile’s place names in English and, where the map has a name in that language, in it as well; a language the map names nothing in, or English, gets the tile in English alone. The language itself goes no further than this server, but the lettering a tile is drawn in comes from the provider as it does for the forms’ maps — so for a language not written in the Latin alphabet the provider can tell that this server drew that alphabet, though not for whom.

The tiles are shared: everyone this copy shows a part of the world in the same language is shown the same tiles, and a tile this server already keeps reaches a browser sooner than one it still has to draw. So another member of this copy who timed their own requests could tell that someone here was shown a region some tens of kilometres across in the last 30 days, and that it was someone whose browser is set to a given language — though not who, and nothing of what they logged there. Section 7 says how long the tiles are kept.

The paragraphs above describe a browser. The OpenDiving app on a phone draws a map of its own in seven places: the Sites tab and the dive form’s Find a Dive Site, which load the map of dive sites as they open, the form to add a dive site and the search for a site’s location, the form to add a trip, the form to add a contact, which loads one only when you ask it to show the map, and the step that checks a site of yours before it is proposed. It draws these maps only where this server draws tiles, so on a copy that draws none those screens show no map. To draw one, the OpenDiving app names the phone’s language to this server when it asks for the map’s style, and fetches the map directly from the same basemap provider, which sees the phone’s IP address, the part of the world on screen, the OpenDiving app’s name and version and the iOS version that its requests’ User-Agent header names, and the language settings that their Accept-Language header names, and nothing of your account.

If you run your own copy of OpenDiving you can point it at a basemap you serve yourself, and none of this leaves your machine.

4.5 Place Names

After you place a dive site — on the map, or by pasting a pair of coordinates into the form — we ask a geocoding provider what that spot is called, so we can offer you a location like “Dahab, South Sinai, Egypt” to save with the site. Only the coordinates are sent, and they are sent by our servers rather than by your browser, so the provider never sees your IP address or anything else about you. The answer is cached, so the same spot is not looked up twice.

The dive site and trip forms also let you search for a place by name, and so does the search on the dive site map in the Sites section and in the dive form’s Find a dive site, which finds places as well as sites. There, what you type is what is sent — again by our servers, not your browser — a short moment after you stop typing, and it may go to a different provider from the one that names a spot. Nothing else about the form or the map goes with it: the map’s centre a search carries stays with this server.

All of this happens only as you fill a form in or search the dive site map, never when you view a site or a trip you have already saved. Type the coordinates in by hand and nothing is sent at all.

4.6 Species Names

The dive form lets you record what you saw, and the picker searches for it as you type — a short moment after you stop, once you have typed a couple of letters. It asks two public registers: the World Register of Marine Species, which is the authority on scientific names, and Wikidata, which supplies the common ones, so that typing “clownfish” finds the fish. What is sent is what you typed, and nothing else about the dive you are logging. As with place names, it is sent by our servers rather than by your browser, so neither register sees your IP address, your account, or anything else about you.

If you then pick a species this copy of OpenDiving has never seen before, we fetch its record so it can be saved. Both registers are asked again — the marine one for the taxonomy, Wikidata for the common name — and all either of them receives is the species’ number in the marine register: not what you typed, and nothing about you or the dive.

Importing a logbook does the same thing without a picker being involved at all. A logbook file can name marine life this copy of OpenDiving has never seen, and those species are looked up before the import is written — the same two registers, the same request, carrying the species’ number and nothing about you. Species it cannot match are left out of the import rather than guessed at, and it tells you which.

At that same moment — whether the species came from the picker or from a file you imported — we also ask a third outside service, Wikimedia Commons, whether it has a photograph of that species, and download the picture once if it does. What Commons receives is the name of an image file, worked out from the species’ number: again, not what you typed, and nothing about you or the dive. The picture is then stored on this copy of OpenDiving and served from here, so your browser never contacts Wikimedia and Wikimedia is never told which species you are looking at. Nothing is downloaded when a species already has its photo, and a species that has none is left without one rather than shown something else.

Most of the time none of those requests happens at all. Answers are kept for a month, and they are shared by everyone using this copy of OpenDiving rather than held per diver, so once anyone has searched for a name, nobody’s search for it leaves again that month. The species themselves are shared in the same way: they are saved here once and belong to no one diver, so picking one that somebody has already picked sends nothing. The longer a copy of OpenDiving runs, the less it has to ask.

All of this happens only as you fill a dive in or import a logbook, never when you view a dive, a species or your species list you have already saved. If you never open the species picker and never import a file naming marine life, nothing is sent at all. The photographs on those pages come from this copy of OpenDiving like every other image on the site.

If you run your own copy of OpenDiving you can point it at your own copies of the two registers, and of the service the picture details are read from. The picture file itself is always fetched from Wikimedia’s own servers: that one address is fixed in the software deliberately, so that a mistake in configuration cannot send this copy off to download images from somewhere it should not. Leaving any of them unset does not switch the search off — it narrows it to the species your own copy already holds.

4.7 Legal Requirements

Whoever runs this copy of OpenDiving may be compelled by law to hand over data they hold — a court order, or a valid demand from an authority with jurisdiction over them. That is a duty that falls on the operator, not a permission this page grants itself, and what they must do about such a demand is a question for them and their jurisdiction. Where the OpenDiving project is not the one running this copy, it holds none of your data and so has nothing it could be asked for; where it is, it is the operator this paragraph is about, and the duty falls on it like any other.

4.8 Inviting Someone to This Copy

Whoever runs this copy decides whether anyone may create an account on it or only people who have been invited. Where it is invitations, this is one of the four places in the software where something about one person is shown to another — the others are a check-in link, in section 4.9, linking a person to an account, in section 4.10, and a proposal for OpenDiving Commons, in section 4.14 — and this section is the whole of it.

An invitation you make by typing an address carries no code, no link and no token — it is simply a note that this copy will let a particular address create an account. So there is nothing to forward and nothing to keep secret, and the person invited still has to prove they can read that mailbox in the ordinary way.

Where this copy is invite-only, you also have an invite link of your own, on the Invitations card in your settings: an address on this site, shown as a QR code or sent, that lets whoever follows it create an account here, counted as your invitation. It is the opposite of a typed invitation in the one way that matters: anyone holding it can use it, whatever address they sign in with, until you reset or remove it, and each account made through it counts against the same limit as the invitations you send. What it carries is kept only where letting somebody in needs it: signing in by email, on the sign-in link’s own record, which is deleted within about a week; signing in with Google, in your browser until Google sends you back, as section 10.2 says. It is written onto no account.

What the person you invite is told: your name, as it is on your account, and that you invited them to this copy. Where this copy is invite-only, whoever opens your invite link sees your name too, whether or not they go on to register, and is told, before they sign in, that you will see the name on their account. Nothing else about you, and nothing you have logged. What you are told: the address you invited, when you invited it, and whether it has been used to create an account — which is a fact about them, arriving because of something you did; and, for somebody who joined through your invite link, the name on their account and when they joined, and never their address. Whoever runs this copy can see the same, because they can read the database on their own machine, which is true of everything on this page.

One thing more is disclosed, and only to the person doing the inviting: if you try to invite an address that already has an account here, this copy says so rather than leaving you to wonder why nothing arrived. That does tell you an address is registered, so what bounds it is a limit on how many invitations one account may attempt in a quarter of an hour, counted with the other rate limits in section 2.2 — not the separate limit on how many invitations you may make in a day, by address or through your invite link, which counts only invitations actually made and so never counts a refusal.

If this copy is not taking new accounts on its own, its home page offers a form for asking to be invited. The address typed there is stored so that whoever runs this copy can see who has asked; the form answers the same way whatever it did with the address, so nobody can use it to find out whether an address already has an account here. Whoever runs this copy is shown that flag when they look at the queue, so they can drop the request instead of inviting somebody who is already here. Section 7 says how long a pending request and an unused invitation are kept.

4.9 Check-in Links

Your check-in page can make a link to itself, for a dive shop to open on its own phone or computer — from a QR code on your screen, or an address you send. This is another of the places in the software where something about one person is shown to another, one of the two that show what you entered, and this section is the whole of it.

What a link shows: your check-in page as it prints — your name and your portrait if you have one, your date of birth and phone number, the email address you entered for check-in, your insurance policies, your emergency contacts, your dive count, deepest dive and last dive, and each certification with its number, dates, instructor and dive center, beside the front of the card where you stored a picture of it. Never the back of a card, and never the address you sign in with; a card kept as a PDF is named as one rather than shown; and neither your profile picture nor anything else this copy holds about you is shown at all.

Who can open it: anyone who has the link, with no account and no signing in — which is what lets a desk open it. Treat it like the printout it stands in for: whoever you give it to can pass it on. The page asks search engines not to list it.

For how long: 24 hours from when you made it. Revoking it from your check-in page stops it at once, and so does making another, since only one of your links works at a time. Asking to delete your account stops it too.

What this copy keeps: a fingerprint of the link rather than the link itself, which is why your check-in page cannot show you its QR code or address again once you leave it; when it was made, when it expires, and whether you revoked it; and your dive count, deepest dive and last dive as the page showed them when you made it, so a correction you made for that day is what the link shows and a dive logged afterwards does not change it. Everything else is read from your account each time the link is opened, so a change you make shows at once. Section 7 says when a link is deleted.

4.10 Linking a Person to an Account

A person you record — a buddy, an instructor — may have an account on this same copy. Type that account’s username into the person and this copy links the two, so that the username the account has now shows beside the name you gave them. This is the third of the four places in the software where something about one person is shown to another, and this section is the whole of it.

What you are shown: whether an account with exactly that username exists here — which choosing a username of your own already tells anyone, since a username that exists is one you cannot take — and, once the person is linked, that account’s current username, kept current if it changes. Nothing else of theirs: not their name, not their picture, and nothing they have logged. Typing your own username is refused, and so is typing one another of your people is already linked to — the refusal names that person. What the account is told: nothing. No message is sent, and nothing in that account shows that anyone linked it. Linking changes what you see, not what they see or hold. Whoever runs this copy can see the link, because they can read the database on their own machine, which is true of everything on this page.

What your export carries: for each person you linked, the linked account’s identifier on this copy — the same identifier that account’s own export carries for itself. It also encodes when that account was created, to the millisecond, so a file you hand to somebody else tells them that too.

What an import can do: a file you import can link a person to the account on this copy its entry names by that identifier — not your own, and not one another of your people is already linked to — and the import’s report names each account it links by its current username, which the file itself did not carry. So a logbook somebody else exported tells whoever imports it here the current usernames of the accounts its author linked. An identifier naming no account here is dropped, and that person arrives unlinked.

Since whether a username exists is something linking reveals, what bounds it is a limit on how many links one account may attempt in a quarter of an hour, typed or imported, counted with the other rate limits in section 2.2. Typing the username a person is already linked to again counts for nothing. Clearing the username, or deleting the person, removes the link at once. If the linked account is deleted, the link stays through its grace period, and once the account is erased every person linked to it is simply unlinked — the record you kept of them stays yours.

4.11 API Keys

In Settings, under Authentication, you can make an API key: a secret that lets a script or a program of your own use this copy’s API as you — to read your dives into a spreadsheet, say, or to log them from another tool. A key reaches your own account and no one else’s, nothing about you is shown to anybody by making one, and this section is the whole of it.

What a key can do: what its scope allows. A read-only key can read whatever your account can and change nothing; a read-and-write key can also add, change and delete what you could in the app. Neither can make, list or revoke API keys, passkeys or signed-in devices, make a check-in link or an invite link, change the email address you sign in with, or delete your account — those need you signed in, in a browser or the OpenDiving app — and neither reaches anything only whoever runs this copy can. Whoever holds a key can use it from anywhere, so treat it like a password: anyone you give it to can pass it on.

For how long: until the expiry you chose when you made it — 30 days, 90 days, a year, or never — or until you revoke it on the API keys card, which stops it on its very next request. Signing out, or signing other devices out, leaves every key working. Asking to delete your account stops all of them.

What this copy keeps: a fingerprint of the key rather than the key itself, which is why it is shown to you once, when you make it, and never again; its first twelve characters, so the card and the emails can tell your keys apart without holding one; and the name you gave it, its scope, and when it was made, last used and expires. Making or revoking a key emails you and is one of the account security events in section 2.2; using one records nothing beyond its last-used date. Section 7 says when a key is deleted.

4.12 Signing In with Google

This copy of OpenDiving offers “Continue with Google”, and until you press that button nothing about you reaches Google. Opening the front page or the sign-in page loads no code of Google’s, contacts no Google address, and gives Google no opportunity to set anything in your browser. If you sign in another way, or never sign in at all, Google is never told you were here.

Pressing the button takes you to Google, because that is what signing in with Google means. From that point you are on Google’s own site, under its own privacy policy, which this copy of OpenDiving neither controls nor can see. Anything Google stores there is its own, on its own address, rather than a third-party cookie on this one. You choose there whether to go through with it, and if you change your mind Google returns you here with nothing having happened.

What comes back to your browser is a single-use code and nothing else. It is this server, not your browser, that hands that code to Google in exchange for confirmation of who you are — a call made server to server, which is why nothing identifying you passes through your browser at any point. This copy stores no Google credential of any kind: it never asks Google for the sort of token that would let it act as you later, and the code and the one-time secret your browser kept to match it are both used once and discarded.

If you do sign in with Google, Google learns that you use this copy of OpenDiving. And if that is the moment your account is created, your Google profile picture is copied onto this instance and becomes your avatar — once, at account creation, and never again. Signing in with Google later does not fetch it a second time, because by then the picture is yours to change.

An operator who would rather not offer this at all can leave Google sign-in unconfigured, and then none of this — including this section — exists on their copy at all.

4.13 Weather at Your Dives

This copy of OpenDiving fills in the weather for the dives you log. Some time after you save a dive that has a place — a dive site’s pin, or a position your dive computer recorded — our servers ask Open-Meteo, a public weather service, what the weather was there and, for a dive in the sea, the waves and the tide. What is sent is the position rounded to about a kilometre and the dates around the dive, at most three days and never an hour. Nothing identifying you or the dive goes with it, and it is sent by our servers rather than by your browser, so Open-Meteo never sees your IP address. Answers are cached, so a second dive at the same place on the same days sends nothing more.

The answer fills a dive’s air temperature, weather and waves only where you left them empty, and the dive page marks each one it filled. Choosing another value replaces it, and the value you chose is never overwritten.

An operator who would rather not use this leaves it switched off, and then nothing is sent and this section does not exist on their copy.

4.14 Proposing for OpenDiving Commons

OpenDiving Commons is edited on this copy. A dive site of yours can be offered to it with Propose for OpenDiving Commons, which the form that adds or edits a site of yours offers to start as you save it, and which is on the site’s own page too; a Commons site can be corrected with Propose a change on its page. Both go one site at a time, and neither goes anywhere until you tick the words it shows you and send it. This is the fourth place in the software where something about one person is shown to another, the second that shows what you entered, and the only one that publishes anything, and this section is the whole of it.

What a reviewer is shown: whoever runs this copy reviews proposals, from an administrator’s account. They are shown the name on your account, never your address; how many of your proposals have been accepted and declined; the message you added, if you added one; and the site’s shared facts — its name and other names, its pin, the name of its locality, its entries in registries such as OpenStreetMap, its depths, its water, its altitude and how divers get in. For a site of your own the proposal follows the site’s edits while it waits, so an edit you make meanwhile is what is in front of them. Never your notes, your tags or your dives, and no other diver is shown any of it.

What is published: if a reviewer accepts, the record, and only the record: those shared facts as the reviewer settled them, with the pin at six decimal places and the locality as a name alone, and the site’s identifier, which it keeps and which encodes when you created the site, to the millisecond. A change publishes the new values on the record it changes. Who proposed it is never published: no name, no address and no account goes with it. A site of yours that is accepted stops being yours, and every account here can use it; your notes, tags and dives on it stay yours, as section 4.2 says. Where the Commons already has the site, the reviewer may accept yours into that record instead: your dives, notes and tags move to the record and your own site is removed, though its identifier is kept with your account, pointing at the record, until your account goes.

Who can read it: anyone. This copy serves every Commons record at a public address, with no account needed, and they are copied to a public repository on GitHub, whose history keeps what it has held. Other copies of OpenDiving carry the records too, and anyone may take them from there.

What you give up: the words you tick say that what you propose is from your own diving and not copied from elsewhere, and dedicate it to the public domain under CC0 1.0. What is accepted is anyone’s, for any purpose, and it stays: removing it from your sites or deleting your account leaves it where it is. A change accepted into a record that came from another source leaves that record under its source’s licence.

What this copy keeps privately: the proposal — what you asked for, the words you ticked and when, your message, whether it waits or was accepted, declined or withdrawn, and any reason. It is tied to your account and is never published. It is kept so that it can be reviewed and answered, so that you can see what became of it, and as the evidence that you made the dedication. It goes when your account goes, whatever became of it, and section 7 has the rest of how long it stays.

What happens to it: while it waits, everyone goes on seeing the site as it is, and you can withdraw it from the site’s page or from Your proposals on the Sites page. A proposal that is declined or withdrawn publishes nothing. A decline always comes with a reason, which the reviewer writes and you read on the site until you propose again, and in your list of proposals. No email is sent about a proposal; the answer waits for you in those two places. Proposals are limited per account per day, counted with the other rate limits in section 2.2. A tool of yours holding a read-and-write API key can send one as you, and the words it sends are yours as much as a tick would be.

What you can ask: the rights in section 6.2 apply to a proposal as to anything else here. Your list shows each one’s outcome and reason; for a copy of the rest, or to have one corrected or deleted, ask whoever runs this copy, as section 13 says. An accepted record is a different matter, because it carries nothing that names you and it is no longer yours to withdraw: deleting the proposal behind it leaves it public.

Reporting a record: anyone, with an account or without, can report a Commons record — a pin that shows more than it should, a wrong name, something that should not be there — to whoever runs this copy, by the way section 13 gives. A report is answered by changing the record, a reviewer coarsening the pin or changing the name. A record cannot yet be removed.

5. Data Security

What the software itself does:

• Passwordless by design: There is no password field anywhere, and no password is stored, because none is ever set. You sign in with a link or a code sent to your email, with a passkey, or — where an instance offers it — with Google. A tool of your own uses an API key instead, which signs nothing in and is shown to you once — section 4.11
• Single-use sessions: The cookie that keeps you signed in is spent and replaced on every use. A spent one presented again within about a minute is answered as the retry it almost always is — a reply lost on a bad connection — and past that it is treated as a stolen session rather than a mistake. Each session is also a record on the server rather than only a token in your browser, which is what lets you see the devices signed in to your account and sign one of them out from another — section 6.1
• Nothing sensitive in browser storage: The short-lived token that authorises each request is held in memory and never written to storage at all, so a script running on the page has nothing to read. Section 10 is the full list of what is written
• Open to review: The source is public, so these claims can be checked rather than taken on trust, and security reports are welcome

What the software cannot promise on an operator’s behalf: whether traffic to this copy is encrypted in transit, whether the disks it sits on are encrypted at rest, who has administrative access to the machine, and whether backups exist and where they go. Those are properties of a deployment, not of a program, and they belong to whoever runs this one. The self-hosting documentation tells operators how to get the first of them right; it cannot make them. On this copy all four are answered rather than declined, under Who Runs This Copy at the top of this page.

6. Your Privacy Rights and Choices

6.1 Account Control

From Settings and the Import page, without asking anyone, you can:

• Update your profile and account information
• Change the email address you sign in with
• See every device signed in to your account, and sign any of them out
• Make an API key for a tool of your own, see what each one may do and when it was last used, and revoke it
• Where this copy is invite-only, invite someone, make, reset or remove your invite link, see the invitations you have sent and who joined through your link, and take back one that has not been used
• Export what you have entered, all but your proposals for OpenDiving Commons
• Bring a logbook back in — a file this app exported, or files from a dive computer or another program, as many at once as you have, seeing what they would do before anything is written
• Delete your account and what is attached to it, which leaves any record accepted into OpenDiving Commons

There are no privacy settings for your dive logs, and their absence is the point: what you log is neither public nor shared unless you propose it, so there is nothing to switch off. What does have a switch is a check-in link you made, which Revoke on your check-in page switches off at once — section 4.9; where this copy is invite-only, your invite link, which Remove on the Invitations card switches off at once — section 4.8; an API key you made, which Revoke on the API keys card switches off at once — section 4.11; and a proposal that waits, which Withdraw on the site or in your list of proposals takes back at once — section 4.14. A proposal already accepted has no switch: it is public, and it stays.

6.2 Data Rights

Depending on your location, you may have the right to:

• Access: Request a copy of your personal data
• Correction: Update inaccurate or incomplete information
• Deletion: Request deletion of your personal data
• Portability: Export your data in a common format — and read it back into another copy of this app, which is the half that makes the format worth having. Your dive drafts ride in the full archive but are not read back
• Objection: Object to certain processing of your data
• Restriction: Request limitation of data processing

The first four need no request: access, correction, deletion and portability are all buttons in Settings, and they act immediately rather than being forwarded to somebody. Nine things sit outside those buttons, and naming them is better than letting that sentence read wider than it is. The email address you sign in with, your username, the list of signed-in devices and your API keys are in Settings but are not part of the export: they are your account on this copy rather than your logbook, and the username only names the file you download. Nor are the map tiles section 4.4 says this copy draws, and deleting your account leaves them too: they are not yours. Each is drawn from the map alone, with nothing of yours in it, and is kept while anyone on this copy is shown it and for 30 days after. And three records in section 2.2 are in neither, the account security events, the retry records and the identifiers of replaced sites: nothing in the app shows them to you and no button copies them, so a copy of any of them has to be asked for like the rights below. Nor is a proposal for OpenDiving Commons in the export: your list of proposals shows what became of each, and a copy of the rest has to be asked for in the same way, as section 4.14 says. The last two, that request, and anything else go to whoever runs this copy — section 13 says how to reach them.

6.3 Communication Preferences

This copy of OpenDiving sends you three kinds of email, and the whole list is here. (It also delivers a support-form message to whoever runs this copy, which is mail about you rather than to you.)

Emails that follow an action on this site: the sign-in message, which carries both a link and a code; the message confirming a new email address, sent to that new address; the message confirming that you asked to delete your account; and, where this copy is invite-only, the message telling an address that somebody here has invited it. None of these can be switched off without breaking the thing they are part of.

Only one of those four is sent to your account’s own address — the deletion confirmation. The other three go to whatever address was typed, and it is worth being straight about what that means. Signing in needs no account, so anyone who types your address into this copy causes a sign-in message to be sent to you — which is why that message tells you to ignore it if it was not you, and why the link and code expire quickly and work only once. The address-confirmation message is the same shape: it goes to whatever new address a signed-in diver typed, for the express purpose of proving they can read it. Neither of those two is something the recipient can prevent, because the alternative is a sign-in flow that cannot start. The invitation goes to whatever address somebody with an account here invited, and names them so you know who; it is not preventable either, but for a different reason and it is worth being exact about which. Nothing turns on its arrival — the address is admitted the moment the invitation is made, so the message is a courtesy rather than a step, and the person who invited you could as easily have told you by other means. What makes it unpreventable is that this copy has no way to know, before sending, that an address would rather not hear from it. What bounds it instead is the limit in section 4.8 on how many invitations one account may make, by address or through its invite link.

Being sent to your own address is not the same as being sent because you acted, and this page will not blur the two. Deleting your account, adding or removing a passkey, and making or revoking an API key each email your account’s address on the strength of a live session and nothing more — no re-checking that it is really you. So if somebody else had hold of your session, the message still arrives at you, about something you did not do. That is precisely why the notices in the next group exist and cannot be switched off.

Security notices, which arrive because your account changed — whether or not it was you who changed it: when a passkey is added to your account, and when one is removed; when an API key is made for it, and when one is revoked. And when your email address is changed, a note goes to the old address naming the new one. That last one exists precisely so that the owner of an address finds out even if they were not the person who changed it, which is why it cannot be switched off: an alert you can silence is not an alert.

Three scheduled emails, each under its own condition.

Gear service. If you set a service schedule on a piece of gear you have not archived, this copy will email you when that service comes due. It is not a drumbeat: one email when something enters “due soon”, one when it goes overdue, and then — because a schedule left overdue would otherwise go quiet forever — a reminder every three months for as long as it stays overdue. Logging the service, or changing the interval, starts the cycle over. Gear with no schedule on it, or gear you have archived, is never mentioned.

Renewals. If a certification you have entered, or an insurance policy in your check-in details, has an expiry date, this copy will email you once when that date is 90 days away or closer, and once more when it has passed. Everything that reaches either point at the same time goes in one email. There is no reminder after that: a card or policy left expired stays in your notifications, but is not emailed about again. Entering a new expiry date starts the cycle over. A card or policy with no expiry date is never mentioned.

Your year in review. During January, this copy will email you the year before in figures, taken from your own log: how many dives and how long underwater, your deepest and longest dives with the date of each and its dive site where it has one, how many dive sites, and how many species you logged and how many of those were new to you. It is sent once for each year, and not at all for a year in which you logged no dives.

All three are on by default: a reminder nobody switched on never arrives, and the point of each is reaching you when you are not in the app. Each has its own switch in Settings, under Notifications, and turning one off stops that kind and leaves the other two as they are.

7. Data Retention

What you have entered is kept for as long as your account exists, and what is accepted into OpenDiving Commons for longer. That is what a dive log is for — a logbook that quietly discarded your older dives would be the wrong product.

Three of the records in section 2.2 expire on their own, whether or not you delete anything, because none is anything you entered. A signed-in device’s session is deleted after it stops being able to sign you in: one that went unused long enough to lapse goes within the hour, and one that ended before that — you signed that device out, or signed out on it — is kept until the end of the day it was last used, midnight UTC, so that it still counts in that day’s total of active accounts, and goes within the hour after. And the account security events are swept on a schedule — entries tied to an account after 90 days, and entries that name only an email address, from before any account existed, after 7 days. That shorter one is deliberately the same short life the sign-in link’s own record already has: an address someone typed into this copy and never came back to should not outlive it here. A retry record is deleted by an hourly sweep once it is as old as the longest an OpenDiving app’s session can sit unused — about three months, the window section 10.1 describes — so that something the app sends again days after a lost reply still finds it.

An import expires on its own too, if whoever runs this copy has set a limit. Its held files go when you apply or discard it, or at that limit if you do neither, and the import goes with them. An import you applied keeps its review and log, without the files, until the retention set here runs out or you delete it from the Import page.

Two more expire on their own where this copy is invite-only, and both hold an address belonging to somebody who may have no account here at all. A request to be invited is kept for up to 90 days from when it was made, and goes sooner if whoever runs this copy invites the address or removes the request, or if an account is created with that address. An invitation nobody has used is kept for up to 90 days from when it was sent, whether or not it was taken back before then; after that the address is refused again until somebody invites it afresh. An invitation that was used is not swept, because by then it belongs to two accounts and goes when either of them does.

A check-in link is deleted by a sweep that runs every hour once it has stopped working: 24 hours after you made it, or sooner if you revoked it or made another.

Where this copy is invite-only, an invite link does not expire: it is kept until you reset or remove it, or your account goes. An invitation made through one is used from the start, so it is never swept either, and goes when either account does.

An API key is not swept either. It is kept, expired or not, until you revoke it or your account goes; an expired one stays on the API keys card, marked, so that removing it is yours to do.

The identifier of a replaced site has no expiry of its own. Replacing a dive site of yours with a Commons site removes the site, and its identifier stays with your account, pointing at the record, until your account goes.

A proposal for OpenDiving Commons is not swept either. It is kept, whatever became of it, until your account goes, and one on a dive site of your own goes sooner if that site is deleted or replaced with a Commons site, whose identifier alone stays, as the paragraph above says. A record accepted into the Commons is kept for as long as the Commons is, whatever becomes of your account: it belongs to no account, and section 4.14 says what it carries.

The map tiles this copy draws, which section 4.4 describes, are kept with its files. They are drawn from the map alone and shared by everyone this copy shows that part of the world in the same language, so they belong to no account and are not deleted with one: a tile this server has not been asked for in 30 days is deleted, and drawn again if a map asks for it after that.

The daily totals in section 2.2 are kept for as long as this copy runs, and deleting an account does not lower them: each is a count of what happened on one day rather than a record about anyone, and a total that shrank when somebody left would no longer say what happened that day.

When you delete your account:

• It first goes into a short grace period, during which signing in again brings it back intact. The email confirming the deletion says when that period ends
• Personal information is permanently deleted within 30 days
• The deletion is not a flag or an archive: the account row and what belongs to it — dives, dive drafts, sites, trips, gear, courses, certifications, contacts, people, tags — are destroyed, and the files you uploaded are unlinked from disk with them. A Commons site you saved stays, being no account’s, and your notes and tags on it go. A site or a change of yours that was accepted into OpenDiving Commons stays too, having stopped being yours when it was accepted
• Your proposals for OpenDiving Commons go with it, whatever became of them. One still waiting leaves the reviewer’s queue as soon as you ask to delete the account, and comes back if you bring the account back
• Any invitations you sent go with it, used or not, and so does your invite link. Somebody you invited who has not created an account yet loses the invitation and would have to be invited again by someone else. Any invitation or pending request naming your address is found by that address and removed as well
• Every person another diver linked to your account is unlinked. Their record of that person stays theirs, and from then on shows no username
• Your sessions, your API keys, your retry records and your account security events go with it. The entries made before the account existed have nothing linking them to it, so they are found by the email address instead — the same way the sign-in records already are. The one gap that cannot close: entries left under an address you later moved off are not named by the deletion, and expire on their own 7-day schedule instead

Apart from the daily totals above and the records accepted into OpenDiving Commons, neither of which names you, nothing is kept for “legitimate business purposes”; there is no business here to have them. Two honest caveats remain, and both belong to the deployment rather than to the software: whatever backups the operator keeps are theirs to expire, and a deletion cannot reach into a backup already written; and an operator under a legal obligation to preserve something is subject to it whatever this page says.

8. Where Your Data Lives

Your data lives on this instance, and where that is, is a fact about its operator’s deployment. There is no network of servers behind it, and nothing of your account leaves it. What does is the OpenDiving Commons records section 4.14 describes, which anyone anywhere can fetch and which are copied to a public repository on GitHub, a service run from the United States. Otherwise one copy of OpenDiving is one database and one files volume, wherever the person running it chose to put them. The files volume also holds the map tiles this copy draws, which are drawn from the map alone and are nobody’s, deleted once 30 days pass without one being shown, as section 7 says.

If that matters to you — and under some data-protection laws it does — the operator is who can tell you, and section 13 says how to ask. If you run the copy yourself, the answer is your own machine. On this copy you need ask nobody: Who Runs This Copy at the top of this page names the region the database and the files sit in.

9. Children's Privacy

OpenDiving is not intended for children under 13, and this copy does not knowingly collect personal information from anyone under 13. If its operator becomes aware that it has, deleting the account removes it.

Divers between 13 and 18 should have a parent’s agreement before using the Service, particularly given what it is a log of.

Those two sentences are the software’s floor, and an operator may be held to a higher one. This copy is: its minimum age is 16, for the reason given under Who Runs This Copy at the top of this page.

10. What Is Stored in Your Browser

Two kinds of thing: one cookie that keeps you signed in, and a short list of preferences remembered on this device. None of it is advertising or analytics, which is why this page has no cookie banner for you to click through — there is nothing here to ask you to accept.

10.1 The Sign-in Cookie

One cookie, named refresh_token, and in normal operation it is the only one this software sets. It is what keeps you signed in. Your browser will not let scripts on the page read it, it is sent only back to this site, and by default it is marked so that it travels only over an encrypted connection.

It is single-use: each time it is spent a fresh one replaces it, with the clock started again. So the window rolls rather than running out on a fixed date — signing in keeps you signed in on this browser until about a week goes by without you using the app, not for a week from when you signed in. So a browser you keep using stays signed in for as long as nothing ends its session, and the next paragraph is what can. The OpenDiving app on a phone asks for a longer window when it signs in, and stays signed in until about three months go by without it being used; a browser is never given that one. “About a week” and “about three months” are the standard settings, and the operator of this copy can change either.

It is cleared when you sign out and when your account is deleted. It also stops being accepted when the session behind it is ended somewhere else: signing that device out from the list in Settings, using “Sign out other sessions” there, or — on an account with an improbable number of devices signed in at once — this copy dropping the least recently used one to make room. In each of those the browser is signed out at once: the short-lived token described below stops being accepted from the same instant, so the next thing that browser asks this server for sends it to the sign-in page. A spent cookie turning up again within about a minute is answered as the retry it almost always is, and past that is treated as a stolen session. For that minute this server keeps the cookie it issued in the spent one’s place, with the token that goes with it, to hand to the retry, and then discards it — nothing of it is written to the database.

The token that actually authorises each request is deliberately never written to your browser’s storage. It is held in the tab’s memory, dies when you close the tab, and is worked out again from the cookie above the next time you open the app. That is the reason the rest of this list is so short.

10.2 Preferences Remembered on This Device

Ten entries in your browser’s local storage. Every one of them is read only by the page you are on: none is sent to this server, and none is sent anywhere else. Where a row below says how long an entry is kept, read it as “unless you tell this browser to stop remembering” — 10.3 is the switch that does that, and says which of these it reaches.

• theme — whether you picked light, dark, or whatever your system is set to. Kept until you change it
• opendiving:post-auth-redirect — where to send you after you click a sign-in link, since the link is opened from your mail app and lands on a page that has no other way to know. It expires after 24 hours, is cleared when you sign out, and is read once and removed. It can hold an in-app address such as a particular dive’s page, which anyone else at this browser could read — which is exactly why it does not linger
• opendiving:google-sign-in-attempts — the one-time secret that proves a “Continue with Google” sign-in coming back from Google is the one you started here, along with where you were headed and, where this copy is invite-only and you came by a member’s invite link, which link. Written only when you press that button, one entry per attempt so that two tabs cannot spoil each other’s, read once and removed the moment Google returns you, and expiring after 30 minutes if it never does
• opendiving:passkey-nudge-dismissed — that you dismissed the offer to add a passkey on this browser. Kept until you undo that from the passkeys card in your settings
• opendiving:dive-profile-series-v5 — which lines you last had showing on a dive profile chart. Kept until you change them
• opendiving:gas-use-series — the same for the gas-use chart. Kept until you change them
• opendiving:dive-activity-view — which period Home’s activity chart is showing. Along with the period it holds a date to anchor it, worked out from the dates of your own dives, so this one is derived from your data rather than being only a setting. Kept until you change it
• opendiving:gas-use-view — the same for the gas-consumption card, with the same anchor date. Kept until you change it
• opendiving:entry-units — which units you would rather type in, per field, so that a rented cylinder gauge in psi does not make you convert in your head. Cleared when you sign out, so that the next person at this browser is not handed your choice
• opendiving:device-memory-opt-out — that you used the switch in 10.3 to say this browser should stop remembering your display preferences. 10.3 lists exactly which of the entries above that reaches. This is the one entry here that exists because you asked for it, and the only way this browser can keep honouring that answer after you close the tab. Kept until you turn the switch back off

10.3 Telling This Browser to Stop Remembering

Changing a preference is not the same as declining to have one stored, and under some rules — UK law is the clearest case — storage of this kind owes you a simple way to object to the storage itself rather than to the value. Here is that way. It applies to this browser, it costs nothing, and you do not need an account to use it.

Seven of those ten are covered: theme, both chart-line entries, both chart-period entries, opendiving:entry-units and opendiving:passkey-nudge-dismissed. Turning the switch on deletes each of them that exists and refuses the next write of any of them. It also sweeps out anything else this site left behind under the same opendiving: naming, including entries older versions of this software wrote and nothing reads any more. Turning it back off restores nothing — the stored values were what you objected to — it only lets later choices be remembered again.

Three are not covered. opendiving:post-auth-redirect and opendiving:google-sign-in-attempts are what carry a sign-in you started here across the hop through your mail app or through Google, and each removes itself — read once and gone, and expiring on its own if you never come back. And the switch’s own entry stays, because an objection this browser forgot the moment you closed the tab would not be one.

Clearing your browser’s data for this site removes all of them too, and we would still rather not dress that up as a control we give you. It is your browser’s, not ours; it cannot single one of these out; and it also destroys the sign-in cookie above and signs you out. The switch is ours, and it is the one that can.

10.4 What Is Never Stored

There is no session storage, no IndexedDB database and no service worker. There is no analytics or telemetry of any kind — not disabled, not configurable, simply absent, and no such dependency is in the build. The daily totals in section 2.2 are counted by this server, and nothing in your browser takes part. The fonts this site is written in are served from this instance and fetched from nowhere else. The one exception is the lettering on the map itself: its labels are drawn from glyph ranges requested, as they are needed, from the same basemap provider that serves its tiles — so it is the party already described in section 4.4, and not a new one.

This software sets no third-party cookies of its own. One outside party acts on its own account rather than ours, and it is disclosed above rather than denied: the basemap provider your operator chose, whose servers answer the requests described in section 4.4 and may set cookies of their own.

Google used to be the second, and deliberately is not any more. Nothing of Google’s runs in your browser on this site, and Google sets nothing in your browser under this address. Signing in with Google takes you to Google, where whatever it stores is its own on its own address — section 4.12 has the detail.

One exception belongs to operators rather than to divers. If this copy has the optional admin panel turned on, that panel sets its own session cookies under its own address. They are the tool of whoever administers this copy, they appear only for someone signing in to it, and they are documented for operators in the self-hosting documentation rather than here. That panel is a separate thing from the Admin section inside this app, which whoever runs this copy reaches from their own account menu: those are ordinary pages on this address, signed in to exactly like the rest of it, and they store nothing of their own.

The rule this project holds itself to, stricter than the law requires: the day any analytics, A/B testing or advertising storage is added to OpenDiving, a real consent flow ships with it and this section changes in the same breath. And any new key added to browser storage owes this section a line in the same change — a rule with a test behind it rather than only good intentions.

11. Changes to This Privacy Policy

This page is part of the software, so it changes when the software changes and ships in the same release. There is no separate mechanism that emails everyone about a policy change, and this page is not going to promise one it does not have.

What exists instead is better in one respect: the page is in the public source repository, so its full history — every edit, when it was made, and what it replaced — is readable by anyone, and no version of it can be quietly withdrawn. Which version you are reading depends on which release of OpenDiving this copy is running.

12. Open Source Transparency

A privacy policy is usually a promise you have to take on trust. This one does not have to be:

• The code is public, so every claim on this page can be checked against what actually runs
• The reasoning behind the awkward parts is written down in the repository too, including the parts this page admits are imperfect
• Anyone who finds this page saying something the code does not do can report it, and that is treated as a defect rather than as wording
• If you would rather trust nobody at all, you can run your own copy, and then every question on this page has the same answer: you

13. Contact

Most of what people write to a privacy address to ask for, you can simply do. Exporting what you have entered, your proposals for OpenDiving Commons aside, and deleting your account are buttons in Settings, and bringing a logbook back in is one on the Import page; they work immediately, they need nobody’s approval, and no request has to be sent to anyone.

For anything else — a question about this page, about how this copy is run, a report about a Commons record, or about a right in section 6.2 that those buttons do not cover — the person to ask is whoever runs this copy of OpenDiving. They are the controller of your data, whether that is the OpenDiving project running a copy of its own or somebody else entirely; an author who does not run this copy holds none of your data and could not answer for whoever does. The support page is how this copy offers to reach them.

On this copy they are named rather than described: Who Runs This Copy at the top of this page gives the operator’s name and an address that reaches them, so a request need not go through the support page at all. That address is the operator’s, in the role that can act on it — which leaves the next paragraph exactly as it stands.

Two things this page will not do, both deliberately. It will not print an address belonging to the OpenDiving project as the software’s author, because the address that can act on a privacy request is the operator’s, and the support page above is already it — on a copy the project runs itself, that page reaches the project too, in the role that can answer. Sent to the author instead, the request reaches people with no access to this copy. And it will not point you at a public issue tracker, because a question about your own data is not something you should have to ask in public. How quickly you get an answer is the operator’s to say, not this page’s.