Partitionnement du stockage du navigateur et confidentialité

Dans les navigateurs qui partitionnent l’état intégré, le site de premier niveau peut faire partie de la frontière : une même origine intégrée peut rencontrer des états gérés par le navigateur distincts sous différents sites de premier niveau. Cela peut réduire certains partages d’état entre sites, mais les API, les détails de partitionnement et les exceptions varient selon le navigateur et sa version. Le produit doit distinguer l’état partagé, l’état séparé et le message présenté dans un contexte neuf.

Il s’agit d’un comportement de confidentialité et de compatibilité, pas d’une isolation totale ni d’un blocage de tout échange de données. Le navigateur peut proposer un mécanisme d’accès au stockage intégré soumis au choix de l’utilisateur, mais sa disponibilité et sa portée dépendent de ses règles. Le stockage géré par le navigateur est distinct des flux de données de l’application et du serveur. Une lecture du stockage intégré ne prouve ni l’identité d’une personne ni celle d’un appareil.

Ce que change la clé de partition

Cookies, stockage créé par script et autres états peuvent être liés à une partition comprenant le site supérieur. MDN State Partitioning décrit le modèle et Privacy Sandbox Storage Partitioning son contexte Chromium. Les règles exactes dépendent de la version.

La même origine peut donc rencontrer des états différents sous A et B. Un choix de consentement, une préférence en cache ou une session créée dans un contexte peut manquer dans l’autre. C’est une conséquence voulue de l’isolation par contexte, pas nécessairement une panne. Le composant doit prévoir un premier usage clair et expliquer quand l’utilisateur doit choisir de nouveau un compte ou une préférence.

La navigation de premier niveau diffère de l’intégration. Un service ouvert comme site principal utilise son contexte propre; dans une autre page il suit les règles intégrées. Testez les deux parcours séparément et ne déduisez pas l’état intégré d’une connexion propre réussie.

Le partitionnement peut aussi toucher les service workers, les caches, IndexedDB et les préférences côté client. Un worker qui attend un cache rempli dans un autre contexte peut devoir récupérer de nouveau ses ressources. Un modèle ou une langue choisi ailleurs peut sembler absent alors que l’utilisateur l’a déjà sélectionné. Définissez ce qui peut être téléchargé de nouveau, quel choix doit être redemandé et comment signaler le nouveau contexte sans perdre la tâche en cours.

Le changement est visible entre onglets, fenêtres et routes. L’utilisateur peut reconnaître le service tout en voyant un consentement neuf. Indiquez s’il faut ouvrir le service ou choisir le compte, au lieu de laisser deviner la cause.

Les équipes qui utilisent des SDK intégrés doivent versionner leurs hypothèses de stockage avec le SDK. Une mise à jour du composant peut modifier les noms de clé, les formats de cache ou le moment où l’accès est demandé. Gardez une voie de migration pour les brouillons et préférences, testez une mise à jour interrompue et conservez la révision de l’application et le fixture pour comparer des mises à jour simultanées du navigateur et du SDK.

Ce que chaque observation établit

• Partitionnement du stockage : Si une valeur synthétique est lisible dans un cadre intégré maîtrisé sous le site A, mais pas sous le site B, le résultat est compatible avec des partitions distinctes ; il n'identifie pas une personne et ne prouve pas que toutes les API sont partitionnées. Comparez l'écriture et la lecture du même cadre et de la même origine dans les deux contextes. Privacy Sandbox décrit cette frontière pour des API comme Local Storage et IndexedDB.
• Autorisation côté serveur : Une réponse autorisée montre que le serveur a accepté cette requête pour le compte de test et la règle appliquée ; elle ne montre ni que le stockage du navigateur n'est pas partitionné ni que d'autres points d'accès sont autorisés. Comparez la réponse à une requête de test autorisée et à une requête non autorisée.
• Exception d'accès au stockage : Une demande réussie à la Storage Access API montre qu'un accès a été accordé à ce document dans ce contexte ; elle ne prouve pas un accès permanent ou universel. Notez le résultat de l'API et une lecture ultérieure dans un cadre de test maîtrisé.
• Flux de données intégré : Une requête observée montre quelles données ont atteint cette destination pendant ce test ; elle ne prouve ni qu'aucune autre donnée n'est envoyée ni ce que le serveur conserve. Examinez la destination et la charge synthétique d'une requête maîtrisée, puis comparez-les au choix indiqué par l'utilisateur.

Concevoir le composant intégré

Partez du parcours utilisateur, pas d’une API de stockage. Décidez si le composant mémorise le consentement, conserve un brouillon, affiche un état de connexion ou seulement du contenu public, puis indiquez le contexte valable pour chaque état. Un enregistrement réduit et propre à un usage est plus facile à expliquer que de supposer que toutes les frames intégrées partagent un compte.

Si un parcours a besoin d’une relation de première partie, offrez un chemin visible vers la page du service afin que l’utilisateur puisse y vérifier son compte, son consentement ou ses réglages. Au retour sur le site intégrateur, préservez la tâche au moyen d’un transfert explicite, de courte durée et autorisé côté serveur, et non d’une dépendance non documentée à un cookie partagé.

Un composant doit considérer une partition vide comme normale. Affichez réglage ou connexion, gardez une entrée non sensible et expliquez l’absence de préférence. Ne copiez pas silencieusement l’état d’un autre site.

Les demandes d’accès doivent prévoir une solution de repli centrée sur l’utilisateur. Si le navigateur propose un mécanisme d’accès intégré, expliquez ce dont le composant a besoin et ce qui sera partagé. Après un refus, les fonctions sans rapport de la page doivent rester utilisables : ne répétez pas la demande, ne bloquez pas la navigation et ne laissez pas entendre qu’il faut accorder l’accès pour lire un contenu public.

Le partitionnement ne remplace pas l’autorisation côté serveur : le service doit toujours y valider les droits du compte et l’intégrité de la requête. Le stockage client est un cache et une commodité, pas une preuve de connexion. Si une session intégrée expire, affichez un état récupérable et demandez l’action appropriée au lieu de traiter un cookie absent comme une preuve concernant le navigateur.

Confidentialité et minimisation

Le partitionnement peut réduire le partage passif d’état entre sites de premier niveau, mais il ne rend pas chaque interaction intégrée privée. Le service intégré reçoit toujours les données de requête nécessaires à sa fonction, et la page de premier niveau peut observer ce qu’elle y place. Examinez le parcours complet des données : paramètres d’URL, messages postMessage, requêtes réseau, journaux serveur, analytique, téléchargements et suppression.

Ne collectez que l’état nécessaire. Une préférence d’affichage peut rester dans la partition sans identifiant de compte; un brouillon a besoin d’une durée et d’une action d’effacement. Le support n’a souvent besoin que du résultat et de la version.

La disponibilité d’une clé ne doit pas devenir un signal d’identité stable. Son absence peut venir d’un nouveau contexte, d’un profil effacé, d’un réglage du navigateur, d’une permission refusée ou d’une modification de l’application. Sa présence peut refléter une relation de première partie partagée sans identifier une personne. Choisissez le parcours selon le résultat fonctionnel et supprimez les données de diagnostic dès que leur utilité pour le support prend fin.

Le contenu tiers peut avoir un propriétaire différent de l’application de premier niveau. Précisez qui contrôle les données de compte, les enregistrements de consentement, l’accès du support et la conservation. Si un composant de paiement, média ou identité a besoin d’une frontière de service, prévenez l’utilisateur avant que les données quittent la page. Le partitionnement local ne dit pas qui peut voir une valeur envoyée au service.

Le guide des cookies traite les sessions et la conservation. Quota de stockage et confidentialité traite les observations de capacité. Gardez ces sujets séparés de la clé de partition : un résultat de quota ne prouve pas le contexte de premier niveau, et le partitionnement ne justifie pas de collecter des mesures de quota.

Tester un état partitionné

Utilisez deux sites supérieurs contrôlés et un service intégré contrôlé. Avec des profils propres, créez une préférence synthétique sous A puis sous B. L’attente doit être une règle visible pour l’utilisateur.

Testez séparément les parcours de première partie et d’intégration. La visite de première partie doit vérifier le parcours normal du compte et des réglages ; la visite intégrée doit vérifier la partition vide, l’accès refusé et le retour au service. Utilisez des données synthétiques, jamais de vrais comptes ou documents sur un point de test.

Couvrez le cycle de vie : nouveau contexte, redémarrage du navigateur, effacement des données du site, changement de consentement, expiration de session et mise à jour de l’application. Vérifiez si le produit conserve la saisie, demande un choix ou recommence volontairement. Une réinitialisation ne doit pas laisser l’interface affirmer qu’une ancienne opération est terminée.

Les frames peuvent communiquer, mais le protocole doit être explicite et limité à la tâche. Vérifiez l’origine et le sens de chaque message des deux côtés ; n’utilisez pas un canal de messages large pour recréer une couche globale de stockage cachée. Si l’utilisateur choisit de continuer sur une page de première partie, transmettez une référence de transfert de courte durée, à la durée documentée et autorisée côté serveur.

Comparez les navigateurs sans transformer un résultat en règle universelle. Notez famille, version, sites, origine intégrée, application et résultat. Un changement peut nécessiter une solution de repli.

Dépanner la compatibilité

Si le composant paraît déconnecté, identifiez le contexte, le profil et le propriétaire. Examinez ensuite session, autorisation, consentement et réseau. Ne commencez pas par copier des cookies.

Distinguez partition vide et panne réseau. Les deux peuvent ressembler à une préférence manquante, mais les actions diffèrent : configuration initiale, nouvel essai ou explication d’une permission révoquée. Des messages d’état clairs réduisent les demandes répétées et les sollicitations du support.

La mise en cache peut rendre un changement incohérent en apparence. Un service worker ou le cache applicatif peut garder une ancienne interface tandis qu’une nouvelle partition récupère les ressources actuelles. Versionnez les actifs, gérez une mise à jour interrompue et gardez un chemin opérationnel pendant le téléchargement du remplacement. Ne supprimez pas l’unique brouillon local utilisable simplement parce que le nouveau contexte n’a pas son cache.

Si la fonction intégrée est facultative, le reste de la page doit rester utilisable sans accès au stockage. Offrez une route de première partie, une alternative locale sans compte ou une explication claire de ce qui ne peut pas continuer. Affichez toute solution distante avant le transfert et précisez la durée de conservation applicable.

Les éléments de support doivent rester limités : tâche concernée, contexte supérieur, catégorie d’origine intégrée, version du navigateur, révision de l’application et résultat visible. Ne demandez les données sous-jacentes de stockage ou de compte que par une procédure autorisée et si le relevé minimal ne suffit pas à expliquer le problème ; supprimez les éléments temporaires à la clôture du dossier.

Revue de version et exploitation

Quand navigateur, SDK, consentement, comptes ou schema changent, rejouez le même flux synthétique. Comparez résultat visible et action attendue, non une supposition sur la clé.

Gardez une matrice des navigateurs et parcours intégrés, avec propriétaire et date. Ne transformez pas chaque valeur créée par le test en historique durable.

Documentez les règles de migration des états autrefois accessibles entre contextes. Avant une mise à jour, l’utilisateur peut devoir choisir de nouveau une préférence, se connecter sur la page du service ou exporter un brouillon. Proposez une action claire et gardez l’ancienne voie assez longtemps pour éviter une perte silencieuse ; ne fusionnez pas les enregistrements de sites de premier niveau sans relation.

La réponse à incident doit préserver le travail. Gardez les données saisies, offrez export ou continuité de première partie et expliquez tout transfert. Ne désactivez pas définitivement l’isolation.

Après une mise à jour du navigateur ou de l’intégration, répétez un parcours avec un brouillon synthétique dans chaque contexte intégré pris en charge. Une nouvelle partition doit afficher la configuration initiale au lieu d’annoncer à tort que l’ancien brouillon a été enregistré; conservez le brouillon original jusqu’à la fin de l’export ou de la poursuite sur la page du service choisie par l’utilisateur. Comparez les révisions de l’application et de ses dépendances avec la précédente exécution réussie avant d’attribuer l’échec au stockage du navigateur.

L’exploitation couvre aussi la suppression. Définissez comment l’utilisateur efface un brouillon intégré, comment le support retire un enregistrement de test temporaire et comment une intégration retirée cesse de recevoir des requêtes. Vérifiez la confirmation visible et gardez l’action disponible même si le service intégré ne peut pas charger son ancienne préférence.

Avant de naviguer vers la première partie, affichez la limite de données : brouillon local, compte ou transfert. Gardez les données saisies jusqu’à confirmation.

L’analytique doit aussi tenir compte des partitions. Deux visites du même service intégré sous deux sites de premier niveau peuvent créer deux états locaux sans représenter deux personnes. Définissez les rapports autour des événements applicatifs terminés, du consentement et de la relation que le service est autorisé à observer. Ne reliez pas des identifiants partitionnés pour reconstituer une vue intersite. Si des rapports agrégés sont nécessaires, documentez le but de mesure, limitez la conservation et vérifiez le refus et la suppression dans chaque contexte pris en charge.

Testez séparément la récupération de compte. La page de première partie doit restaurer l’accès sans perdre le travail saisi dans l’application supérieure. Le handoff expire, n’expose aucun secret dans l’URL et ne renvoie que le résultat nécessaire. Couvrez annulation, expiration, autre compte actif et redémarrage avec une prochaine action claire.

L’accessibilité couvre le changement de contexte. Annoncez le besoin de configuration, placez le focus sur un titre utile après la continuité de première partie et restaurez la position clavier au retour. Distinguez accès refusé, état expiré et service indisponible avec des messages et contrôles de récupération accessibles.

Traitez toute conclusion de compatibilité comme une observation datée. Notez version et parcours maîtrisé, puis révisez quand navigateur, fournisseur d’identité, SDK ou modèle de consentement évolue. La documentation publique décrit la tâche et la solution de repli prise en charge sans spéculer sur l’implémentation interne.

Sources publiques

• MDN : State Partitioning
• Privacy Sandbox : Storage Partitioning