# Modelo de privacidadQué se almacena, qué no, y las categorías sensibles que el motor nunca ve.

## 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:

| ID | Restricción | Cómo la cumple la app |
|---|---|---|
| C1 | Divulgación y consentimiento explícitos | Asistente de onboarding en 4 pasos antes de activar el permiso listener. |
| C2 | Sin `SYSTEM_ALERT_WINDOW` | Re-notificaciones vía `NotificationManager`, sin ventana overlay. |
| C3 | TTL de retención de datos | Retención configurable (24h por defecto), tarea periódica de limpieza, purga manual. |
| C4 | Selector de contactos en lugar de `READ_CONTACTS` | El permiso `READ_CONTACTS` completo **no** se utiliza. Las futuras reglas con contactos usarán el Contact Picker de Android. |
| C5 | Filtro de privacidad (blocklist de categorías sensibles) | Pre-filtro codificado en duro a la entrada del motor. |
| C6 | Sin capa de red | `android.permission.INTERNET` fuera del manifest. Sin dependencias de cliente HTTP en ningún `Cargo.toml`. |

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.**

   ```sh
   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](/es/contact/). Todo el producto depende de que estas
garantías sean verificables.