Ciclo de vida y privacidad de Web Push

Web Push no es un permiso permanente ni un identificador duradero. El navegador puede conceder permiso, crear una suscripción con un endpoint y claves, rotarla y eliminarla después. BotBrowser puede conservar un estado de permiso declarado en un perfil controlado y autorizado para revisar el flujo de una aplicación. No concede permisos, entrega mensajes, decide si alguien desea avisos ni elimina un endpoint del servicio de push.

La especificación Push API, la referencia Push API de MDN y la especificación Service Workers describen los objetos y eventos del navegador. La documentación de permisos de BotBrowser cubre el estado de permiso como entrada de perfil. Este artículo añade lo que esa página no cubre: ciclo de vida, detección de endpoints obsoletos, limpieza después de unsubscribe() y retención limitada de endpoints y claves.

TL;DR

• Trata Notification.permission, PushSubscription y el registro del servidor como estados relacionados pero distintos.
• Crea una suscripción solo después de una acción visible y una explicación clara del futuro aviso.
• Guarda endpoint y claves públicas para el propósito declarado, con propietario, caducidad y eliminación.
• Reconcilia pushsubscriptionchange, fallos de entrega, cierre de sesión, cierre de cuenta y unsubscribe().
• Un endpoint es una capacidad de enrutamiento y un valor enlazable; no es una clave de identidad.

Contenido

• Separar permiso, suscripción y entrega
• Crear una suscripción con intención explícita
• Modelar la rotación del endpoint y los eventos del service worker
• Limpiar la baja y los cambios de cuenta
• Minimizar privacidad y retención del endpoint
• Usar un registro de ciclo de vida basado en evidencia
• Conclusión práctica

Separar permiso, suscripción y entrega

El navegador expone un estado de permiso mediante Notifications API, mientras Push API crea una PushSubscription para el registro de un service worker. No son equivalentes. Notification.permission === "granted" solo indica que el contexto actual puede usar notificaciones; no demuestra que exista una suscripción, que la persona haya iniciado sesión ni que un proveedor entregue mensajes. Puede no existir suscripción aunque el permiso siga concedido. La guía de Permissions Policy separa la elegibilidad de una política del permiso registrado aquí.

Mantén tres máquinas de estados. El permiso puede ser default, denied o granted. La suscripción puede ser none, active, rotating, unsubscribed o expired. La entrega puede ser unknown, accepted, rejected o stale según la respuesta del proveedor. Una sola columna push_enabled mezcla responsables y hace difícil auditar la limpieza.

registration.pushManager.getSubscription() devuelve una suscripción o null. null es una observación de ese registro, origen y alcance; no prueba que la persona nunca se suscribiera en otro contexto. Lee el permiso y la suscripción juntos, y explica la siguiente acción sin inferir identidad. Un registro mínimo puede contener un ID interno aleatorio, origen, alcance del service worker, referencia irrecuperable para deduplicación, claves necesarias por el protocolo, tiempos, estado y motivo de eliminación. No pongas el endpoint completo en analítica ni en una URL.

Durante soporte, permiso concedido sin service worker listo, endpoint rechazado por el proveedor y fila que quedó activa tras una baja son casos distintos. El propietario puede ser el navegador, la página, el worker, el proveedor o la base de datos. El artículo de permisos y fingerprinting del navegador explica por qué un permiso no identifica a una persona; aquí el riesgo adicional es la retención de un endpoint enlazable.

Crear una suscripción con intención explícita

Explica categoría, frecuencia y forma de desactivar antes de llamar a subscribe(). No lo hagas al cargar la página ni como efecto oculto de otra función. Registra primero el service worker, espera navigator.serviceWorker.ready, verifica el alcance y consulta getSubscription(). Si no hay suscripción, muestra una decisión visible solo cuando corresponda.

El control de activación debe tener un camino de apagado igualmente claro. “Activar avisos de pedidos” es mejor que “Permitir notificaciones”. En ajustes, muestra el estado de la aplicación y enlaza con los controles del navegador cuando el permiso está denegado. La aplicación no puede revertir una denegación del navegador.

applicationServerKey vincula la suscripción con la clave pública del servicio. Versiona la clave solo durante una migración deliberada y conserva la versión en la fila, nunca el material privado. Envía endpoint, claves públicas requeridas, origen y un ID corto de solicitud mediante un intercambio autenticado e idempotente. Un endpoint no demuestra que el llamante sea dueño de una cuenta.

Distingue denegación, worker no disponible, contexto no permitido, fallo del proveedor y error de respuesta. Conserva la tarea del usuario y ofrece actualizaciones dentro de la aplicación. No reabras un prompt denegado ni envíes endpoints o excepciones sin redactar a telemetría general.

Modelar la rotación del endpoint y los eventos del service worker

El endpoint puede cambiar. El evento pushsubscriptionchange en el ámbito global del service worker es una señal para reconciliar, no una garantía de que todos los navegadores lo emitan. El worker puede obtener la suscripción actual, enviar un cambio autenticado y marcar la fila anterior para revisión. Si no aparece reemplazo, conserva un estado unknown rotation y permite que la próxima visita cierre la diferencia.

Una rotación no significa una persona nueva. Puede deberse a mantenimiento del navegador, política del proveedor, cambio de clave, reinicio del perfil o actualización del worker. Vincula la nueva fila a un ID de aplicación con una referencia de migración corta, comprueba de nuevo cuenta y propósito, y retira el endpoint anterior cuando el reemplazo sea aceptado.

Una respuesta del proveedor que indique endpoint inexistente justifica stale y detener envíos. Un fallo transitorio merece reintento acotado, no borrado inmediato. Un envío aceptado tampoco prueba que alguien lo vio o lo desea. Mantén la confirmación de entrega separada de la interacción.

Una actualización del service worker puede cambiar push y notificationclick. Coordina el esquema con la activación del nuevo worker y conserva una ruta compatible cuando la fila antigua no contiene un campo nuevo. El artículo sobre actualizaciones de service workers cubre la coordinación de versiones; el ciclo de vida de caché del service worker muestra por qué la activación y la limpieza necesitan responsables explícitos.

Limpiar la baja y los cambios de cuenta

PushSubscription.unsubscribe() elimina la suscripción local y devuelve un booleano. true no borra una fila del servidor, colas del proveedor ni registros externos. Envía una solicitud autenticada de desactivación y acepta que un cliente sin red la complete después.

El endpoint de limpieza debe ser idempotente: verificar el propietario, marcar la fila inactiva y retirar endpoint y claves del almacenamiento de entrega. Un tombstone mínimo puede conservar ID aleatorio, fecha y motivo durante el periodo necesario para evitar reactivación accidental, pero no el endpoint completo.

Cerrar sesión y cerrar una cuenta no son iguales. El primero puede detener envíos para la sesión actual; el segundo revoca las filas de la cuenta conforme a su política y elimina las copias de la aplicación. Cerrar una pestaña o detener un worker no demuestra ninguno de esos actos.

Si la operación local termina pero la red falla, guarda solo una marca de reconciliación que expire. Si el servidor desactiva la fila pero el navegador no termina, informa que queda limpieza local pendiente. No afirmes “borrado en todas partes” sin evidencia de cada sistema bajo tu control.

Minimizar privacidad y retención del endpoint

Un endpoint opaco sigue siendo un valor de enrutamiento enlazable. Trátalo y trata las claves públicas como datos personales o identificadores seudónimos sensibles. Guárdalo en un almacén de entrega con acceso limitado; la analítica necesita solo evento, propósito e ID interno no reversible. Redacta valores en soporte, copias y exportaciones.

El plazo de retención debe derivar del propósito. Un registro activo vive mientras exista consentimiento y necesidad de entrega. Uno obsoleto, no confirmado o dado de baja debe caducar pronto. Elimina o redacta endpoint y claves cuando termina el propósito, se cierra la cuenta o vence el plazo, conservando únicamente el motivo.

El contenido de la notificación también debe minimizarse. Un aviso puede aparecer en una pantalla compartida y el proveedor puede procesar metadatos. Prefiere una referencia opaca que abra una página autorizada. No unas “subscribed”, “rotated”, “clicked” y “unsubscribed” con señales de navegador para construir un perfil persistente. Define los campos retentionUntil y accountClosed para que el plazo y su disparador puedan verificarse.

Usar un registro de ciclo de vida basado en evidencia

Registra propósito, origen, alcance, permiso, estado, versión de clave, ID redactado, acción, momento y fecha de retención. Un formato compacto y seguro para documentación es:

{
  "purpose": "order-status",
  "origin": "https://shop.example",
  "serviceWorkerScope": "/app/",
  "permission": "granted",
  "subscriptionState": "active",
  "keyVersion": "v2",
  "recordId": "psr_7f2c",
  "lastReconciledAt": "2026-10-25T14:00:00Z",
  "retentionUntil": "2026-11-24T14:00:00Z",
  "nextAction": "send"
}

Es una forma de fixture, no una suscripción real. Si permiso es granted y suscripción none, ofrece opt-in explícito; si está active pero stale, detén envíos y reconcilia; si está unsubscribed, elimina datos activos y no vuelvas a suscribir en silencio; si venció la retención, borra la fila y pide una nueva decisión.

Observación	Significado	Propietario	Próxima acción
permission=granted, subscription=null	El navegador permite avisos, pero no hay suscripción local	Página y usuario	Explicar y ofrecer opt-in
subscription=active, proveedor dice gone	La ruta ya no sirve	Servicio de entrega	Marcar stale y reconciliar
unsubscribe() devuelve true, fila activa	La limpieza local terminó; la de servidor espera	API de aplicación	Reintentar desactivación idempotente
permission=denied, fila activa	El navegador contradice la intención de entrega	Usuario y aplicación	Detener envíos y explicar ajustes
Venció el plazo	Terminó el propósito o se abandonó la fila	Responsable de datos	Eliminar endpoint y claves

BotBrowser puede reproducir una entrada de permiso declarada y abrir una página propia donde la aplicación registre transiciones. No puede invocar un prompt nativo, elegir una decisión, inspeccionar la cola privada del proveedor, garantizar pushsubscriptionchange ni certificar borrado externo. Úsalo para observaciones de compatibilidad acotadas.

Preguntas frecuentes

¿Permiso concedido significa suscripción activa?

No. Todavía hay que crear la suscripción, registrarla en el servidor y comprobar la fila propia.

¿El endpoint es una huella del dispositivo?

No prueba un dispositivo ni una persona, pero enlaza eventos. Limita acceso, retención y combinaciones con otras señales.

¿Qué ocurre después de unsubscribe()?

Separa resultado local y limpieza de servidor, usa un endpoint idempotente y elimina material activo. No prometas borrar colas del proveedor sin evidencia.

¿La rotación crea otra cuenta?

No necesariamente. Crea o actualiza una fila de entrega vinculada temporalmente, verifica propósito y retira el valor anterior.

¿Puede BotBrowser activar Web Push?

Puede conservar un permiso declarado para una revisión autorizada, pero no concede permiso, crea una suscripción ni garantiza entrega.

Fuentes

• Push API, W3C
• Push API, MDN
• Service Workers, W3C
• Documentación de permisos de BotBrowser

Conclusión práctica

Modela Web Push como un ciclo de vida: el permiso habilita una capacidad, el registro del service worker posee la suscripción, el servidor autoriza la entrega y la limpieza termina el propósito. Reconcilia rotación, fallos, cambios de permiso, cierre de sesión, cierre de cuenta y unsubscribe(). Mantén endpoints y claves fuera de analítica e identidad. BotBrowser puede repetir una entrada de permiso autorizada, pero la intención del usuario, la entrega y la eliminación pertenecen a la aplicación y al proveedor.