Valider la confidentialité selon le backend de rendu

BotBrowser prend en charge des backends Linux documentés pour WebGL et WebGPU; le résultat dépend du backend, du mode, de l'hôte et du profil examinés. Le backend de rendu influence davantage que la cadence d'affichage. Canvas, WebGL et WebGPU exposent des signaux liés au navigateur et aux graphiques. Lorsqu'un flux passe d'un poste de travail à un serveur Linux, au rendu logiciel ou à une session headless, ces signaux peuvent changer. WebNN est une interface voisine avec ses propres questions de disponibilité et de backend, traitées dans Disponibilité de WebNN, backends et confidentialité.

TL;DR

• Notez navigateur, profil, hôte, mode d'affichage et backend dans une même matrixRow.
• Utilisez un parcours pris en charge et consignez completionState avant de changer une seule entrée.
• Séparez les capacités Canvas, WebGL et WebGPU du temps CPU et de la latence de capture.
• Mettez en pause ou revenez en arrière si la capacité requise ou le résultat visible dépasse la limite documentée.

Sommaire

• Construire la matrice
• Comparer des familles de signaux
• Documenter le rendu logiciel
• Conclusion pratique

Construire la matrice

Notez la version BotBrowser, le profile family, la plateforme cible, le système hôte, le mode du navigateur, le service d’affichage et le backend. Gardez le parcours applicatif identique et ne changez qu’un élément à la fois. Comparez au minimum une session headed, une session headless et le type d’hôte utilisé en production.

Le profile et la version majeure du navigateur forment une unité. Un résultat obtenu avec une version ne remplace pas la validation d’une autre version.

Comparer des familles de signaux

Canvas, WebGL, WebGPU, la géométrie d’écran et le timing peuvent être liés sans être identiques. Une valeur stable ne prouve pas la cohérence de toute l’identité graphique. Vérifiez d’abord le résultat visible du parcours, puis les familles de signaux couvertes par le produit. Lorsqu’un écart demande un examen plus approfondi, les preuves d’exécution décrites dans V8Log Forensics : preuves d’exécution pour la validation privacy peuvent aider.

Une page publique doit expliquer la comparaison et les limites de support. Les scripts de détection, seuils et journaux internes restent dans les enregistrements contrôlés.

Dans une ligne, journeyRevision identifie les étapes et le critère visible de fin ; completionState décrit l’état affiché et baselineStatus indique si la configuration acceptée satisfaisait déjà ce critère. backend désigne le chemin graphique, pas le résultat utilisateur. Une matrixRow représente une combinaison précise, pas une promesse générale. Ajoutez l’équipe responsable et la prochaine date de revue.

Classez les résultats distinctement : « terminé » signifie que le parcours atteint son état attendu ; « capacité indisponible » signifie qu’une opération graphique requise manque même si la page charge ; « résultat applicatif différent » décrit un parcours terminé avec un écart dont la cause reste à établir. Notez l’observation qui justifie la classe. Un écart n’attribue pas à lui seul la cause au navigateur.

Avant d’évaluer un candidat, rejouez la ligne acceptée sur le même hôte et la même fixture. Si elle ne satisfait plus le critère, réparez d’abord la référence. Si elle réussit, utilisez le même parcours, viewport, état initial du stockage et révision applicative pour le candidat en ne changeant qu’une dimension pertinente. En cas d’écart, rejouez une fois la référence pour écarter un incident transitoire.

Le retour arrière restaure la combinaison connue : paire navigateur/profil, politique hôte, voie d’affichage, politiques de route et de stockage, puis backend. Remettre seulement l’ancien binaire ne suffit pas si les bibliothèques de l’hôte ou le service d’affichage ont changé. La revendication publique doit préciser plateforme, ligne de navigateur, profil, mode, backend et parcours couverts, ainsi que les cas non évalués.

Une capture peut montrer un recadrage ou un contrôle manquant, mais elle ne prouve ni la disponibilité d’une API graphique ni la conformité d’un signal de confidentialité. Si WebGPU est facultatif, évaluez le repli prévu. S’il est requis, la ligne échoue même si le reste de la page fonctionne. Un écart visuel avec interaction réussie doit être jugé selon l’exigence du parcours, pas automatiquement comme un échec de confidentialité.

Documenter le rendu logiciel

Les serveurs Linux peuvent utiliser le rendu logiciel sans GPU pris en charge, dans un conteneur ou pour obtenir un chemin reproductible. Notez le backend, le service d’affichage, les bibliothèques et le mode du navigateur. Évaluez séparément la cohérence de confidentialité et le coût opérationnel. Le rendu logiciel et ses replis de capacité sont présentés dans Rendu WebGL logiciel, replis de capacité et vie privée. Pour une comparaison mesurée des backends logiciels sous Linux, voir Mesa llvmpipe ou SwiftShader pour Chromium sous Linux.

Si une capacité nécessaire manque, arrêtez cette ligne de la matrice et choisissez un backend pris en charge. Ne modifiez pas la limite de confidentialité avec un flag non validé. Ce qu’une page peut faire lorsqu’un appareil WebGPU est perdu en cours de session est expliqué dans Récupérer après la perte d’un appareil WebGPU.

Lectures associées.

Canvas Fingerprinting, WebGL Fingerprinting et WebGPU Fingerprinting présentent les familles de signaux. Évaluer la cohérence multiplateforme présente la matrice des hôtes.

BotBrowser prend en charge des backends documentés de rendu logiciel sous Linux pour WebGL et WebGPU, mais BotBrowser ne garantit pas le même résultat sur tous les GPU ou environnements Linux ; chaque résultat dépend du backend, du mode du navigateur, de l’hôte et du profil testés.

Sources

• Documentation BotBrowser du backend GPU Linux
• Spécification WebGPU du W3C
• Spécification WebGL de Khronos

Conclusion pratique

• Associez chaque version au profile family correspondant.
• Notez hôte, cible, mode, affichage et backend.
• Utilisez un parcours réel, pas seulement une page vide.
• Examinez Canvas, WebGL, WebGPU, affichage et timing ensemble.
• Gardez probes, seuils, journaux et preuves client dans des dossiers contrôlés.

Conservez une matrixRow pour chaque environnement pris en charge, répétez le même journeyRevision et séparez le résultat visible des signaux de confidentialité et de la performance. Ne promouvez un backend que lorsque le couple navigateur/profil, l’hôte, le mode d’affichage et l’opération graphique restent dans la limite documentée; sinon gardez la ligne acceptée et le paquet de retour arrière.