5d6c322129
Sheets via neuer KeyboardAwareSheet-Composable (in Modal pattern, auto-grow mit Tastatur, paddingBottom-Lift): EditMail, AddDomain, CreateRoom, ConnectMail. GameOverScreen behält Spring-Slide-In, nutzt RN Keyboard.addListener für Lift. - KeyboardAwareSheet.tsx — universal modal with sheet-grow + keyboard-padding - react-native-keyboard-controller installiert + KeyboardProvider in Root - Snake: time + ScoreProgressBar + useSnakeSounds (haptic, audio TODO) - Tetris: title weg, Buttons zentriert, kein Pressable mit style-fn - DPad-Buttons 60→48, more bg, no scale - useMe: pub-sub listener pattern für app-weite avatar/nickname-Updates - dm.tsx: resolveAvatar wrap (iron.png-Warning) - Mail-error-humanizer + locales Recovery-Doc-Update in docs/internal/RECOVERY_LOG_2026-05-10.md Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
197 lines
11 KiB
Markdown
197 lines
11 KiB
Markdown
# Rebreak — Privacy-Policy User-Notes (DSB-Begleitdokument)
|
||
|
||
**Stand:** 2026-05-09
|
||
**Verfasser:** Hans Müller (externer DSB i.V.)
|
||
**Adressat:** Chahine Brini (Inhaber Rebreak / künftig Raynis GmbH)
|
||
**Kontext:** Begleitnotiz zur veröffentlichten Datenschutzerklärung v1 vom 09.05.2026
|
||
|
||
---
|
||
|
||
## ACHTUNG — HIGH-PRIO Flag
|
||
|
||
> **User wünscht ausdrücklich KEIN separates Consent-UI** für die Stufe-1-Übertragung
|
||
> von Lyra-Chat-Inhalten an Groq/Anthropic. Die Transparenz wird ausschließlich über
|
||
> § 11 Abs. 2–3 der Datenschutzerklärung sowie die übergeordnete Art. 9 Abs. 2 lit. a-
|
||
> Einwilligung beim Lyra-Onboarding hergestellt.
|
||
>
|
||
> **DSB-Bewertung:** Vertretbar bei Stufe 1, da kein Klarname/keine E-Mail/keine
|
||
> Account-ID übermittelt wird. Voraussetzung: das Lyra-Onboarding muss eine echte,
|
||
> granulare, vorab-eingeholte Einwilligung sein (nicht im AGB-Sammelhaken). Sobald
|
||
> identifizierende Inhalte im Chat stehen, ist Stufe 2 Pflicht. **Ziel-Datum für
|
||
> Stufe 2: Q3 2026 (siehe Migrations-Plan unten).**
|
||
|
||
---
|
||
|
||
## 1. TODO — DPA / AVV-Status der 12 Sub-Auftragsverarbeiter
|
||
|
||
| # | Anbieter | Sitz | DPA-Status | TIA | Action |
|
||
|---|---|---|---|---|---|
|
||
| 1 | Hetzner Online GmbH | DE (EU) | TODO — Standard-AVV vorbereitet | n/a | Bei Hetzner: Anhang 4 + 5 ausfüllen, gegenzeichnen lassen |
|
||
| 2 | Stripe Payments Europe Ltd. | IE (EU) → Stripe Inc. (USA) | TODO — Stripe-DPA online akzeptieren (Dashboard) | TODO leichtgewichtig | https://stripe.com/legal/dpa |
|
||
| 3 | Groq, Inc. | USA | OFFEN — auf Groq-DPA warten / via Sales anfragen | TODO PFLICHT | Hoch-Prio: Groq Sales kontaktieren falls kein Self-Service DPA |
|
||
| 4 | Anthropic PBC | USA | TODO — Anthropic Commercial-Terms + DPA-Addendum | TODO PFLICHT | https://www.anthropic.com/legal/commercial-terms |
|
||
| 5 | OpenRouter, Inc. | USA | OFFEN — DPA-Verfügbarkeit unklar, ggf. nicht produktiv nutzen | TODO PFLICHT | Falls keine SCCs verfügbar: Provider rauswerfen |
|
||
| 6 | Cartesia, Inc. | USA | OFFEN — DPA anfordern | TODO PFLICHT | Falls TTS optional: erst aktivieren, wenn DPA vorliegt |
|
||
| 7 | ElevenLabs Inc. | USA | TODO — ElevenLabs Enterprise-DPA | TODO PFLICHT | https://elevenlabs.io/dpa |
|
||
| 8 | Deepgram, Inc. | USA | TODO — Deepgram-DPA via Account-Manager | TODO PFLICHT | Falls STT optional: erst aktivieren, wenn DPA vorliegt |
|
||
| 9 | Cloudflare, Inc. | USA (EU-Edge) | TODO — Cloudflare-DPA online | leichtgewichtig | https://www.cloudflare.com/cloudflare-customer-dpa/ |
|
||
| 10 | Apple Inc. (APNs) | USA | abgedeckt durch Apple Developer Program License Agreement | leichtgewichtig | Existierender ADP-Vertrag enthält DPA-Anhang |
|
||
| 11 | Google LLC (FCM) | USA | TODO — Firebase-DPA via Console | leichtgewichtig | https://firebase.google.com/terms/data-processing-terms |
|
||
| 12 | Infisical Inc. | USA | TODO — DPA falls verfügbar; ohne Endnutzer-PII niedrige Prio | n/a | Niedrige Prio (nur tech-Secrets, keine Endnutzer-Daten) |
|
||
|
||
**Zusammenfassung:** 0 von 12 DPAs aktuell formal abgeschlossen. Empfehlung: Hetzner +
|
||
Stripe + Anthropic + Groq + Cloudflare + Firebase als Top-6 priorisieren (decken die
|
||
materiellen Drittland-Übertragungen ab). Realistisches Zeitfenster: 4–6 Wochen.
|
||
|
||
---
|
||
|
||
## 2. Anwalt-Review-Checkliste — 3 kritische Punkte
|
||
|
||
> **Ich (DSB) bin kein Rechtsanwalt.** Folgende Passagen sind vor produktiver
|
||
> Veröffentlichung der Policy zwingend durch eine im IT-/Datenschutzrecht
|
||
> spezialisierte Kanzlei zu prüfen.
|
||
|
||
### 2.1 Pro-Trial als Gegenleistung für demographische Daten — Risk: HOCH
|
||
|
||
**Stelle:** § 5 Abs. 4 Datenschutzerklärung („Pro-Trial-Reward")
|
||
**Norm:** Art. 7 Abs. 4 DSGVO (Kopplungsverbot), EDSA-Leitlinien 05/2020
|
||
**Risiko:** Aufsichtsbehörden bewerten „Vorteil gegen Datenpreisgabe" zunehmend
|
||
restriktiv. Argumentation „Pro-Features gehen über Kernleistung hinaus" ist tragfähig,
|
||
aber nicht risikolos.
|
||
**Anwaltsfrage:** Reicht die transparente Darstellung + jederzeitige
|
||
Widerrufsmöglichkeit + keine-Kopplung-an-Kernfunktion-Klausel zur Rechtfertigung?
|
||
Empfehlung: alternative Formulierungen (z. B. „Anerkennung" statt „Belohnung"), ggf.
|
||
Ergänzung um pseudonyme Erhebungs-Variante als Default.
|
||
|
||
### 2.2 LLM-Übertragung Stufe 1 ohne separates Consent-UI — Risk: MITTEL
|
||
|
||
**Stelle:** § 11 Abs. 2–3
|
||
**Norm:** Art. 9 Abs. 2 lit. a DSGVO, Erwägungsgrund 32 (Granularität der
|
||
Einwilligung), Art. 12 DSGVO (Verständlichkeit)
|
||
**Risiko:** Aufsichtsbehörden könnten argumentieren, dass die spezifische
|
||
Drittland-Übertragung von Gesundheitsdaten an US-LLM-Anbieter eine eigene, granulare
|
||
Einwilligung erfordert.
|
||
**Anwaltsfrage:** Reicht die übergeordnete Lyra-Onboarding-Einwilligung +
|
||
transparente Darstellung in der Datenschutzerklärung aus? Falls nein: Mindest-Anforderung
|
||
an UI-Hinweis (z. B. einmalige In-Chat-Notiz „Lyra-Antworten werden via US-Anbieter
|
||
generiert", ohne Klick-Block) festlegen. **User-Position:** kein separates Consent-UI
|
||
gewünscht — Anwalt soll konkret ja/nein dazu sagen.
|
||
|
||
### 2.3 Übergangsklausel Einzelunternehmer → Raynis GmbH — Risk: MITTEL
|
||
|
||
**Stelle:** § 1 Abs. 2
|
||
**Norm:** Art. 7 DSGVO (Einwilligung gegenüber konkretem Verantwortlichen), § 25 UmwG /
|
||
Asset-Deal-Mechanik, Erwägungsgrund 42 DSGVO
|
||
**Risiko:** Bestehende Einwilligungen wurden gegenüber „Chahine Brini, einzelkaufmännisch"
|
||
erteilt. Ein einseitiger „Geht-auf-die-GmbH-über"-Hinweis kann nach Aufsichtsbehörden-
|
||
Lesart unzureichend sein — insbesondere bei Art. 9-Daten.
|
||
**Anwaltsfrage:** Reicht eine vorab-Information per E-Mail + In-App-Notice zur
|
||
Übertragung der Einwilligung auf die GmbH, oder muss eine erneute aktive
|
||
Bestätigung („Re-Consent") eingeholt werden? Gilt unterschiedliche Behandlung für
|
||
Art. 6 vs. Art. 9 Daten? Wir empfehlen, als Default einen Re-Consent-Flow vorzubereiten
|
||
und ggf. nicht zu nutzen, falls Anwalt Entwarnung gibt.
|
||
|
||
---
|
||
|
||
## 3. Stufe-2-Migrations-Plan: Lyra-Pseudonymisierung (Q3 2026)
|
||
|
||
### Ziel
|
||
Pre-Processing-Layer im backend zwischen `coach/sos-stream`-Endpoint und LLM-Provider,
|
||
der personenbezogene Entitäten (Namen, Orte, E-Mails, Telefonnummern, IBANs,
|
||
Verein-/Firmennamen) maskiert, BEVOR der Prompt das Backend verlässt.
|
||
|
||
### Technische Schritte (high-level Spec, Detail-Spec geht an `rebreak-backend`)
|
||
|
||
1. **Library-Auswahl (KW 27–28 / Juli 2026):**
|
||
- Kandidaten: `@microsoft/presidio-analyzer` (Python, via Sidecar), `compromise`
|
||
(JS, lightweight), self-hosted spaCy-Service mit dt. Modell.
|
||
- Trade-off: Latenz vs. Recall. Ziel: < 80 ms p95-Overhead pro Nachricht.
|
||
|
||
2. **Maskierungs-Mapping (KW 28):**
|
||
- Pro Conversation eine ephemere ID-Tabelle (memory-only, 30 min TTL).
|
||
- Maskierungen: `[PERSON_1]`, `[ORT_1]`, `[EMAIL]`, `[PHONE]`.
|
||
- Re-Substitution beim Streaming-Output: vor dem Senden an Client zurückübersetzen
|
||
(User soll seine eigenen Namen wieder sehen).
|
||
|
||
3. **Backend-Hook (KW 29):**
|
||
- Neuer Service `backend/server/services/pii-mask.ts` mit zwei Funktionen:
|
||
`maskBeforeLLM(prompt, conversationId)` und `unmaskAfterLLM(stream, conversationId)`.
|
||
- Integration in `backend/server/api/coach/sos-stream.get.ts`.
|
||
|
||
4. **Telemetrie + Eval (KW 30–31):**
|
||
- Anonymisierte Metriken: Anzahl Maskierungen pro Nachricht, Latenz, False-Positive-
|
||
Rate (manuelle Stichprobe von 200 Konversationen).
|
||
- DSFA-Update mit Stufe-2-Beschreibung.
|
||
|
||
5. **Privacy-Policy-Update (KW 32):**
|
||
- § 11 Abs. 2 in Stufe-1- und Stufe-2-Beschreibung umstellen.
|
||
- Versionierungs-Hinweis nach § 16.
|
||
|
||
### Voraussetzungen / Blocker
|
||
|
||
- DPAs aller LLM-Anbieter müssen vorher unterschrieben sein (siehe Punkt 1).
|
||
- DSFA-Update muss parallel laufen (Hans Müller).
|
||
- Backend-Sprint mit ca. 8–12 Personentagen Aufwand schätzbar.
|
||
|
||
---
|
||
|
||
## 4. Backyard-Migration-Empfehlung — Marketing-Site / Privacy-Page
|
||
|
||
### Status quo
|
||
|
||
- `datenschutz.vue` und (neu) `privacy-policy.vue` liegen aktuell im trucko-monorepo
|
||
unter `apps/rebreak/app/pages/`.
|
||
- Deployment der Marketing-Site läuft separat (nicht über Hetzner-Backend-Pipeline).
|
||
|
||
### Empfehlung an `rebreak-strategist` + `backyard`
|
||
|
||
Die öffentlich kommunizierte Datenschutzerklärung sollte mittelfristig im
|
||
**rebreak-monorepo** leben und über die etablierte Hetzner-Pipeline deployt werden.
|
||
Begründung:
|
||
|
||
1. **Versionskontrolle + Audit-Trail** — bei einer DiGA-Anwendung ist die Historie der
|
||
Datenschutzerklärung als Compliance-Nachweis relevant. Liegt sie im Hauptrepo, ist
|
||
sie Teil derselben CI/CD-Logik und Backups wie der Backend-Code.
|
||
2. **Stand-Konsistenz** — derzeitige Trennung führt zu Stand-Drift (Marketing-Site:
|
||
01.05.; Backend-Realität: 09.05.). Single-Source-of-Truth-Prinzip.
|
||
3. **Hetzner-Hosting** — Datenresidenz EU/DE-konsistent ohne Cloudflare-Pages-Drittland-
|
||
Risiko (sofern Marketing-Site aktuell dort läuft).
|
||
|
||
**Action:** Backyard-Agent erstellt Migrations-Plan (geschätzt 2 Sprint-Punkte). Bis
|
||
dahin pflegen wir die Datei in trucko, mit Cross-Reference im rebreak-monorepo
|
||
(`docs/internal/PRIVACY_POLICY_USER_NOTES.md` ← du liest sie gerade).
|
||
|
||
---
|
||
|
||
## 5. Risk-Summary (Snapshot 09.05.2026)
|
||
|
||
| Bereich | Risk-Level | Begründung | Mitigation |
|
||
|---|---|---|---|
|
||
| Drittland-Transfer Lyra (Groq/Anthropic) | KRITISCH bis DPAs vorliegen, danach MITTEL | Art. 9-Daten in USA, FISA 702 Risiko | DPAs + TIA + Stufe-2-Pseudo Q3 2026 |
|
||
| Pro-Trial-Kopplung | HOCH | Art. 7 Abs. 4 DSGVO Auslegungs-Risiko | Anwalt-Review + transparente Darstellung |
|
||
| Re-Consent bei Raynis-GmbH-Übergang | MITTEL | Einwilligungs-Adressat ändert sich | Re-Consent-Flow vorbereiten |
|
||
| Demographische Daten | NIEDRIG | Streng user-initiated, klare Trennung von Lyra-Memories | Profile-Form-Validierung |
|
||
| Mail-Schutz-Modul | MITTEL bei Aktivierung | Tiefer Eingriff in Mailbox eines Suchterkrankten | Echte opt-in, granulare Einwilligung |
|
||
| Cookie/Tracking | NIEDRIG | Keine Drittanbieter-Tracker im Einsatz | Keine Action |
|
||
| Push-Notifications | NIEDRIG–MITTEL | APNs/FCM = USA-Transfer + Inhalt kann Gesundheitsbezug haben | Inhalt der Push-Texte minimieren („Du hast eine Erinnerung" statt „Streak gefährdet") |
|
||
| Drittland Anbieter ohne DPA | KRITISCH bis geklärt | OpenRouter, Cartesia, Deepgram unklar | Falls kein DPA: Anbieter rauswerfen |
|
||
|
||
---
|
||
|
||
## 6. Nächste Schritte (priorisiert)
|
||
|
||
1. **Diese Woche:** Hetzner-AVV + Stripe-DPA + Cloudflare-DPA + Firebase-DPA online
|
||
abschließen (alle Self-Service, < 2h Aufwand zusammen).
|
||
2. **KW 20 (12.–18.05.):** Anthropic Commercial-Terms / Groq DPA-Anfrage absetzen.
|
||
3. **KW 20:** Anwalt-Termin zu den 3 Punkten in Sektion 2 vereinbaren.
|
||
4. **KW 21:** OpenRouter / Cartesia / Deepgram-Status klären → ggf. aus Verarbeitungs-
|
||
verzeichnis und § 6-Tabelle streichen, bis DPA vorliegt.
|
||
5. **KW 22–23:** Verarbeitungsverzeichnis (Art. 30 DSGVO) als separates Dokument
|
||
erstellen (Vorlage GDD / LfD Niedersachsen verwenden).
|
||
6. **KW 24–28:** DSFA gemäß Art. 35 DSGVO finalisieren.
|
||
7. **Q3 2026:** Stufe-2-Pseudonymisierung implementieren.
|
||
|
||
---
|
||
|
||
**Bei Rückfragen:** datenschutz@rebreak.org · Betreff „DSB-Notes v1"
|