Model prywatności

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:

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.

   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. Cały produkt zależy od tego, że te gwarancje są weryfikowalne.