Security, data protection, and getting your data back out

Passwords are hashed with Argon2. Access tokens are short-lived and signed; refresh tokens are bound to the device that obtained them and stored in the database, so a server restart does not sign out every device in a fleet — including ships with no link to sign back in over.

On board, a device that has been signed in unlocks with a PIN rather than a full sign-in, because a full sign-in needs a server and the whole point is that there might not be one.

• Rate-limited, tightly on sign-in. The expensive request and the attacked one gets a stricter ceiling than the rest.
• Self-service password recovery. A reset link is single-use, expires in thirty minutes and is limited to three per hour per account. The answer to a forgotten-password request is identical whether or not the address exists.
• A temporary password is handed over once. An administrator resetting somebody’s password sees it once, and the account is forced to change it on first use.

The product keeps what a position and an emergency require: who somebody is, which position they hold, when they are on board, which certificates they hold, and how to reach their next of kin. Everything more sensitive than that — medical records, controlled-drug treatments — sits behind its own narrow permission rather than being visible to anybody with an officer’s role.

There is no permission anywhere in the product, at any level, that grants reading another person’s messages. Norwegian employment law restricts an employer’s access to an employee’s electronic communication, and rather than implement a feature we would have to refuse to use, we did not implement it. A test asserts its absence.

A seafarer who leaves a company has a right to erasure. A ship has a legal obligation to retain rest-hour records, the oil record book and drill records for years. These two things genuinely conflict, and a vendor who tells you otherwise has not read one of them.

How it is resolved here: erasing a person anonymises the person — name, date of birth, address, contact details, photograph, signature — and deletes the sensitive record entirely, while the statutory entries keep an unattributed reference. The record that a rest period was worked survives; the name attached to it does not.

A person who is still embarked cannot be erased, because the crew list is a live safety document. That refusal is explicit and gives its reason.

A company can export everything it has: every table, every row, in a machine-readable form, without asking us and without a fee. Secrets are never exported — no password hashes, no PIN verifiers, no tokens — because an export is a copy of your records, not a copy of your locks.

This exists because a customer who cannot leave has stopped being asked whether the product is any good, and we would rather keep being asked.

Hosted in the European Economic Area. The AIS provider key is read from the environment, never stored in the database, never logged and never returned to a browser.

Backups are taken and — more to the point — restored. There is a restore drill script in the repository that takes a backup, builds a database from it, counts the tables, counts the users, counts the audit entries, starts the API against it and signs in. A backup nobody has restored is a hope.

• Three health endpoints, for three questions. One for whether the process is worth keeping, one for whether traffic should go here, one for a person on the telephone. They are different questions and one endpoint cannot serve all three.
• Every refusal has a request id. Including a 404. A person reading one string off their screen is enough for us to find what happened.
• A lapsed subscription never stops a ship recording. Rest hours, the oil record book, drills, permits, defects, checklists and every read stay working. What stops is adding another vessel or another account. Making a customer non-compliant at sea over an invoice is not commercial pressure.