Modèle de confidentialité

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 :

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.

   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. Tout le produit dépend du fait que ces garanties soient vérifiables.