Clean Clock – Richtlinie zur Observability & Diagnose (Observability Policy)

Stand: 2026-04-19

Diese Richtlinie beschreibt, welche Daten zu Diagnosezwecken erfasst werden, wie sie geschützt werden und wann sie gelöscht werden. Ziel ist eine maximale Transparenz gemäß DSGVO-Bestimmungen.

Was protokolliert wird

Client-Seite (Flutter App)

  • Ereignisnamen: Übergänge zwischen Bildschirmen/Flows, Start/Erfolg/Fehlschlagen von Aktionen.
  • Korrelations-IDs: Zufällig generierte Trace-IDs zur technischen Verknüpfung von Client- und Server-Ereignissen.
  • Fehlercodes: Strukturierte technische Fehlerkennungen (z. B. GPS_PERMISSION_DENIED).
  • HTTP-Statuscodes: Antwortstatus von Backend-Aufrufen (z. B. 200, 403, 500).
  • Plattforminformationen: Betriebssystem (web, ios, android) und App-Build-Version.
  • GPS-Status-Kategorien: Ausschließlich Status-Indikatoren wie inside_radius, outside_radius, accuracy_low, permission_denied, timeout.
  • Zeitstempel: Zeitpunkt des Ereignisses in UTC (ISO 8601).

Server-Seite (Supabase Edge Functions)

  • Ereignisnamen: Eingang von Anfragen, Erfolg/Fehlschlagen von RPC-Aufrufen, Validierungsfehler.
  • Korrelations-IDs: Übernahme aus dem x-correlation-id-Header oder automatische Generierung.
  • Funktionsname: Name der verarbeitenden Edge Function.
  • Benutzer-ID: Supabase Auth User ID (ausschließlich zur Verifizierung der Zugriffsberechtigung).
  • Fehlermeldungen: Bereinigte Meldungen; Stack-Traces werden in öffentlichen Antworten unterdrückt.

Was NICHT erfasst wird (Ausschlussliste)

  • Rohe GPS-Koordinaten: Breitengrad und Längengrad werden niemals in Logs gespeichert (nur Status-Kategorien).
  • Zugangsdaten: Passwörter, Sitzungs-Token, API-Schlüssel oder Secrets.
  • Persönliche Identifikatoren: E-Mail-Adressen und Klarnamen werden in Logs automatisch geschwärzt.
  • Nutzdaten: Vollständige Request- oder Response-Payloads (Inhalte von Nachrichten etc.).
  • Systeminterna: Lokale Dateipfade oder detaillierte Systemkonfigurationen des Endgeräts.

Aufbewahrung & Löschung (Retention)

Clientseitiger Puffer (In-Memory)

  • Speicherung: Ausschließlich im flüchtigen Arbeitsspeicher (Ringpuffer); keine Speicherung auf dem Datenträger.
  • Kapazität: Maximal die letzten 100 Ereignisse.
  • Lebensdauer: Der Puffer wird bei jedem Neustart der App vollständig gelöscht.
  • Export: Daten verlassen das Gerät nur durch explizite Nutzeraktion (Opt-in) über den Diagnose-Bildschirm.
  • Zugriffsschutz: Nur verfügbar, wenn das Flag DEBUG_DIAGNOSTICS aktiv ist.

Serverseitige Protokolle

  • Speicherung: Protokollfunktion der Supabase Edge Function Laufzeitumgebung.
  • Aufbewahrungsfrist: Gemäß den Standardrichtlinien der Supabase-Plattform (in der Regel 7 Tage).
  • Zugriff: Eingeschränkt auf Administratoren des Supabase-Projekts.
  • Keine Datenbank-Logs: Es werden keine persistenten Datenbanktabellen für Observability-Logs geführt.

Schwärzung (Redaction)

Alle Protokollausgaben durchlaufen einen automatisierten Filter:

  • JWT/Token → <token-redacted>
  • E-Mail-Adressen → <email-redacted>
  • Sensible Felder (Password, Secret) → <redacted>
  • Personenbezogene Felder (Name, Telefon) → <personal-redacted>

Zugriffskontrolle & Sicherheit

  • Export: Der Export von Client-Diagnosedaten ist technisch an ein Compile-Time-Flag gebunden.
  • Schnittstellen: Es existieren keine öffentlichen API-Endpunkte zum Abruf von Logdaten.
  • Nutzerinteraktion: Ein Versand von Diagnosedaten erfordert eine bewusste Handlung des Nutzers (Kopieren oder Senden).

Zweckbindung (Purpose)

Die Erfassung von Observability-Daten erfolgt ausschließlich zu folgenden Zwecken:

  1. Fehlerdiagnose: Identifikation technischer Instabilitäten (z. B. GPS-Fehler, RPC-Timeouts).
  2. Support: Nachverfolgung von nutzergemeldeten Problemen mittels Korrelations-IDs.
  3. Systemintegrität: Überwachung der allgemeinen Fehlerraten und Dienstverfügbarkeit.

Eine Nutzung zu Werbezwecken, zur Erstellung von Nutzerprofilen oder eine Weitergabe an Dritte findet nicht statt.

Scroll to Top