# Privacy-ModellWas gespeichert wird, was nicht, und die sensiblen Kategorien, die die Engine nie sieht.

## Architektur-Zusammenfassung

Das Privacy-Modell von Notification Guard ruht auf drei
strukturellen Eigenschaften:

1. **Nur lokale Daten.** Alles wird in der app-privaten
   SQLite-Datenbank gespeichert. Kein Cloud-Sync, kein
   serverseitiger Zustand, kein Konto.
2. **Keine Netzwerk-Manifest-Permission.**
   `android.permission.INTERNET` ist **nicht deklariert** im
   AndroidManifest. Die App kann keine Netzwerk-Calls machen —
   Punkt. Das ist via `aapt dump badging` verifizierbar.
3. **Privacy-Vorfilter.** Sensible App-Kategorien (Banking,
   2FA/Authenticator, Gesundheitswesen, Behörden-Apps) werden
   **bevor** die Regel-Engine ihre Benachrichtigungen sieht
   ausgefiltert. Ihre Inhalte gelangen nie in die Datenbank.

## Was gespeichert wird

Wenn eine Benachrichtigung zur Auswertung erfasst wird, landet
Folgendes in der lokalen SQLite-Datenbank:

- Der Paketname der ursprünglichen App (z. B. `com.whatsapp`).
- Ein Timestamp.
- Die zugewiesene Kategorie (Social, Games, News, Shopping,
  Streaming, etc.).
- Die Regel-Entscheidung: Allow, Snooze oder Block.
- Bei Block: Titel und Body-Text der Benachrichtigung (damit der
  Nutzer nachsehen kann, was unterdrückt wurde).

Für **geblockte** Benachrichtigungen werden Titel und Body
zusätzlich der **TTL-Bereinigung** unterworfen — per Default 24
Stunden nach Erfassung. „Alles löschen" leert alles sofort.

## Was nie gespeichert wird

Für Benachrichtigungen von Apps der **sensiblen Kategorien**:

- Das Paket wird an der Listener-Service-Grenze erkannt.
- Die Benachrichtigung wird **sofort durchgereicht**, ohne
  Auswertung und ohne Speicherung.
- Kein Titel, kein Body, keine Metadaten dieser Benachrichtigung
  erreichen je die Datenbank.

Die Sensible-Kategorien-Liste ist in der Regel-Engine
fest verdrahtet. Sie umfasst (nicht abschließend):

- Banking-Apps (DKB, PayPal, Sparkassen-Apps, …)
- 2FA-/Authenticator-Apps (Google Authenticator, Authy, …)
- Krankenkassen-Apps (TK, AOK, Barmer, …)
- Behörden-Apps (Bund-Services, Elster, …)

Diese Liste kann zur Build-Zeit per Konfiguration erweitert
werden — für Deployments, die zusätzliche sensible Kategorien
hinzufügen müssen (z. B. interne Firmen-Apps, die nie gefiltert
werden sollen).

## Google-Play-Compliance-Constraints

Die Architektur ist um sechs harte Compliance-Constraints aus
den aktuellen Google-Play-Policies herum strukturiert:

| ID | Constraint | Wie die App das erfüllt |
|---|---|---|
| C1 | Prominent Disclosure und Consent | 4-Schritt-Onboarding-Wizard vor Listener-Permission-Aktivierung. |
| C2 | Kein `SYSTEM_ALERT_WINDOW` | Re-Notifications laufen via `NotificationManager`, kein Overlay-Fenster. |
| C3 | Data-Retention-TTL | Konfigurierbare Retention (24h Default), periodischer Cleanup-Task, manuelles Löschen. |
| C4 | Contact-Picker statt `READ_CONTACTS` | Die volle `READ_CONTACTS`-Permission wird **nicht** verwendet. Künftige kontaktbewusste Regeln nutzen den Android Contact Picker. |
| C5 | Privacy-Filter (Sensible-Kategorien-Blocklist) | Hardcoded Vorfilter am Engine-Eingang. |
| C6 | Kein Netzwerk-Layer | `android.permission.INTERNET` nicht im Manifest. Keine HTTP-Client-Dependencies in irgendeiner `Cargo.toml`. |

Das sind keine Absichtserklärungen — das ist strukturell. Jeden
einzelnen davon zu entfernen würde eine Architektur-Änderung
erfordern, nicht nur einen Config-Flip.

## Manifest-Permissions

Vier deklarierte Permissions, jede an ein konkretes Feature
gebunden:

- **`BIND_NOTIFICATION_LISTENER_SERVICE`** — Kern-Funktion. Ohne
  diese kann die App keine Benachrichtigungen lesen oder filtern.
  Nutzer-Aktivierung über System-Einstellungen.
- **`RECEIVE_BOOT_COMPLETED`** — Verbindet den Listener nach
  Geräte-Reboot wieder.
- **`WAKE_LOCK`** — Triggert Snooze-Timer zuverlässig aus dem
  Doze-Modus (geplant für Phase 2).
- **`POST_NOTIFICATIONS`** — Stellt eigene Re-Notifications
  (released oder snoozed) ohne Overlay-Fenster dar (siehe C2).

Keine Runtime-Permissions, kein restricted Special-Access jenseits
des Notification-Listeners.

## Wie verifizieren

Wenn du evaluierst, das in deiner Organisation auszurollen:

1. **APK-Manifest inspizieren.**

   ```sh
   aapt dump badging notification-guard.apk | grep -i permission
   ```

   Bestätigen, dass `android.permission.INTERNET` nicht
   auftaucht.

2. **Netzwerk-Verhalten beobachten.**

   App auf einem Test-Gerät mit vollem Traffic-Capture (PCAP,
   ein transparenter Proxy) laufen lassen. Bestätigen, dass
   keine ausgehenden Verbindungen entstehen.

3. **Datenbank inspizieren.**

   Die SQLite-Datei liegt im app-privaten Speicher. Auf einem
   gerooteten Test-Gerät rauskopieren und bestätigen, dass keine
   Benachrichtigungen von Apps der sensiblen Kategorien
   erscheinen.

Wenn einer dieser Checks ein Ergebnis liefert, das du nicht
erwartest, bitte Details über die [Kontakt](/de/contact/)-Seite
schicken. Das ganze Produkt hängt davon ab, dass diese Garantien
verifizierbar sind.