Cycle de vie et confidentialité de Web Push

Web Push n'est ni une autorisation permanente ni un identifiant durable. Le navigateur peut accorder le consentement, créer un abonnement avec un endpoint et des clés, le faire tourner, puis le supprimer. BotBrowser peut conserver un état de permission déclaré dans un profil contrôlé et autorisé afin d'observer le flux d'une application. Il n'accorde pas la permission, n'envoie pas de message, ne choisit pas pour l'utilisateur et ne supprime pas un endpoint auprès d'un service push. Le guide Permissions Policy sépare l'éligibilité de la politique de l'état de permission suivi ici.

La spécification Push API, la référence Push API de MDN et la spécification Service Workers décrivent les objets et événements du navigateur. La documentation des permissions BotBrowser décrit la permission comme une entrée de profil. Cet article ajoute ce que cette page ne traite pas : le cycle de vie, les endpoints périmés, le nettoyage après unsubscribe() et une conservation limitée des endpoints et des clés.

TL;DR

• Séparez Notification.permission, PushSubscription et l'enregistrement serveur.
• Ne créez un abonnement qu'après une action visible et une explication de la future notification.
• Conservez endpoint et clés publiques pour un but déclaré, avec responsable, expiration et suppression.
• Réconciliez pushsubscriptionchange, les erreurs d'envoi, la déconnexion, la fermeture de compte et unsubscribe().
• Un endpoint est une capacité de routage corrélable, pas une clé d'identité.

Sommaire

• Séparer permission, abonnement et livraison
• Créer un abonnement avec une intention explicite
• Modéliser la rotation de l'endpoint et les événements du service worker
• Nettoyer la désinscription et les changements de compte
• Réduire la confidentialité et la rétention de l'endpoint
• Utiliser un enregistrement de cycle fondé sur des preuves
• Conclusion pratique

Séparer permission, abonnement et livraison

Notifications API expose un état de permission, tandis que Push API crée une PushSubscription pour l'enregistrement d'un service worker. Ces états ne sont pas interchangeables. Notification.permission === "granted" signifie seulement que le contexte actuel peut utiliser les notifications ; cela ne prouve ni l'existence d'un abonnement, ni une session ouverte, ni la livraison par un fournisseur. Un abonnement peut manquer alors que la permission reste accordée.

Conservez trois machines d'état. La permission vaut default, denied ou granted. L'abonnement vaut none, active, rotating, unsubscribed ou expired. La livraison vaut unknown, accepted, rejected ou stale selon la réponse du service push. Une colonne unique push_enabled mélange les responsabilités et empêche de vérifier le nettoyage.

registration.pushManager.getSubscription() renvoie un abonnement ou null. null est une observation de ce registre, de cette origine et de ce scope ; ce n'est pas la preuve que l'utilisateur ne s'est jamais abonné dans un autre contexte. Lisez permission et abonnement ensemble, puis expliquez l'action suivante sans déduire une identité. Un enregistrement minimal peut contenir un identifiant interne aléatoire, l'origine, le scope du service worker, une référence irréversible de déduplication, les clés nécessaires au protocole, les dates, l'état et la raison de suppression. Ne placez pas l'endpoint complet dans l'analytique ou une URL.

Pour le support, permission accordée sans worker prêt, endpoint refusé par le fournisseur et ligne serveur restée active après une désinscription sont des cas différents. Le responsable peut être le navigateur, la page, le worker, le fournisseur ou la base de données. L'article Permissions du navigateur et fingerprinting rappelle qu'une permission n'identifie pas une personne ; le cycle d'abonnement ajoute le risque concret de corrélation de l'endpoint.

Créer un abonnement avec une intention explicite

Expliquez la catégorie, la fréquence et le moyen de désactivation avant subscribe(). Ne le faites pas au chargement ou derrière un minuteur. Enregistrez le service worker, attendez navigator.serviceWorker.ready, vérifiez son scope, puis appelez getSubscription(). S'il n'y a rien, affichez une décision explicite.

Le bouton d'activation doit avoir un chemin d'arrêt aussi clair. « Activer les avis de commande » est plus précis que « Autoriser les notifications ». Les réglages doivent montrer l'état de l'application et renvoyer vers les réglages du navigateur quand la permission est refusée. L'application ne peut pas annuler un refus du navigateur.

applicationServerKey associe l'abonnement à la clé publique du service. Versionnez cette clé pour une migration voulue et conservez uniquement la version dans la ligne. Envoyez endpoint, clés publiques, origine et identifiant court dans une requête authentifiée et idempotente. Un endpoint ne prouve pas que l'appelant possède le compte.

Distinguez refus, worker indisponible, contexte non autorisé, erreur du fournisseur et erreur de réponse. Conservez la tâche en cours et proposez des mises à jour dans l'application. Ne relancez pas une invite refusée et n'envoyez pas d'endpoint ou d'exception non masqué dans une télémétrie générale.

Modéliser la rotation de l'endpoint et les événements du service worker

L'endpoint peut changer. L'événement pushsubscriptionchange dans le scope global du service worker demande une réconciliation ; il ne garantit pas une émission dans chaque navigateur. Le worker peut obtenir l'abonnement courant, envoyer une mise à jour authentifiée et marquer l'ancienne ligne pour examen. Sans remplacement, gardez l'état unknown rotation jusqu'à une prochaine visite.

Une rotation ne signifie pas un nouvel utilisateur. Elle peut venir de la maintenance du navigateur, d'une politique fournisseur, d'une nouvelle clé, d'une réinitialisation du profil ou d'un remplacement du worker. Reliez la nouvelle ligne à l'ancien identifiant applicatif par une référence de migration courte, vérifiez le compte et le but, puis retirez l'ancien endpoint quand le nouveau est accepté.

Une réponse indiquant que l'endpoint n'existe plus justifie l'état stale et l'arrêt des envois. Une erreur transitoire appelle un nombre limité de tentatives, pas une suppression immédiate. Un envoi accepté ne prouve pas que quelqu'un l'a lu. Séparez l'acceptation de livraison de l'engagement utilisateur.

Une mise à jour du service worker peut changer push et notificationclick. Coordonnez le schéma avec l'activation du nouveau worker et gardez une compatibilité si une ancienne ligne manque un champ. L'article Mises à jour des service workers traite de la cohérence des clients ; le cycle de vie du cache des service workers montre pourquoi l'activation et le nettoyage ont besoin de responsables explicites.

Nettoyer la désinscription et les changements de compte

PushSubscription.unsubscribe() supprime l'abonnement local et renvoie un booléen. true ne supprime ni ligne serveur, ni file fournisseur, ni journal externe. Envoyez une demande authentifiée de désactivation et acceptez qu'elle soit retardée hors ligne.

Un endpoint de nettoyage doit être idempotent : vérifier le propriétaire, marquer la ligne inactive et retirer endpoint et clés du stockage de livraison. Un tombstone minimal peut garder identifiant aléatoire, date et motif pendant la période anti-réactivation, mais jamais l'endpoint complet.

La déconnexion et la fermeture d'un compte ne sont pas identiques. La première peut arrêter les avis pour la session courante ; la seconde révoque les lignes du compte selon la politique et supprime les copies applicatives. Fermer un onglet ou arrêter un worker ne prouve aucun de ces actes.

Si la suppression locale réussit mais que le réseau tombe, gardez seulement une marque de réconciliation expirante. Si le serveur désactive la ligne mais que le navigateur échoue, indiquez que le nettoyage local reste à faire. Ne dites pas « supprimé partout » sans preuve pour chaque système contrôlé.

Réduire la confidentialité et la rétention de l'endpoint

Un endpoint opaque reste une valeur de routage corrélable. Traitez-le et les clés publiques comme données personnelles ou identifiants pseudonymes sensibles. Gardez-les dans un magasin de livraison à accès limité ; l'analytique n'a besoin que de l'événement, du but et d'un identifiant interne non réversible. Masquez les valeurs dans le support, les sauvegardes et les exports.

La durée de conservation découle du but. Une ligne active vit tant que l'utilisateur a choisi les notifications et que la livraison est nécessaire. Une ligne obsolète, non confirmée ou désinscrite expire rapidement. Supprimez ou rendez irréversibles endpoint et clés à la fin du but, à la fermeture du compte ou à l'échéance ; gardez seulement le motif.

Réduisez aussi le contenu de la notification. Un avis peut apparaître sur un écran partagé et le service push peut traiter ses métadonnées. Préférez une référence opaque ouvrant une page protégée. Ne joignez pas les événements « subscribed », « rotated », « clicked » et « unsubscribed » à d'autres signaux de navigateur pour construire un profil persistant. Nommez les champs retentionUntil et accountClosed afin de vérifier le délai et son déclencheur.

Utiliser un enregistrement de cycle fondé sur des preuves

Enregistrez but, origine, scope, permission, état, version de clé, identifiant masqué, action, date et limite de rétention. Un format sûr pour la documentation est :

{
  "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"
}

Cette forme est un fixture, pas un abonnement réel. Si permission vaut granted et l'abonnement none, offrez l'opt-in ; s'il est active mais stale, arrêtez l'envoi et réconciliez ; s'il est unsubscribed, supprimez les données actives sans réabonner silencieusement ; si la limite est dépassée, supprimez la ligne et demandez une nouvelle décision.

Observation	Signification	Responsable	Action sûre
permission=granted, subscription=null	Le navigateur autorise les notifications, mais aucun abonnement local n'existe	Page et utilisateur	Expliquer et offrir l'opt-in
subscription=active, fournisseur dit gone	La route ne fonctionne plus	Service de livraison	Marquer stale et réconcilier
unsubscribe() renvoie true, ligne active	Nettoyage local terminé, serveur en attente	API applicative	Réessayer la désactivation idempotente
permission=denied, ligne active	Le navigateur contredit l'intention de livraison	Utilisateur et application	Arrêter et expliquer les réglages
Limite dépassée	But terminé ou ligne abandonnée	Responsable des données	Supprimer endpoint et clés

BotBrowser peut reproduire une permission déclarée et ouvrir une page contrôlée où l'application observe ses transitions. Il ne peut pas ouvrir une invite native, choisir, inspecter la file privée du fournisseur, garantir pushsubscriptionchange ou certifier un effacement externe. Utilisez-le pour des observations de compatibilité limitées.

FAQ

Une permission accordée signifie-t-elle un abonnement actif ?

Non. Il faut encore créer l'abonnement, l'enregistrer côté serveur et vérifier sa ligne.

Un endpoint est-il une empreinte d'appareil ?

Il ne prouve ni appareil ni personne, mais il corrèle des événements. Limitez accès, rétention et jointures avec d'autres signaux.

Que faire après unsubscribe() ?

Séparez le résultat local du nettoyage serveur, utilisez une désactivation idempotente et retirez les données actives. Ne promettez pas l'effacement des files du fournisseur sans preuve.

Une rotation crée-t-elle un nouveau compte ?

Non nécessairement. Créez ou mettez à jour une ligne de livraison liée temporairement, revérifiez le but et retirez l'ancien endpoint.

BotBrowser peut-il activer Web Push ?

Il peut conserver une permission déclarée pour une revue autorisée, mais n'accorde pas la permission, ne crée pas l'abonnement et ne garantit pas la livraison.

Sources

• Push API, W3C
• Push API, MDN
• Service Workers, W3C
• Documentation des permissions BotBrowser

Conclusion pratique

Modélisez Web Push comme un cycle : la permission active une capacité, le registre du service worker possède l'abonnement, le serveur autorise la livraison et le nettoyage termine le but. Réconciliez rotation, erreurs, changements de permission, déconnexion, fermeture de compte et unsubscribe(). Gardez endpoints et clés hors de l'analytique et de l'identité. BotBrowser peut répéter une entrée autorisée, mais l'intention, la livraison et la suppression relèvent de l'application et du fournisseur.