Skip to content

Privacy (GDPR)

Garmin Wear OS Apple Watch Server
Status ✅ ✅ ⏳ ✅

Verified against code: 2026-10-19

Purpose

SailEver fully adheres to the GDPR. This file states the rules every product follows, and links to where each rule is specified in detail. It holds the principles only; the behaviour lives in the linked sections. Decision and reasons: ADR 006.

These rules are binding for every new feature, every new platform (Apple Watch, phone apps, CIQ SDK) and every new table or outside service. A change that would break one of them needs an owner decision and a new ADR first.

Rules

  • A watch app sends nothing to SailEver until the user has agreed on the watch: no device registration, no pairing request, no upload, no other request. One gate in front of every request enforces this.
  • The question is asked the first time the user opens pairing: "Send your trips to sailever.com?" with sailever.com/privacy. Without Yes, SailEver receives and stores nothing from that watch.
  • Recording works without consent, but the tracks stay on the user's own watch (and in Garmin Connect or Google, which is their processing, not ours). They reach SailEver only after consent and pairing.
  • Unpair withdraws the consent: nothing is sent afterwards, queued tracks stay on the watch.
  • The watch consent is stored on the watch only; the server never asks for it and never receives it.
  • The Wear OS track map loads tiles from tiles.sailever.com only on a paired watch (pairing includes the consent) and only while the Track view is on screen; the privacy page names it. Garmin draws its track map from the watch's own maps and sends nothing (watchapp/track-view.md, ADR 018).

Specified in watchapp/sync-and-pairing.md (consent view, gate, unpair) and device-api.md (client rules).

  • An account exists only with consent to the current privacy policy, stored with its version and time. Sign-up and the beta application need a ticked checkbox; an account without consent to the current version sees the consent page before anything else in the signed-in area.
  • A new privacy policy version that changes the purpose asks every account again.
  • The terms are accepted the same way (checkbox at sign-up and on the beta form, stored with their version); the consent page asks for both.

Specified in server/auth.md.

3. Full deletion, available to everyone

  • Every user can delete the account themselves, at any time, under Account → Delete account. The deletion starts at once; there is no grace period and no soft delete.
  • Deleting an account removes everything tied to it: devices, trips (with their descriptions), tracks with their track files, raw segments, boats, the sailor bio, passkeys, sign-in tokens, connections, beta applications and support requests. Paired watches are revoked first and stop sending.
  • The database enforces it: every table that holds user data cascades from the account, and a test (apps/server/test/services/account_erasure_test.rb) fails when a table with a user_id or email column is not covered.
  • Requests by email are carried out with the same erasure (bin/rails "users:erase[EMAIL]", or the admin users list).
  • Single trips, tracks and devices can be deleted in the logbook at any time.
  • Sharing follows the account: deleting a trip or the owner's account ends its public links and crew; deleting a crew member's account removes them from every crew (server/sharing.md).
  • A crew member's role (crew or skipper) goes with their membership. A skipper has the owner's rights on that trip except deleting it or tracks they didn't upload; tracks a skipper uploads belong to the trip's owner and keep who uploaded them (tracks.uploaded_by_id), which is cleared when that account is deleted (server/sharing.md § Roles). The privacy page says so.

Specified in server/auth.md and server/data-model.md.

4. Information, retention and processors

  • sailever.com/privacy describes every kind of data, its purpose, its legal basis, every outside service that receives data, how long data is kept, and the user's rights (access, rectification, erasure, restriction, portability, objection, complaint to the Austrian Datenschutzbehörde).
  • Data is kept only as long as stated there; cleanup jobs enforce the limits (never-paired devices 30 days, support requests and beta applications 12 months, ended trip links 30 days).
  • Nothing is public by default. A trip is shown to others only through a link its owner creates; public links end after 30 days, and a user's name appears on a public page only with their opt-in (first name only). The public page carries no email, last name, device or record id (server/sharing.md). With it comes the trip replay: positions to the minute, speed, course, pressure and the stored model wind of the kept parts (server/trip-replay.md); the privacy page says so. A crew link shows the trip's title, area, dates and distance before signing in, with the owner's first name under the same opt-in; messengers fetch and keep that link preview, including a picture of the trip's map drawn on our own server, kept only while a link works (server/sharing.md).
  • A new kind of data or a new outside service is added to the privacy page in the same change.

Specified in server/public-site.md (legal pages) and server/data-model.md (cleanup jobs).