rebreak-monorepo/backend/docs/consent-gap-plan.md
chahinebrini 0ab635c74a feat: art-9 consent flow + outlook-oauth schema + cooldown patterns + mail draft persist
DSGVO Art. 9 — Compliance-Gap im Mail-Connect-Flow geschlossen (Hans-Müller-DSB
hat den Gap für Gmail/iCloud/GMX identifiziert, schon vor Outlook-OAuth-Pflicht):

- Schema: mail_connections.consent_at + consent_version + consent_ip_address;
  neue consent_logs-Tabelle für Audit (grant + revoke append-only)
- Endpoints:
  - POST /api/mail-connections/consent (Bulk-Array für Re-Consent, partial-fail
    wirft sofort = DSGVO-sicher gegen silent-skip fremder IDs)
  - POST /api/mail-connections/:id mit consent-gate (412 wenn consentVersion fehlt)
  - DELETE /api/mail-connections/:id mit Widerruf-Log (OAuth-Token-Revoke als
    TODO für mo Phase 2)
  - GET /api/mail-connections/pending-consent — listet Bestands-Connections
    mit consent_at=NULL für Re-Consent-Modal
- Account-Lösch-Bug fix: deleteAllMailConnections() war in user/delete nicht
  eingebunden — Verbindungen blieben als Waisen
- Frontend:
  - ConnectMailSheet: neuer Consent-Step VOR Provider-Grid (view-Machine
    consent → grid → form), exakter Hans-Müller-Wortlaut für Art. 9 Abs. 2
    lit. a Einwilligung
  - MailConsentReminderSheet: Re-Consent-Modal beim App-Open für Bestands-User
  - Stores mailConsent + mailConnectDraft (letzterer fixt Bug: Email/Provider
    ging verloren wenn User Browser für App-Pw-Generierung öffnete)
  - 12 neue i18n-Keys mail.consent.* in DE + EN
- Versionierter Consent-Text: art9-mail-v1-2026-05-13 (Bump bei Text-Änderung
  triggert Re-Consent für alle)

Outlook-OAuth Schema (Phase 0 — additiv, Endpoints kommen später):

- mail_connections: auth_method (default 'app_password' → keine Bestands-
  Connection bricht), oauth_access_token, oauth_refresh_token,
  oauth_token_expiry, oauth_scope
- Encryption via bestehendes server/utils/crypto.ts (AES-256-GCM, Key aus
  Infisical)
- Plan-Doc backend/docs/mail-outlook-oauth-plan.md (mo)
- DSB-Review backend/docs/mail-outlook-oauth-dsgvo-review.md (Hans-Müller):
  MS als Sub-AV via DPA Sep 2025, EU Data Boundary seit Feb 2025; 5 Pflicht-
  Aufgaben + Anwalts-Klärung zu DPA-Anspruch ohne MS-Lizenz

Profile — Cooldown-Pattern-Analysis als Collapsible:

- CooldownPatternAnalysis: 24h-Uhrzeit-Heatmap, Mo–So-Wochentag-Histogramm,
  Top-5-Reason-Wortcloud mit Stop-Words-Filter, Cancel-Rate-Anzeige
- DiGA-relevant: NLP läuft client-side, reason-Texte verlassen das Device
  nicht (gut für DSB-Akte)
- useProfileData: useCooldownHistoryFull (limit=100) für Pattern-Analyse
- Neutral formuliert, kein Stigma, alle Headings als Frage

Plan-Docs (kein Code):

- backend/docs/mail-custom-keywords-plan.md — Pro/Legend Custom-Keyword-Filter
  (3.25 PT MVP, user-scoped, Body-Match in Phase 2)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 16:35:18 +02:00

6.8 KiB

Consent-Gap-Plan — Art. 9 DSGVO Mail-Auto-Delete

Stand: 2026-05-13 Autor: rebreak-backend-agent Status: Implementiert (Backend), TODOs für mo + rebreak-native-ui


Was wurde implementiert

Neue Spalten in mail_connections:

  • consent_at TIMESTAMPTZ NULL — wann eingewilligt, NULL = "Re-Consent pending"
  • consent_version TEXT NULL — z.B. "art9-mail-v1-2026-05-13"
  • consent_ip_address TEXT NULL — IP zum Zeitpunkt der Einwilligung

Neue Tabelle consent_logs:

  • Append-only Audit-Trail für alle Einwilligungen und Widerrufe
  • Wird NIEMALS gelöscht (Beweispflicht Art. 7 Abs. 1 DSGVO)

Backend-Dateien

Datei Zweck
server/utils/consent-texts.ts Versionierte Consent-Texte (DE + EN)
server/db/consent.ts DB-Layer: writeConsentGrant, writeConsentRevoke, getConsentLogsByUser, setMailConnectionConsent
server/api/mail-connections/consent.post.ts POST /api/mail-connections/consent
server/api/mail-connections/[id].post.ts POST /api/mail-connections/:id (mit Consent-Gate 412)
server/api/mail-connections/[id].delete.ts DELETE /api/mail-connections/:id (mit Widerruf-Log)
server/api/user/delete.delete.ts Erweitert: schreibt Widerruf für alle Connections bei Account-Löschung

"art9-mail-v1-2026-05-13" — definiert in server/utils/consent-texts.ts.


TODO #1 — mo (Mail-Stack / Daemon)

Daemon pausiert Verarbeitung wenn consent_at = NULL

Kontext: Alle Bestandsrows nach Migration haben consent_at = NULL. Das bedeutet "Re-Consent pending". Der Daemon darf für diese Connections KEIN Auto-Delete ausführen bis der User explizit eingewilligt hat.

Implementierung in imap-idle/index.mjs (oder wherever der Scan-Loop läuft):

// Beim Laden einer Connection für den Scan-Loop:
if (!connection.consent_at) {
  log(`[consent] Skipping ${connection.email}: Re-Consent pending (consent_at = NULL)`);
  // Verbindung aus dem aktiven Scan-Pool auslassen — KEIN Fehler, kein Error-State.
  // isActive bleibt true. Wenn User Re-Consent gibt, wird consent_at gesetzt
  // und die Connection beim nächsten Loop-Cycle wieder aufgenommen.
  continue;
}

Checklist:

  • mo — imap-idle/index.mjs: consent_at-Check im Connection-Load
  • mo — scan.post.ts / scan-internal.post.ts: gleiches Check (On-Demand-Scans)

TODO #2 — mo (OAuth Token-Revoke bei Disconnect)

Wenn OAuth-Connections getrennt werden: Token bei Microsoft revoken

Kontext: Wenn authMethod === 'oauth2_microsoft' (Outlook-OAuth, noch nicht live), muss beim Disconnect der Refresh-Token bei Microsoft widerrufen werden.

Placeholder-Comments existieren bereits in:

  • server/api/mail-connections/[id].delete.ts (User-Disconnect)
  • server/api/user/delete.delete.ts (Account-Löschung)

Implementierung wenn OAuth-Phase startet:

if (conn.authMethod === 'oauth2_microsoft') {
  const refreshToken = decrypt(conn.oauthRefreshToken);
  let revoked = false;
  for (let attempt = 0; attempt < 3; attempt++) {
    try {
      await fetch('https://login.microsoftonline.com/common/oauth2/v2.0/token', {
        method: 'POST',
        headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
        body: new URLSearchParams({
          grant_type: 'revoke',
          token: refreshToken,
          client_id: process.env.MS_OAUTH_CLIENT_ID,
          client_secret: process.env.MS_OAUTH_CLIENT_SECRET,
        }),
      });
      revoked = true;
      break;
    } catch (e) {
      // Retry
    }
  }
  // Audit-Log: Token-Revoke success/failure
  // Dann trotzdem DB-Row löschen (DSB-Memo Abschnitt 5.1)
}

TODO #3 — Datenexport (Art. 15 DSGVO)

consent_logs für den User in den Datenexport aufnehmen

Es gibt aktuell keinen /api/data-export-Endpoint im Backend. Wenn er gebaut wird (separater Sprint), muss er enthalten:

  • consent_logs für den User (aus getConsentLogsByUser(userId) in server/db/consent.ts)
  • Für jede MailConnection: Provider, verbundene E-Mail-Adresse, Verbindungs-Zeitpunkt, erteilte OAuth-Scopes (lesbar, kein Token-Inhalt), Token-Ablaufdatum

DSB-Memo Abschnitt 5.2 + Hans-Müller-To-Do-Liste Item #6.


Frontend-Spec für rebreak-native-ui (UI-Agent)

Trigger: App-Open + Auth-User eingeloggt + mindestens eine MailConnection mit consent_at = NULL (Backend: GET /api/mail/status liefert connections mit consentAt-Feld — Null-Check im Frontend).

Alternativ: neuer Endpoint GET /api/mail-connections/pending-consent der nur die IDs der Connections ohne Consent zurückgibt.

Modal-Inhalt:

  • Titel: aus getConsentText("art9-mail-v1-2026-05-13").de (oder .en je nach Locale)
  • Zwei Buttons: "Einwilligen" → POST /api/mail-connections/consent, "Verbindung trennen" → DELETE /api/mail-connections/:id

Nach "Einwilligen":

  • Pro Connection ein POST /api/mail-connections/consent senden
  • Body: { mailConnectionId: "<uuid>", consentVersion: "art9-mail-v1-2026-05-13" }
  • Bei 200: Modal schließen, Toast "Einwilligung erteilt"
  • Bei 409 (version_mismatch): sollte nicht passieren wenn Frontend aktuelle Version nutzt

Neuer Flow:

  1. User gibt Email + Passwort ein
  2. Vor dem Abschicken: Consent-Text anzeigen (Checkbox oder expliziter Button)
  3. POST /api/mail-connections/:id mit consentVersion im Body
  4. Bei 412 (consent_required): Consent-Modal anzeigen (sollte nicht vorkommen wenn Schritt 2 korrekt implementiert ist)
  5. Bei 200: Connection verbunden

Der consentVersion-Wert muss das Frontend kennen. Empfehlung: Backend liefert ihn via GET /api/mail/status oder einem neuen GET /api/mail-connections/consent-version- Endpoint. Alternativ: hardcoded im Frontend, aber dann muss er bei jedem Text-Bump synchronisiert werden.

Empfehlung: GET /api/mail-connections/consent-version

Einfacher Endpoint ohne Auth:

GET /api/mail-connections/consent-version
→ { version: "art9-mail-v1-2026-05-13", texts: { de: "...", en: "..." } }

Damit muss das Frontend die Version nie hardcoden. Noch nicht implementiert — als TODO für rebreak-backend falls UI-Agent es braucht.


  1. Hans-Müller gibt neuen Text frei
  2. Neuen Eintrag in server/utils/consent-texts.ts hinzufügen
  3. CURRENT_ART9_MAIL_VERSION auf neue Version setzen
  4. Alle bestehenden Connections mit alter Version bekommen automatisch Re-Consent-Modal (Daemon-Check: connection.consent_version !== CURRENT_ART9_MAIL_VERSION → pausieren)
  5. Deploy via GitHub Actions Pipeline

Nicht gemacht (explizit aus Scope ausgeschlossen)

  • Migration lokal ausgeführt — nein, Pipeline deployt
  • Frontend-Änderungen — UI-Agent-Task
  • Daemon-Logik angefasst — mo's Domain
  • git push — kein User-GO erteilt