Model de privacy

Rezumat de arhitectură#

Modelul de privacy al Notification Guard se sprijină pe trei proprietăți structurale:

1. Doar date locale. Totul este salvat în baza de date SQLite privată a aplicației. Fără cloud sync, fără stare server-side, fără cont.
2. Fără permisia de rețea în manifest. android.permission.INTERNET nu este declarată în AndroidManifest. Aplicația nu poate face apeluri de rețea — punct. Asta este verificabil prin aapt dump badging.
3. Prefiltru de privacy. Categoriile sensibile de aplicații (bancare, 2FA/authenticator, sănătate, aplicații guvernamentale) sunt filtrate înainte ca motorul de reguli să le vadă notificările. Conținuturile lor nu ajung niciodată în baza de date.

Ce este salvat#

Când o notificare este capturată pentru evaluare, în baza de date SQLite locală ajunge următorul:

• Numele pachetului aplicației sursă (de exemplu com.whatsapp).
• Un timestamp.
• Categoria atribuită (Social, Games, News, Shopping, Streaming etc.).
• Decizia regulii: Allow, Snooze sau Block.
• La Block: titlul și textul corpului notificării (ca să poată utilizatorul să verifice ce a fost suprimat).

Pentru notificările blocate, titlul și corpul sunt în plus supuse curățării TTL — implicit 24 de ore după capturare. „Șterge tot" golește totul instantaneu.

Ce nu este niciodată salvat#

Pentru notificări de la aplicații din categoriile sensibile:

• Pachetul este recunoscut la granița serviciului de listener.
• Notificarea este trecută imediat mai departe, fără evaluare și fără salvare.
• Niciun titlu, niciun corp, niciun metadate al acestei notificări nu ajunge vreodată în baza de date.

Lista de categorii sensibile este cablată în motorul de reguli. Cuprinde (neexhaustiv):

• Aplicații bancare (BCR, BRD, Banca Transilvania, Raiffeisen, ING…)
• Aplicații 2FA/authenticator (Google Authenticator, Authy…)
• Aplicații de asigurări de sănătate (CASS, RCA online…)
• Aplicații guvernamentale (mObywatel/echivalente RO, e-Guvernare, ANAF…)

Lista poate fi extinsă la build prin configurare — pentru deployments care trebuie să adauge categorii sensibile suplimentare (de exemplu aplicații interne ale firmei care nu trebuie filtrate niciodată).

Constrângeri de compliance Google Play#

Arhitectura este structurată în jurul a șase constrângeri dure de compliance din politicile actuale Google Play:

Acestea nu sunt declarații de intenție — sunt structurale. Eliminarea oricăreia ar cere o modificare de arhitectură, nu doar un flip de configurare.

Permisiile din manifest#

Patru permisii declarate, fiecare legată de o funcție concretă:

• BIND_NOTIFICATION_LISTENER_SERVICE — funcția centrală. Fără ea, aplicația nu poate citi sau filtra notificări. Activată de utilizator prin setările sistemului.
• RECEIVE_BOOT_COMPLETED — Reconectează listenerul după restart de dispozitiv.
• WAKE_LOCK — Declanșează timerele de snooze fiabil din modul Doze (planificat pentru faza 2).
• POST_NOTIFICATIONS — Afișează propriile re-notificări (released sau snoozed) fără fereastră overlay (vezi C2).

Fără permisii runtime, fără restricted special-access dincolo de listener-ul de notificări.

Cum să verifici#

Dacă evaluezi rolarea acestuia în organizația ta:

1. Inspecția manifestului APK.

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

   Confirmă că android.permission.INTERNET nu apare.

2. Observă comportamentul de rețea.

   Lasă aplicația să ruleze pe un dispozitiv de test cu capturare completă de trafic (PCAP, un proxy transparent). Confirmă că nu apar conexiuni de ieșire.

3. Inspecția bazei de date.

   Fișierul SQLite stă în storage-ul privat al aplicației. Pe un dispozitiv de test rooted, copiază-l afară și confirmă că nu apar notificări de la aplicații din categoriile sensibile.

Dacă vreunul dintre aceste check-uri dă un rezultat la care nu te aștepți, te rog trimite detalii prin pagina Contact. Întregul produs depinde de faptul că aceste garanții sunt verificabile.