Modelo de privacidad

Resumen arquitectónico#

El modelo de privacidad de Notification Guard descansa sobre tres propiedades estructurales:

1. Datos solo locales. Todo se almacena en la base SQLite privada de la app. Sin sincronización cloud, sin estado en servidor, sin cuenta.
2. Sin permiso de red en el manifest. android.permission.INTERNET no está declarada en el AndroidManifest. La app no puede hacer llamadas de red — punto. Esto es verificable vía aapt dump badging.
3. Pre-filtro de privacidad. Las categorías de apps sensibles (banca, 2FA/authenticator, sanidad, apps de administraciones públicas) se filtran antes de que el motor de reglas vea sus notificaciones. Su contenido nunca entra en la base de datos.

Qué se almacena#

Cuando una notificación se captura para evaluación, lo siguiente se escribe en la base SQLite local:

• El nombre de paquete de la app de origen (p. ej. com.whatsapp).
• Un timestamp.
• La categoría asignada (Social, Juegos, Noticias, Compras, Streaming, etc.).
• La decisión de regla: permitir, snooze o bloquear.
• Si está bloqueada: el título y el cuerpo del texto de la notificación (para que el usuario pueda revisar lo suprimido).

Para notificaciones bloqueadas, el título y el cuerpo también están sujetos al limpiado por TTL — por defecto, 24 horas tras la captura. “Borrar todo” purga todo al instante.

Qué nunca se almacena#

Para notificaciones de cualquier app de las categorías sensibles:

• El paquete se reconoce en la frontera del servicio listener.
• La notificación se pasa inmediatamente, sin evaluación ni almacenamiento.
• Ni título, ni cuerpo, ni metadatos sobre esa notificación llegan jamás a la base de datos.

La lista de categorías sensibles está codificada en duro en el motor de reglas. Incluye (no exhaustivo):

• Apps de banca (DKB, PayPal, cajas de ahorros, …)
• Apps 2FA / authenticator (Google Authenticator, Authy, …)
• Apps de seguros sanitarios (TK, AOK, Barmer, …)
• Apps de administraciones públicas (servicios federales, Elster, …)

Esta lista puede extenderse vía configuración en build-time — para despliegues que necesiten añadir categorías sensibles adicionales (p. ej. apps corporativas internas que nunca deban filtrarse).

Restricciones de cumplimiento Google Play#

La arquitectura está estructurada alrededor de seis restricciones de cumplimiento duras derivadas de las políticas actuales de Google Play:

No son aspiracionales — son estructurales. Eliminar cualquiera de ellas requeriría un cambio de arquitectura, no solo un flip de configuración.

Permisos del manifest#

Cuatro permisos declarados, cada uno atado a una función concreta:

• BIND_NOTIFICATION_LISTENER_SERVICE — Función esencial. Sin él, la app no puede leer ni filtrar notificaciones. Activado por el usuario en los ajustes del sistema.
• RECEIVE_BOOT_COMPLETED — Reconecta el listener tras reinicio del dispositivo.
• WAKE_LOCK — Dispara temporizadores de snooze de forma fiable desde modo Doze (planificado para fase 2).
• POST_NOTIFICATIONS — Muestra nuestras propias re-notificaciones (liberadas o en snooze) sin ventana overlay (ver C2).

Sin permisos de runtime, sin accesos especiales restringidos más allá del listener de notificaciones.

Cómo verificar#

Si estás evaluando desplegarla en tu organización:

1. Inspeccionar el manifest del APK.

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

   Confirmar que android.permission.INTERNET no aparece.

2. Inspeccionar el comportamiento de red.

   Ejecutar la app en un dispositivo de prueba con captura completa de tráfico (PCAP, un proxy transparente). Confirmar que no hay conexiones salientes.

3. Inspeccionar la base de datos.

   El fichero SQLite vive en almacenamiento privado de la app. En un dispositivo de prueba rooteado, copiarlo fuera y confirmar que no aparecen notificaciones de apps de categorías sensibles.

Si alguna de estas comprobaciones da un resultado inesperado, por favor envíanos los detalles vía la página Contacto. Todo el producto depende de que estas garantías sean verificables.