# Model prywatnościCo jest zapisywane, co nie i wrażliwe kategorie, których silnik nigdy nie widzi.

## Podsumowanie architektury

Model prywatności Notification Guard opiera się na trzech właściwościach strukturalnych:

1. **Tylko dane lokalne.** Wszystko jest zapisywane w prywatnej bazie SQLite aplikacji. Brak cloud-sync, brak stanu po stronie serwera, brak konta.
2. **Brak permisji sieciowej w manifeście.** `android.permission.INTERNET` jest **nie zadeklarowany** w AndroidManifest. Aplikacja nie może wykonywać wywołań sieciowych — kropka. Weryfikowalne przez `aapt dump badging`.
3. **Prefiltr prywatności.** Wrażliwe kategorie aplikacji (bankowość, 2FA/authenticator, ochrona zdrowia, aplikacje urzędowe) są filtrowane **zanim** silnik reguł zobaczy ich powiadomienia. Ich treści nigdy nie trafiają do bazy danych.

## Co jest zapisywane

Gdy powiadomienie jest przechwytywane do oceny, w lokalnej bazie SQLite ląduje:

- Nazwa pakietu źródłowej aplikacji (np. `com.whatsapp`).
- Timestamp.
- Przypisana kategoria (Social, Games, News, Shopping, Streaming itd.).
- Decyzja reguły: Allow, Snooze lub Block.
- Przy Block: tytuł i treść powiadomienia (aby użytkownik mógł sprawdzić, co zostało zignorowane).

Dla **zablokowanych** powiadomień tytuł i treść są dodatkowo poddawane **czyszczeniu TTL** — domyślnie 24 godziny po przechwyceniu. „Usuń wszystko" czyści wszystko natychmiast.

## Co nigdy nie jest zapisywane

Dla powiadomień z aplikacji **kategorii wrażliwych**:

- Pakiet jest rozpoznawany na granicy listener-service.
- Powiadomienie jest **natychmiast przepuszczane** dalej, bez oceny i bez zapisu.
- Żaden tytuł, żadna treść, żadne metadane tego powiadomienia nigdy nie docierają do bazy danych.

Lista wrażliwych kategorii jest na sztywno wpisana w silniku reguł. Obejmuje (nie wyczerpująco):

- Aplikacje bankowe (mBank, PKO, Santander, …)
- Aplikacje 2FA/authenticator (Google Authenticator, Authy, …)
- Aplikacje ubezpieczeń zdrowotnych (NFZ, ZUS, …)
- Aplikacje urzędowe (mObywatel, e-PIT, …)

Lista ta może być rozszerzona przy buildzie przez konfigurację — dla deploymentów, które muszą dodać dodatkowe wrażliwe kategorie (np. wewnętrzne aplikacje firmowe, które nigdy nie powinny być filtrowane).

## Ograniczenia compliance Google Play

Architektura jest zbudowana wokół sześciu twardych ograniczeń compliance z aktualnych polityk Google Play:

| ID | Ograniczenie | Jak aplikacja je spełnia |
|---|---|---|
| C1 | Prominent Disclosure i Consent | 4-krokowy wizard onboardingu przed aktywacją permisji listenera. |
| C2 | Brak `SYSTEM_ALERT_WINDOW` | Re-notyfikacje idą przez `NotificationManager`, bez okna overlay. |
| C3 | TTL retencji danych | Konfigurowalna retencja (24h default), okresowy task cleanup, ręczne usunięcie. |
| C4 | Contact-Picker zamiast `READ_CONTACTS` | Pełna permisja `READ_CONTACTS` **nie** jest używana. Przyszłe reguły uwzględniające kontakty użyją Android Contact Picker. |
| C5 | Filtr prywatności (blocklista wrażliwych kategorii) | Na sztywno wbudowany prefiltr na wejściu silnika. |
| C6 | Brak warstwy sieciowej | `android.permission.INTERNET` brak w manifeście. Brak zależności HTTP-client w jakimkolwiek `Cargo.toml`. |

To nie są deklaracje intencji — to jest strukturalne. Usunięcie któregokolwiek z tych punktów wymagałoby zmiany architektury, nie tylko flipa konfiguracji.

## Permisje manifestu

Cztery zadeklarowane permisje, każda związana z konkretną funkcją:

- **`BIND_NOTIFICATION_LISTENER_SERVICE`** — funkcja rdzeniowa. Bez tego aplikacja nie może czytać ani filtrować powiadomień. Aktywacja przez użytkownika przez ustawienia systemowe.
- **`RECEIVE_BOOT_COMPLETED`** — Po rebootcie urządzenia ponownie podłącza listener.
- **`WAKE_LOCK`** — Triggeruje timery snooze niezawodnie z trybu Doze (planowane na fazę 2).
- **`POST_NOTIFICATIONS`** — Wyświetla własne re-notyfikacje (released lub snoozed) bez okna overlay (patrz C2).

Brak permisji runtime, brak restricted special-access poza notification-listener.

## Jak zweryfikować

Jeśli oceniasz wdrożenie tego w swojej organizacji:

1. **Inspekcja manifestu APK.**

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

   Potwierdzić, że `android.permission.INTERNET` nie pojawia się.

2. **Obserwacja zachowania sieciowego.**

   Uruchomić aplikację na urządzeniu testowym z pełnym capture ruchu (PCAP, transparentny proxy). Potwierdzić, że nie powstają wychodzące połączenia.

3. **Inspekcja bazy danych.**

   Plik SQLite leży w prywatnym storage aplikacji. Na zrootowanym urządzeniu testowym wyciągnąć i potwierdzić, że nie pojawiają się powiadomienia z aplikacji wrażliwych kategorii.

Jeśli któryś z tych checków daje wynik, którego się nie spodziewasz, prosimy o szczegóły przez stronę [Kontakt](/pl/contact/). Cały produkt zależy od tego, że te gwarancje są weryfikowalne.