Privacy Policy

StarStats is operated as a personal hobby project. The data controller for the purposes of GDPR is the project maintainer, contactable at [email protected]. We do not have a designated Data Protection Officer because we are below the threshold that mandates one; the contact email above reaches a real person.

We only collect what we need to run the service. Nothing is sold to third parties, used for advertising, or shared with analytics platforms.

2.1 When you sign up

• Email address. Used as your login identifier and for transactional email traffic (sign-up verification, password reset, sign-in via one-shot magic link, and confirmation when you change your sign-in email). Lawful basis: performance of a contract (Art. 6(1)(b)) — we can't run an account for you without it.
• Password. Stored only as an Argon2id hash. We never see, log, or transmit the plain text. Lawful basis: contract performance.
• Two-factor authentication (TOTP) secret. Optional. If you enable 2FA, we generate a 160-bit shared secret and store it in the user row encrypted with AES-256-GCM under a key held in a file outside the database. We hold the secret only because authentication code verification requires it; it is decrypted in memory for each verification and never logged. Lawful basis: contract performance.
• Recovery codes (TOTP fallback). Optional. When you enable 2FA we mint ten one-shot recovery codes and store them as Argon2 hashes — we cannot show them again, even to you. They exist so you can sign in if you lose your authenticator app. Lawful basis: contract performance.
• RSI handle (Star Citizen username). The handle that appears in your Game.log. Used to tag the events you ingest so we can show your stats and not someone else's. Lawful basis: contract performance.

2.2 When the desktop client uploads game events

• Parsed game events — kills, deaths, mission completions, vehicle changes, location changes, client-side errors. Each event is a structured record with a timestamp and your RSI handle. We do not collect chat, inventory, currency, or screen contents. Lawful basis: contract performance.
• Other players who appear in your events. Some events (e.g., a kill credit) reference a second RSI handle. We store that handle alongside your event so the event is meaningful to you. We don't build a profile of that second person — they appear only when they intersected with your gameplay, and only the uploader (and the people they explicitly share with) can see it. Lawful basis: legitimate interest (Art. 6(1)(f)) — providing meaningful personal stats requires referencing pseudonymous public game handles, on balance with the low risk to those individuals.

2.3 When you use the website

• Session cookie (starstats_session): HttpOnly, Secure (in production), SameSite=Lax, 1-hour TTL. Holds your authentication token. Strictly necessary; cannot be disabled while you are signed in. No consent banner is required for strictly-necessary cookies under ePrivacy/PECR.
• Server logs may briefly record your IP address for rate-limiting and abuse prevention. IPs are not retained in the application database; they live in the rate-limiter's in-memory window and the short-lived web-server access log.

2.4 When something goes wrong

• Error reports are sent to an internal error-monitoring service (GlitchTip) so we can fix bugs. Reports include the URL path (with user-identifying segments scrubbed), the type of error, and a stack trace. Lawful basis: legitimate interest (service reliability).

The list below is intentionally short. Every sub-processor here either runs on the same infrastructure as StarStats itself or is strictly necessary for the service to function:

• Hosting infrastructure. StarStats runs on infrastructure controlled by the project maintainer. No third-party hosting provider has access to the application database.
• SMTP relay — transactional email traffic (sign-up verification, password reset, email change confirmation) is delivered through an SMTP server. The relay processes your email address and the verification link only. The current relay is documented in the deployment notes and is changed only with a corresponding update to this policy.
• GlitchTip (error monitoring). Runs on the same infrastructure as the rest of StarStats. No data leaves the StarStats deployment.
• SpiceDB (authorisation). Runs on the same infrastructure. Stores only the relationships needed for sharing ("A can view B's stats") — no event data.
• Audit log mirror (MinIO). Object storage on the same infrastructure, holding append-only operational audit records. Same network boundary as the application database.
• robertsspaceindustries.com (RSI handle verification and citizen profile snapshot). When you start the RSI handle verification flow we issue you a short code, and when you ask us to check your bio we make a single HTTP GET against https://robertsspaceindustries.com/citizens/<your-handle> to look for that code in the public bio. We send only a generic User-Agent identifying StarStats and the page version; no cookie, no session token, no account email. Once we confirm the code is in your bio we delete it from our row, and we do not re-fetch the page outside of an explicit verification attempt by you. The verification flow is optional but is required before you can publish a public profile or share with an org. Once your handle is verified, you can also ask us to snapshot your public RSI citizen profile by pressing Refresh now in Settings. This is a user-initiated, on-demand fetch — never a continuous background poll — and is rate-limited to one fetch per hour per user. The request goes to the same URL (https://robertsspaceindustries.com/citizens/<your-handle>) with the same generic User-Agent; no cookie, no session token, no account email. From the page we extract your display name, enlistment date, primary location (city / region / country, as RSI displays it), badges (name and image URL), bio text, and the one-line summary of your primary org. All of this is publicly visible on RSI's site to anyone visiting your citizen page — we are not scraping anything that requires login. We keep one row per snapshot so you can see how your profile has changed over time; you can request deletion through the normal account-deletion flow, at which point snapshots are pseudonymised in the same way as game events.
• Star Citizen Wiki API (ship and vehicle reference data). The Star Citizen Wiki API at https://api.star-citizen.wiki is a community-run, MIT-licensed reference for in-game ship and vehicle metadata — it is not operated by Roberts Space Industries. We use it to translate the internal class names that appear in your Game.log (e.g. AEGS_Avenger_Stalker) into player-facing names ("Aegis Avenger Stalker") so the dashboard can display events legibly. The exchange is server-to-server and one-directional: a scheduled task on the StarStats server fetches the reference catalogue once a day, sending only a generic User-Agent identifying StarStats — no user data, no email, no RSI handle, no event payload, and no IP-on-behalf-of-the-user. The request is never made from your browser. The cached data is keyed by ship class name and is never linked to any user.

We do not use Google Analytics, Meta pixels, advertising networks, or any third-party tracker. We do not embed third-party iframes that could observe your usage.

Our infrastructure is hosted within the EEA. We do not transfer your data outside the EEA except where unavoidable for transactional email delivery (e.g., recipient mailservers operated by mail providers who may sit in other jurisdictions). If you have a specific concern about a mail provider, contact us and we will tell you which SMTP relay is in use at that time.

• Account record (email, password hash, handle): until you delete your account.
• Ingested game events: until you delete your account, at which point they are pseudonymised — the row count and structure stay so people who shared a timeline with you don't see holes, but your handle and raw log lines are replaced with a non-resolvable tombstone. The events are no longer linked to you.
• Citizen profile snapshots: until you delete your account. On deletion they are pseudonymised in the same way as game events — the snapshot rows remain but your handle is replaced with a non-resolvable tombstone, so they are no longer linked to you.
• Email verification tokens: 24 hours, then auto-expire and are dropped on next access.
• Magic-link sign-in tokens: 15 minutes, single-use. Once redeemed (or expired) the token row is no longer accepted; we keep the row briefly for audit purposes but it cannot be re-issued.
• Interim 2FA tokens: 5 minutes, single-use. Issued between "you proved your password (or magic-link)" and "you typed an authentication code" — useless on their own.
• Recovery codes: until you regenerate or disable 2FA. Stored as Argon2 hashes; each consumed code is marked used and cannot be replayed.
• Device pairing codes: 5 minutes.
• Active device tokens: until you revoke the device or delete your account.
• Audit log: 90 days in the live database; an archived mirror exists for operational integrity. The audit mirror references your account UUID rather than personal details where possible.
• Error reports: 30 days, then deleted.

Under GDPR you have the following rights. Most can be exercised directly from the Settings page; for the remainder, send an email to [email protected] and we will respond within 30 days.

• Access (Art. 15): you can ask for a copy of the personal data we hold about you.
• Rectification (Art. 16): you can update your email or RSI handle from Settings, or by contacting us.
• Erasure (Art. 17): use the "Delete my account" control in Settings. Your account record is removed; your ingested events are pseudonymised so they are no longer linked to you. Some operational audit entries may be retained for the periods listed above under a legal-basis of legitimate interest in service integrity.
• Restriction (Art. 18): contact us to pause processing of your account.
• Portability (Art. 20): contact us for an export of your account record and events as JSON.
• Objection (Art. 21): you may object to any processing we carry out under legitimate-interest basis (e.g., error monitoring); contact us.
• Withdraw consent: where we rely on consent (we don't, today, for any core processing), you can withdraw it at any time without affecting the lawfulness of prior processing.
• Complaint: you have the right to lodge a complaint with your local data-protection authority. In the UK that's the ICO (ico.org.uk). In the EU, find your authority at edpb.europa.eu.

StarStats is not directed at children under 13 (under 16 in some EU jurisdictions). We do not knowingly collect data from anyone under that age. If you believe a child has created an account, contact us and we will remove it.

We do not perform automated decision-making or profiling that produces legal or similarly significant effects on you. Stats and timelines are descriptive aggregations of events you uploaded — no scoring, ranking against other users, or eligibility decisions are made.

Passwords are hashed with Argon2id. Sessions are HttpOnly + Secure cookies with a 1-hour TTL. The API uses RS256 JWTs signed by a key generated on the server. All ingress is served over HTTPS with HSTS. Database connections require TLS in our production deployment. Access to the deployment's underlying infrastructure is limited to the project maintainer.

Two-factor authentication (optional). If you enable it, we store your TOTP shared secret encrypted with AES-256-GCM under a key held in a file outside the database, with a fresh nonce per encryption. Recovery codes are stored only as Argon2 hashes — we can verify a code you give us but cannot read it back. Disabling 2FA wipes both the secret and the recovery-code rows.

Magic-link and 2FA flows use single-use, short-lived interim tokens (15 minutes for magic links, 5 minutes for the post-password 2FA token); a leaked link or interim token without the matching second factor is useless on its own. Failed sign-in attempts are timing-equalised to avoid revealing whether an email maps to an account.

If we ever discover a personal-data breach that is likely to result in a risk to your rights and freedoms, we will notify you and the relevant supervisory authority within 72 hours of becoming aware, in line with Art. 33 / 34.

When we change this policy in a way that affects you (new sub-processor, new category of data, new retention period) we update the "Last updated" date at the top and, for material changes, post a notice on the dashboard for existing users. Trivial wording fixes are not announced.