Logging Privacy¶

Diese Leitlinie beschreibt die minimalen Guardrails fuer Backend-Logs und Client-Logs in TargetShot.

Ziel¶

Logs sollen betriebliche Fehlerdiagnose ermoeglichen.
Logs sollen keine unnötigen personenbezogenen Daten oder Secrets transportieren.
Client-Logs sind ein Admin-Werkzeug und kein frei lesbarer Debug-Stream.

Folgende Inhalte duerfen nicht unkontrolliert in Logs oder Client-Log-Payloads landen:

Access-Tokens, Refresh-Tokens, JWTs, Passwoerter, Secrets und Authorization-Header
rohe Request-Bodies aus Mitglieder-, Auth- oder Admin-Pfaden
vollstaendige Mitgliederobjekte oder Beispiel-Responses
direkte E-Mail-Adressen, sofern eine maskierte Form fuer den Betriebsfall ausreicht
hochaufloesende Browser-Fingerprints oder client-seitig gesetzte Rollenfelder

GET /api/client-logs ist nur fuer Admins vorgesehen.
Client-Logs speichern nur reduzierte Betriebsmetadaten:
level / type
redacted message
route
status
method
latencyMs
online
grob zusammengefasster userAgent
Rohe url und client-seitige Rollenwerte werden nicht persistiert.
Low-signal console.log- und console.info-Rauschen wird nicht an den Server weitergereicht.

Aus dem Web wird stack weiterhin nicht persistiert.
Aus der App (source: 'mobile') wird stack persistiert — redigiert wie die message und hart begrenzt auf 40 Zeilen bzw. 2000 Zeichen.
Betriebsnutzen: In einem Store-Build gibt es weder Konsole noch Sourcemaps im Zugriff. Ohne Stack ist eine Meldung wie „undefined is not an object" nicht verortbar, und der Fehler bleibt unauffindbar. Im Browser ist der Stack verzichtbar, weil der Tester die Konsole hat.
Datenschutzbedarf: Ein Hermes-Stack traegt Bundle-Positionen (index.bundle:1:2), keine Nutzerdaten und keine URLs mit Parametern — anders als ein Browser-Stack. Er laeuft zusaetzlich durch dieselbe Redaktion (Bearer-Tokens, JWTs, Secrets, E-Mail-Adressen).
Der Stack ist ueber die Admin-Lesepfade sichtbar; die Aufbewahrung von 30 Tagen und die Admin-Beschraenkung gelten unveraendert.

source, platform und appVersion sind additiv: Web-Clients senden sie nicht, das alte Format bleibt gueltig.
platform und appVersion sind Kennzeichen, keine Freitexte — sie werden auf A-Z a-z 0-9 . _ ( ) - reduziert und ersetzen bei App-Meldungen den nutzlosen Request-User-Agent (okhttp/…, CFNetwork/…) durch TargetShot 1.0.1 (42) / ios 18.0.
Als route meldet die App das Routen-Muster (/duelle/[id]), nicht den aufgeloesten Pfad — eine fremde Kennung im Pfad wuerde sonst mitgehen.

Lokale Browser-Logs werden derzeit fuer maximal 7 Tage im Local Storage gehalten.
Die App haelt ihren Fehlerpuffer nur im Speicher (max. 50 Eintraege, endet mit dem Prozess) und sendet je Sitzung hoechstens 60 Eintraege in Buendeln zu 20; liegengebliebene Buendel (Drossel, Fehlschlag, Rest eines Bursts) schiebt ein Weckruf-Timer nach, ohne auf einen neuen Fehler zu warten.
Das Rate-Limit der Route (10 Requests/Minute) gilt je IP — hinter einer Vereins-IP teilen sich alle Geraete plus Web EIN Budget. Die App wertet 429 deshalb nicht als Fehlschlag Richtung Aufgeben, sondern wartet 75–105 s (mit Streuung) und versucht es erneut.
Persistierte Backend-Client-Logs werden auf eine operative Retention von 30 Tagen begrenzt.
Ingest-Payloads werden pro Request hart begrenzt und auf allowlist-basierte Typen reduziert.

Member-Fehlerpfade loggen keine kompletten Sample-Responses.
Reconcile-/Sync-Fehler loggen keine rohen Bodies.
Direkte Kontaktinformationen werden fuer Logs wenn moeglich maskiert.
Club-Kontext soll in Logs bevorzugt als Count oder Scope-Meta statt als volle Liste auftauchen.

Bei neuen Logging-Pfaden gilt:

Nur loggen, was fuer Betrieb oder Fehlerdiagnose wirklich noetig ist.
Freie Textfelder zuerst redigieren oder auf reduzierte Meta-Informationen abbilden.
Admin-/Support-Lesepfade explizit absichern.
Neue Client-Log-Felder nur einfuehren, wenn ihr Betriebsnutzen und Datenschutzbedarf zusammen dokumentiert sind.