Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Privacy & GDPR

This page is for people who run a MyAstroBoard instance. It lists what personal data the application stores, where it goes, how long it stays, and which built-in features help you meet the EU General Data Protection Regulation (GDPR). It ends with a privacy notice template you can adapt for your users.

Important

This is a technical description, not legal advice. MyAstroBoard is self-hosted software: the project never receives any of your data. Whoever operates an instance is the data controller for it and remains responsible for its compliance.


Who is responsible?

SituationGDPR status
You run MyAstroBoard for yourself and your householdUsually covered by the household exemption (Art. 2(2)(c)) - the GDPR does not apply.
An astronomy club, association or company runs it for its membersThe GDPR applies. The organisation is the controller; this page and the template below are a starting point.
Someone else hosts it on your behalfThey are your processor; you need a processing agreement with them (Art. 28).

The MyAstroBoard maintainers are neither controller nor processor: the software sends no telemetry and has no analytics, tracking or advertising code.


What personal data is stored

Everything lives in the data/ directory (the Docker volume): records in the SQLite database myastroboard.db (details), pictures and attachments as files named <user_id>_..., where user_id is a random UUID.

DataLocation in data/Notes
Account: username, password hash, role, creation date, last logindatabase, users tablePasswords are hashed (werkzeug); never stored in clear.
Two-factor secret (if enabled)database, users tableTOTP seed, needed to verify codes.
Preferences (language, time format, default/active location…)database, users table
Web Push subscriptionsdatabase, users tableBrowser push endpoint + keys, only if the user enabled notifications.
Observing locations: name, latitude, longitude, timezonedatabase, configurationA location is often the user’s home: treat coordinates as personal data.
Astrodex: observed objects, notes, optional picture coordinatesdatabase, astrodex_items / astrodex_picturesSee Photo metadata below.
Astrodex picturesastrodex/images/
Observation log: sessions, notes, conditionsdatabase, observation_* tables
Observation log attachmentsobservation_sessions/attachments/
Equipment profiles, Plan My Night plans, wishlistdatabase, equipment_*, plans/plan_entries, wishlist_items
Application logmyastroboard.log*Contains usernames and client IP addresses (sign-ins, refused access). See Retention.
Pre-1.7 data archivebackups/pre-1.7-*.zipWritten once by the 1.7 upgrade (every 1.6 data file, secrets included); delete it from App settings -> Backup / Restore once you no longer need to go back to 1.6. Data of accounts deleted later remains in it until then.

The browser keeps only the session cookie and a few display settings in localStorage (language, time format, a photo filter, the last seen app version). None of them is used for tracking.

Photo metadata

Camera and phone pictures usually embed EXIF metadata: the GPS position where the picture was taken (often the observer’s garden), camera serial numbers, sometimes the owner’s name. Because Astrodex pictures and session attachments can be seen by other users of the instance, MyAstroBoard removes this metadata when a picture is uploaded (JPEG, PNG, WebP):

  • removed: EXIF (GPS, serial numbers, owner, dates), XMP, IPTC, comments, PNG text chunks, and secondary images some phones append to the file (HDR gain maps, depth maps);
  • kept: the pixels, byte for byte - nothing is re-encoded, astrophotos keep their full quality -, the ICC colour profile and the orientation;
  • GIF files are stored as sent (the format carries no EXIF/GPS).

Pictures uploaded before this protection existed still carry their original metadata. Non-image attachments (PDF, Word, text) are stored as sent: remove author metadata before uploading them if it matters.

The coordinates a user types manually on an Astrodex picture are different: they are deliberate data used by the photo map. On a new installation the map is private: each user only sees their own pictures. Installations created before this default keep sharing the map with every user whose Astrodex is shared, until an administrator enables Configuration -> Astrodex -> Photo map private (see Astrodex).


Cookies

MyAstroBoard sets a single cookie: the Flask session cookie, which keeps the user signed in (HttpOnly, SameSite=Lax, Secure when enabled in App settings -> Configuration). It lasts until the browser closes, or 30 days when Remember me is ticked. It is strictly necessary for the service, so no consent banner is required (ePrivacy Directive, Art. 5(3)).

On a demo instance (DEMO_MODE=true), the same cookie also carries the visitor’s UI preferences (theme, language, density), since every visitor shares one demo account. Nothing else about the visitor is stored.


Third parties

MyAstroBoard contacts external services to compute forecasts and display maps. None of them receives account data, but some receive coordinates or the user’s IP address.

ServiceWhat it receivesSent byWhy
Open-Meteo (Switzerland/EU)Coordinates of each locationServerWeather forecast
7Timer! (China)Coordinates of each locationServerSeeing / transparency forecast
Nominatim - OpenStreetMap (EU)Coordinates + the browser’s IPBrowserNaming a location, only when the user clicks Use my location
OpenStreetMap tile and vector tile servers (United Kingdom)The map areas viewed, from the server’s IP (never the users’ IP); downloaded tiles are cached on the serverServerBackground of the maps (locations, photo map, observation log, orbital stations)
Browser push services (Google FCM, Mozilla, Apple)An opaque notification payloadServerWeb Push, only for users who enabled notifications
CelesTrak, The Space Devs, NOAA SWPC, JPL, Minor Planet Center, CDS Strasbourg, wheretheiss.atNothing personalServerSatellites, launches, space weather, ephemerides, object images
DSS2 sky survey mirrors: ESA ESASky (Spain/EU), MAST on Amazon S3 (United States), CSIRO CASDA (Australia), China-VO (China)Sky coordinates of catalogue objects, from the server’s IP; nothing about the usersServerObject images and framing backgrounds, only while CDS hips2fits is unreachable
SIMBAD mirrors: CfA Harvard (United States), IDIA (South Africa)Names of the astronomical objects looked up, from the server’s IP; nothing about the usersServerObject information, only while CDS SIMBAD is unreachable
GitHubNothing personalServerCheck for new releases and download their changelog
MyMemoryPublic spaceflight texts onlyServerOn-demand translation of launch descriptions

Optional integrations send data only when an administrator enables them:

  • MQTT / Home Assistant - to your own broker; a user’s data is published only while that user’s own switch is on, location devices carry no coordinates and pictures are sent without location data (details).
  • MyAstroShine - the chosen picture is sent to the MyAstroShine instance configured by the administrator (details).
  • Astrodex Stream - a signed URL that exposes one user’s pictures to whoever holds it (details).
  • AllSky and other connectors - the application reads from them; it does not send user data.

Transfers outside the EU: 7Timer (China) receives location coordinates, and the OpenStreetMap Foundation (United Kingdom) receives the map areas viewed, from the server’s IP. Mention them in your privacy notice.


Retention

DataKept until
Account and all per-user filesThe account is deleted (see below).
LocationsAn administrator deletes them.
Application log90 days by default: older lines are removed once a day (App settings -> Logs, 0 to 3650 days; 0 keeps only the size limit of 10 MB x 6 files).
Backups downloaded from ConfigurationUnder your control, outside the application: they contain everything listed above.

Data subject rights

RightHow to fulfil it today
Access (Art. 15)My settings -> Security -> Your data downloads a ZIP of everything stored about the user; an administrator can download the same archive for any user from App settings -> Users -> Export data.
Rectification (Art. 16)Users edit their own data; an administrator edits accounts and locations.
Erasure (Art. 17)An administrator deletes the account in Users. This removes the account and all of its data: Astrodex and pictures, observation sessions and attachments, equipment, plans and wishlist. Log lines mentioning the user remain until rotation.
Portability (Art. 20)The same ZIP: account and preferences, locations, Astrodex, observation log, equipment, plans and wishlist as JSON, with pictures and attachments as the original files. Password hashes and two-factor secrets are left out.
Objection / restrictionHandled by the administrator (disable the account, remove a location).

Accounts deleted before full erasure existed may have left files behind. The 1.7 upgrade moved such leftovers (data of accounts that no longer exist) to data/backups/orphans/; delete that folder once checked. Pictures and attachments of such accounts can be found by comparing the <user_id> prefixes of the files in astrodex/images/ and observation_sessions/attachments/ with python backend/db/manage.py list-users.


Security measures

  • Password hashing, optional two-factor authentication (TOTP), and throttled sign-in: 5 failed passwords per username and address, or 20 per address, within 15 minutes (details).
  • Session cookie HttpOnly, SameSite=Lax, optional Secure flag; serve the instance over HTTPS behind a reverse proxy (guide).
  • Role-based access (admin / user / read-only) and local-only accounts restricted to trusted networks (details).
  • Private by default towards search engines: robots.txt disallows crawling and the login page is noindex unless you opt in (App settings -> Configuration -> Privacy & search engines).
  • Connector secrets (MQTT connection passwords included) are stored apart from the configuration, with owner-only file permissions, and never appear in exports or API responses.
  • All front-end libraries are served locally: no CDN, font or analytics request leaves the browser except the geocoding listed above (map tiles go through the server).

Protect the data/ volume and your backups: they hold everything on this page.


Privacy notice template

Adapt the bracketed parts and publish the notice where your users can read it (club website, sign-up email…).

Privacy notice - [Instance name]

Controller: [Club / association name], [address], contact: [email].

What we collect: your username, a hashed password, your preferences, the observing
locations you record (name and coordinates), and the content you add (Astrodex pictures
and notes, observation logs, equipment, plans, wishlist). Our server logs record your
username and IP address when you sign in, for security.

Why: to provide the MyAstroBoard service you signed up for (Art. 6(1)(b) GDPR) and to
keep it secure (legitimate interest, Art. 6(1)(f)).

Who can see it: administrators of this instance; other members only for what you share
(shared Astrodex, photo map). Pictures are stripped of their GPS metadata on upload.

Third parties: weather providers (Open-Meteo, 7Timer! - China) receive the coordinates
of the observing locations; map tiles (OpenStreetMap - United Kingdom) are loaded by our server, and
place names (OpenStreetMap) by your browser. [Add enabled integrations: MQTT, MyAstroShine...]

Retention: your data is kept while your account exists and deleted with it. Server logs
are kept for [90] days.

You can download all your data at any time from My settings -> Security -> Your data.

Your rights: access, rectification, erasure, portability, objection. Contact [email].
You may lodge a complaint with your data protection authority ([e.g. CNIL]).

Cookies: one session cookie, strictly necessary to keep you signed in.

Last updated 2026-11-13