Privacy model

Architecture summary#

Notification Guard’s privacy model rests on three structural properties:

1. Local-only data. Everything is stored in the app-private SQLite database. No cloud sync, no server-side state, no account.
2. No network manifest permission. android.permission.INTERNET is not declared in the AndroidManifest. The app cannot make network calls — period. This is verifiable via aapt dump badging.
3. Privacy pre-filter. Sensitive app categories (banking, 2FA/authenticator, healthcare, public-authority apps) are sorted out before the rules engine sees their notifications. Their content never enters the database.

What is stored#

When a notification is captured for evaluation, the following is written to the local SQLite database:

• The originating app package name (e.g. com.whatsapp).
• A timestamp.
• The category assigned (Social, Games, News, Shopping, Streaming, etc.).
• The rule decision: allow, snooze, or block.
• If blocked: the notification’s title and body text (so the user can review what was suppressed).

For blocked notifications, the title and body are also subject to TTL cleanup — by default, 24 hours after capture. Manual “Clear all” purges everything immediately.

What is never stored#

For notifications from any app in the sensitive categories list:

• The package is recognized at the listener-service boundary.
• The notification is passed through immediately, without evaluation or storage.
• No title, no body, no metadata about that notification ever reaches the database.

The sensitive-category list is hardcoded in the rules engine. It includes (non-exhaustive):

• Banking apps (DKB, PayPal, savings-bank apps, …)
• 2FA / authenticator apps (Google Authenticator, Authy, …)
• Health-insurance apps (TK, AOK, Barmer, …)
• Public-authority apps (federal services, Elster, …)

This list can be extended via configuration at build time — for deployments that need to add additional sensitive categories (e.g. internal corporate apps that should never be filtered).

Google Play compliance constraints#

Notification Guard’s architecture is structured around six hard compliance constraints derived from current Google Play policies:

These are not aspirational — they are structural. Removing any one of them would require an architecture change, not just a config flip.

Manifest permissions#

Four declared permissions, each tied to a concrete feature:

• BIND_NOTIFICATION_LISTENER_SERVICE — Core function. Without this, the app cannot read or filter notifications. User-activated via system settings.
• RECEIVE_BOOT_COMPLETED — Reconnects the listener after a device reboot.
• WAKE_LOCK — Triggers snooze timers reliably from Doze mode (planned for phase 2).
• POST_NOTIFICATIONS — Surfaces our own re-notifications (released or snoozed) without an overlay window (see C2).

No runtime permissions, no restricted special access beyond the notification listener.

How to verify#

If you are evaluating whether to deploy this in your organization:

1. Inspect the APK manifest.

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

   Confirm that android.permission.INTERNET does not appear.

2. Inspect network behaviour.

   Run the app on a test device with full traffic capture (PCAP, a transparent proxy). Confirm no outgoing connections.

3. Inspect the database.

   The SQLite file lives in app-private storage. On a rooted test device, copy it out and confirm that no notifications from sensitive-category apps appear.

If any of those checks comes back with a result you would not expect, please send details via the Contact page. The whole product depends on these guarantees being verifiable.