Privacy-Modell

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:

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.

   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-Seite schicken. Das ganze Produkt hängt davon ab, dass diese Garantien verifizierbar sind.