Data Security

Last updated: 16 May 2026

This document describes the technical and organisational measures (TOMs as required by Art. 32 GDPR) used to protect personal data in SeizeIO. It complements the Privacy Policy.

1. Transmission

• All communication between the app and the backend is encrypted via HTTPS (TLS 1.2+) or WSS for WebSocket connections.
• HTTP Strict Transport Security (HSTS) is enabled server-side so browsers only open encrypted connections.
• Security headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy) are set on every response.

2. Authentication

• Identity management is handled by a dedicated Keycloak server (OpenID Connect / OAuth 2.0).
• Passwords are stored only as a hash (bcrypt, managed by Keycloak). Plain-text passwords never leave the device.
• Access tokens (JWT) are short-lived; a refresh-token flow allows seamless renewal without re-entering the password.
• On the device, tokens are stored in the operating system's secure storage (Android Keystore / iOS Keychain).

3. Authorisation and access

• All API endpoints require a valid access token, except for public information pages (such as this one).
• Data access is scoped per user: users can only modify their own account and movement data.
• Game-related data (routes, captures) is only shared inside the respective round with other participants.

4. Storage

• The database runs on managed infrastructure (Railway) with at-rest encryption; snapshots are also encrypted.
• Location points are kept in aggregated form (paths, territories) after processing. Raw GPS points are only kept as long as required by game logic.
• Server logs do not contain GPS coordinates and are automatically deleted after at most 30 days.

5. Input validation and abuse protection

• Rate limiting on authenticated endpoints prevents brute-force and scraping attacks.
• Plausibility checks on incoming GPS data reject unrealistic movement (per-mode speed limits, geographic jump detection).
• Inputs are validated server-side via typed schemas (Pydantic); SQL queries are exclusively parameterised (SQLAlchemy ORM).

6. Device

• The app only asks for location permissions when actually needed and shows its own disclosure (prominent disclosure) before each system prompt.
• During background tracking, Android requires a persistent system notification that cannot be hidden; on iOS a system location indicator in the status bar signals that tracking is active.
• If internet connectivity is lost, GPS points are buffered locally and uploaded automatically once connectivity returns.

7. Operations

• Backend and Keycloak run in isolated containers on Railway; access is via key-based authentication only.
• Secrets (API keys, DB credentials) are provided exclusively through the platform's secret manager and are never stored in source code.
• Dependencies are regularly scanned for known vulnerabilities.

8. Reporting vulnerabilities

Please report security-relevant findings confidentially to ajohe.ajohe@gmail.com. We aim to respond promptly and handle responsibly disclosed vulnerabilities with appropriate discretion.

9. Changes

This document is updated when the security measures in place change in a material way. The current version is always available at this URL.