# Modèle de confidentialitéCe qui est stocké, ce qui ne l'est pas, et les catégories sensibles que le moteur ne voit jamais.

## Résumé architectural

Le modèle de confidentialité de Notification Guard repose sur
trois propriétés structurelles :

1. **Données locales uniquement.** Tout est stocké dans la base
   SQLite privée de l'app. Pas de synchronisation cloud, pas
   d'état côté serveur, pas de compte.
2. **Aucune permission réseau au manifest.**
   `android.permission.INTERNET` n'est **pas déclarée** dans
   l'AndroidManifest. L'app ne peut pas faire d'appel réseau —
   point. C'est vérifiable via `aapt dump badging`.
3. **Pré-filtre de confidentialité.** Les catégories d'app
   sensibles (banque, 2FA/authenticator, santé, services
   publics) sont triées **avant** que le moteur de règles ne voie
   leurs notifications. Leur contenu n'entre jamais en base.

## Ce qui est stocké

Quand une notification est capturée pour évaluation, ce qui suit
est écrit dans la base SQLite locale :

- Le nom de package de l'app d'origine (par ex. `com.whatsapp`).
- Un timestamp.
- La catégorie assignée (Social, Jeux, Actualités, Shopping,
  Streaming, etc.).
- La décision de la règle : autoriser, snooze ou bloquer.
- Si bloquée : le titre et le corps du texte de la notification
  (pour que l'utilisateur puisse revoir ce qui a été supprimé).

Pour les notifications **bloquées**, le titre et le corps sont
aussi soumis au **nettoyage TTL** — par défaut, 24h après
capture. "Tout effacer" purge tout immédiatement.

## Ce qui n'est jamais stocké

Pour les notifications de toute app des **catégories sensibles** :

- Le package est reconnu à la frontière du service listener.
- La notification est **passée immédiatement**, sans évaluation
  ni stockage.
- Aucun titre, aucun corps, aucune métadonnée à propos de cette
  notification n'atteint jamais la base.

La liste des catégories sensibles est codée en dur dans le moteur
de règles. Elle inclut (non exhaustif) :

- Apps bancaires (DKB, PayPal, caisses d'épargne, …)
- Apps 2FA / authenticator (Google Authenticator, Authy, …)
- Apps d'assurance santé (TK, AOK, Barmer, …)
- Apps services publics (services fédéraux, Elster, …)

Cette liste peut être étendue via configuration au build — pour
les déploiements ayant besoin d'ajouter des catégories sensibles
additionnelles (par ex. des apps corporate internes qui ne
doivent jamais être filtrées).

## Contraintes de conformité Google Play

L'architecture est structurée autour de six contraintes de
conformité strictes issues des politiques Google Play actuelles :

| ID | Contrainte | Comment l'app la satisfait |
|---|---|---|
| C1 | Divulgation et consentement explicites | Assistant d'onboarding en 4 étapes avant l'activation de la permission listener. |
| C2 | Pas de `SYSTEM_ALERT_WINDOW` | Re-notifications via `NotificationManager`, pas de fenêtre overlay. |
| C3 | TTL de rétention des données | Rétention configurable (24h par défaut), tâche de nettoyage périodique, purge manuelle. |
| C4 | Sélecteur de contacts au lieu de `READ_CONTACTS` | La permission `READ_CONTACTS` complète n'est **pas** utilisée. Les futures règles conscientes des contacts utiliseront le Contact Picker Android. |
| C5 | Filtre de confidentialité (blocklist de catégories sensibles) | Pré-filtre codé en dur à l'entrée du moteur. |
| C6 | Pas de couche réseau | `android.permission.INTERNET` absente du manifest. Aucune dépendance client HTTP dans aucun `Cargo.toml`. |

Ce ne sont pas des intentions — c'est structurel. Supprimer l'une
d'entre elles nécessiterait un changement architectural, pas un
simple flip de config.

## Permissions du manifest

Quatre permissions déclarées, chacune liée à une fonctionnalité
concrète :

- **`BIND_NOTIFICATION_LISTENER_SERVICE`** — Fonction principale.
  Sans elle, l'app ne peut ni lire ni filtrer les notifications.
  Activée par l'utilisateur via les paramètres système.
- **`RECEIVE_BOOT_COMPLETED`** — Reconnecte le listener après un
  reboot.
- **`WAKE_LOCK`** — Déclenche les minuteurs de snooze de manière
  fiable depuis le mode Doze (prévu en phase 2).
- **`POST_NOTIFICATIONS`** — Affiche nos propres re-notifications
  (libérées ou snoozées) sans fenêtre overlay (voir C2).

Aucune permission d'exécution, aucun accès spécial restreint
au-delà du listener de notifications.

## Comment vérifier

Si vous évaluez le déploiement dans votre organisation :

1. **Inspecter le manifest de l'APK.**

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

   Confirmer que `android.permission.INTERNET` n'apparaît pas.

2. **Inspecter le comportement réseau.**

   Lancer l'app sur un appareil de test avec capture de trafic
   complète (PCAP, un proxy transparent). Confirmer l'absence de
   connexions sortantes.

3. **Inspecter la base de données.**

   Le fichier SQLite vit dans le stockage privé de l'app. Sur un
   appareil de test rooté, le copier dehors et confirmer
   qu'aucune notification d'app de catégorie sensible n'y
   apparaît.

Si l'un de ces contrôles retourne un résultat inattendu, envoyez
les détails via la page [Contact](/fr/contact/). Tout le produit
dépend du fait que ces garanties soient vérifiables.