Private Verification Tokens : proposition de Chrome et BotBrowser

La navigation privée peut faire passer une personne connue pour un nouveau client. Private Verification Tokens (PVT) est une proposition limitée à un site, pas une fonctionnalité publiée ; BotBrowser ne l’active pas et ne peut pas obliger un site à faire confiance à une visite privée.

TL;DR

• PVT reste une proposition, pas une fonctionnalité généralement disponible.
• Le concept vise à transmettre un signal de confiance limité au contexte privé sans révéler l’historique de navigation.
• BotBrowser n’active, ne falsifie, n’importe ni ne précharge de jetons PVT.
• Testez séparément les parcours réguliers et privés ; ne faites pas dépendre une décision de production de PVT.

Sommaire

• Regarder la vidéo
• L’essentiel en quelques mots
• Quel problème PVT cherche-t-il à résoudre ?
• Schéma conceptuel
• Proposition, expérimentation ou fonctionnalité livrée ?
• Ce que cela change pour la navigation privée
• Ce que les opérateurs peuvent tester dès maintenant
• Conclusion pratique

Regarder la vidéo

Cette vidéo en anglais lit la proposition Private Verification Tokens face au registre de la plateforme : Chrome Platform Status la liste comme proposée et non publiée. Une page de laboratoire locale demande ensuite à la console de Chrome stable s'il existe une entrée feature-policy contenant « verification » sous Ubuntu (Chrome 154) et Windows (Chrome 155), et une lecture en contexte privé affiche ce que voit aujourd'hui un contexte privé. Chaque hôte a affiché 0 correspondance et aucune surface PVT sur une seule exécution, ce qui ne dit rien d'une autre version ni d'un autre site. Aucun profil BotBrowser n'intervient. L'audio est en anglais.

La politique de connexion proposée est une frontière distincte du navigateur : Connection Allowlists : déploiement et limites explique pourquoi une annonce datée, un instantané ChromeStatus et un brouillon WICG ne doivent pas devenir une seule affirmation de prise en charge.

L'essentiel en quelques mots

Private Verification Tokens (PVT) est une proposition de confidentialité que Chrome explore pour la navigation privée. L'idée est qu'un site puisse recevoir un justificatif limité pendant une navigation normale, puis qu'une requête provenant d'une session privée puisse présenter un signal de portée réduite. Il ne s'agit pas d'une capacité Web générale déjà livrée : la proposition reste précoce et expérimentale. Dans un test contrôlé, BotBrowser peut garder cohérentes les surfaces d’empreinte entre sessions normale et privée d’un même profil dans un test contrôlé ; il ne peut pas obliger un site à accepter un visiteur privé.

Au moment de la rédaction, Chrome Platform Status classe PVT comme proposed et not released. Les versions actuelles de BotBrowser n'activent pas PVT et ne fabriquent, n'importent ni ne préchargent de tokens PVT. Ces limites sont plus importantes que le simple nom d'une fonctionnalité dans une page d'état.

Pour des limites de confidentialité proches, comparez la détection du mode privé et la vérification de l'empreinte du navigateur. Ces sujets décrivent des décisions distinctes du navigateur et du site, pas la publication de PVT.

Quel problème PVT cherche-t-il à résoudre ?

La proposition désigne ce signal limité par Sec-Private-Verification-Token.

La navigation privée vise à réduire l'état persistant et le rapprochement entre les sessions. Un nouveau contexte privé ne possède généralement pas les cookies, le stockage du site ou la session ouverte d'un profil normal. Pour un site, il devient difficile de distinguer une personne qui vient d'ouvrir une fenêtre privée propre d'un client qui ne dispose réellement d'aucun état réutilisable. Pour savoir quels enregistrements locaux une fenêtre privée limite et qui peut encore voir l’activité, consultez Ce que fait et ne fait pas la navigation privée, qui explique aussi ce qui se ferme avec la session.

Dans les deux cas, le site peut demander une vérification supplémentaire. Pour la personne, cela peut créer une friction inutile ; pour le site, ignorer totalement cette différence peut produire des résultats imprécis. PVT explore un point intermédiaire plus étroit : le navigateur pourrait indiquer qu'il a déjà reçu un signal de confiance valide pour ce site, sans transmettre la session normale ni son historique. Pour comprendre pourquoi une fenêtre privée ne modifie pas l’empreinte du navigateur, consultez Navigation privée et fingerprinting : pourquoi elle ne suffit pas, qui compare pas à pas une session normale et une session privée.

La « confiance » ne constitue ni une identité ni une authentification. Le signal ne devrait pas révéler l'identité de la personne, les pages consultées ou la session qui a créé le token. La conception publique vise une réponse minimale pour un site enregistré : le navigateur peut-il présenter un justificatif valide et limité ?

Schéma conceptuel

Le schéma ci-dessous illustre uniquement la relation conceptuelle décrite publiquement. Il ne représente ni un comportement déjà publié ni une implémentation de BotBrowser. Le navigateur gère la frontière entre la navigation normale et la navigation privée, et le site ne reçoit que le résultat autorisé par la spécification.

Proposition, expérimentation ou fonctionnalité livrée ?

Ces termes ne sont pas interchangeables. L'explainer public présente PVT comme une première esquisse et précise que la fonctionnalité n'est pas approuvée pour une livraison dans Chrome. Chrome Platform Status l'enregistre comme proposed et not released. Ses champs de milestone pointent vers Chrome 154 à 165, tandis que d'autres publications décrivent cette période comme une voie expérimentale possible. L'enregistrement, l'examen, la disponibilité et le comportement final peuvent changer. Pour suivre une proposition depuis son intention publique jusqu’à des preuves bornées dans le navigateur, consultez Des standards du navigateur à l’état d’implémentation, qui inclut une fiche d’état.

Les développeurs ne doivent donc pas considérer PVT comme un contrat Web stable et universel. Même si une version expérimentale montre un comportement associé, cela ne permet pas de conclure que tous les utilisateurs de Chrome, tous les systèmes d'exploitation ou tous les contextes privés obtiendront le même résultat. Il faut noter séparément la version, l'état de l'enregistrement et l'étape du déploiement.

Ce que cela change pour la navigation privée

L’évaluation doit distinguer la limite du site eTLD+1 de l’identité du profil.

PVT s'intéresse à une tension concrète : la navigation privée ne devrait pas être considérée comme anormale simplement parce qu'elle ne possède pas de cookies persistants, mais réduire les erreurs ne devrait pas créer un canal d'identité durable. Une conception responsable doit au moins répondre aux questions suivantes :

• Quelles informations peuvent passer du contexte normal au contexte privé ?
• Des identités, profils ou fenêtres privées distincts peuvent-ils partager le résultat ?
• Un site peut-il combiner le signal avec d'autres données pour créer un identifiant durable ?
• Le signal reste-t-il limité au site enregistré ou peut-il devenir un mécanisme inter-sites ?
• Les personnes et les opérateurs peuvent-ils comprendre quand le signal existe ou manque ?

Un seul en-tête ou le nom d'une API ne suffit pas à répondre. Il faut tester les versions de navigateur, les systèmes d'exploitation, les profils normaux, les contextes privés et les combinaisons de plusieurs fenêtres. L'absence du signal, son refus et l'absence de prise en charge par le navigateur sont des résultats différents qui doivent être distingués dans les journaux.

Ce que fait BotBrowser aujourd'hui

BotBrowser peut maintenir la cohérence des surfaces d'empreinte, des valeurs de quota de stockage et du comportement des API de stockage entre les sessions normales et en navigation privée pour un même profil, afin que votre équipe puisse comparer l'état du contexte normal et du contexte privé lors de l'évaluation de PVT. La limite est explicite : BotBrowser n'active pas PVT, ne fabrique, n'importe ni ne précharge de tokens PVT, ne peut pas rendre PVT disponible avant que Chrome ne le publie et ne contrôle pas si un site accepte un visiteur privé ou lui fait confiance.

Il s'agit d'un choix explicite fondé sur l'état public actuel. La spécification, l'enregistrement, le comportement entre navigateurs et les limites de confidentialité continuent d'évoluer. Tant que ces conditions ne sont pas stabilisées, conserver le comportement actuel permet aux utilisateurs de mieux le comprendre et de le vérifier. Les profils normaux, les contextes privés et les autres signaux du navigateur continuent de fonctionner selon la version et les notes de version en vigueur.

Une éventuelle réévaluation devrait reprendre l'étude des propriétés de confidentialité, de l'isolation entre profils et contextes et des rapports publics de compatibilité. Tout changement devra être annoncé dans une nouvelle note de version ; cela n'annonce pas l'activation de la fonctionnalité.

Ce que les opérateurs peuvent tester dès maintenant

Traitez Sec-Private-Verification-Token comme un marqueur proposé, pas comme une interface disponible.

Si votre application reçoit à la fois des visiteurs en navigation normale et privée, consignez séparément les situations suivantes :

1. Un profil normal avec un état existant pour le site.
2. Un nouveau profil normal sans état préalable.
3. Un nouveau contexte privé issu d'un profil normal.
4. Deux contextes privés indépendants qui ne doivent partager ni identité ni état de confiance.

Pour chaque test, notez la version du navigateur, le système d'exploitation, l'état du profil, le type de contexte, l'enregistrement éventuel du site et le résultat observable. Ne déduisez pas la prise en charge de la simple présence du nom PVT dans une page d'état et n'extrapolez pas le résultat d'une seule requête à tous les utilisateurs.

L'application peut considérer PVT comme une entrée future possible, et non comme une dépendance actuelle. Les contrôles de vérification, les messages de confidentialité, la voie de repli et la gestion des erreurs doivent fonctionner sans PVT. Ainsi, un report, une modification de conception ou une disponibilité partielle ne conditionnera pas l'expérience.

Questions fréquentes

PVT est-il un justificatif de connexion ?

Non. La conception publique le limite à un signal destiné à un site enregistré ; il ne remplace ni la connexion, ni l'autorisation, ni la vérification d'identité. Il indique seulement qu'un signal de confiance limité a pu exister auparavant, pas l'identité d'une personne précise.

PVT transforme-t-il la navigation privée en navigation normale ?

La proposition cherche à conserver la séparation du contexte privé. La réponse dépendra de la spécification finale, des navigateurs et de l'usage qu'en feront les sites. Une esquisse n'est pas une garantie.

Quand BotBrowser l'activera-t-il ?

Aucun plan ni engagement produit n'est prévu actuellement. Consultez les futures notes de version et les rapports de compatibilité de BotBrowser.

Sources

• Private Verification Tokens explainer
• Chrome Platform Status: Private Verification Tokens
• Documentation incognito de BotBrowser
• PPC Land: Chrome tests a one-bit signal telling sites an Incognito visitor is human

Conclusion pratique

Considérez PVT comme une proposition, pas comme une dépendance de production. Gardez les parcours privés fonctionnels sans ce jeton et réévaluez la capacité uniquement si les documents officiels et les notes de version confirment un changement.