Rapport WebGL BrowserLeaks : collecte et champs absents

Quand un rapport WebGL de BrowserLeaks laisse le rendu ou le hachage d’image vide, ce vide ne révèle pas à lui seul sa cause. La page publique combine la découverte du contexte, des lectures de paramètres ordinaires, des métadonnées de rendu facultatives, des contrôles de précision et une empreinte des pixels rendus. BotBrowser documente des contrôles de profil qui configurent une surface WebGL déclarée pour un examen autorisé ; il ne peut pas expliquer le champ absent d’un rapport tiers, ne contrôle pas le script de cette page et ne prédit pas la décision d’un autre service. L’analyse des sources WebGL de CreepJS suit un autre collecteur et ses propres comparaisons entre contextes.

TL;DR

• BrowserLeaks essaie une séquence fixe de noms de contextes WebGL avant de collecter les lignes du contexte sélectionné.
• Les lignes getParameter, l’extension facultative WEBGL_debug_renderer_info, les précisions de nuanceur et une empreinte ultérieure de readPixels suivent des parcours distincts.
• L’absence d’une valeur de rendu non masquée ne prouve ni le blocage d’une extension, ni un modèle de GPU, ni l’usage d’un outil de confidentialité ou l’automatisation.
• Notez la révision de la page et l’étape qui a produit l’absence ; répétez cette étape avec la même version du navigateur et la même origine avant de comparer.
• BotBrowser documente des contrôles de profil pour valider WebGL, sans garantir qu’une valeur précise s’affiche sur BrowserLeaks ou un autre site.

Contents

• Regarder la vidéo
• Commencer par les étapes de collecte
• Paramètres ordinaires et données facultatives du rendu
• Précision et pixels sont distincts
• Classer un champ absent avant de l’interpréter
• Utiliser une fiche de rapport contrôlée
• Conclusion pratique

Regarder la vidéo

Cette vidéo est en anglais. Elle détaille les cinq étapes de collecte puis exécute un fixture contrôlé en cinq étapes dans Chrome réel : le résultat natif de getContext('webgl2'), la chaîne de rendu renvoyée par l'extension de débogage, un entier de précision de shader et un véritable tampon readPixels. Le fixture rejoue l'ordre d'étapes publié ; il ne mesure pas l'appareil d'une personne précise.

Commencer par les étapes de collecte

La page WebGL publique de BrowserLeaks est un modèle de rapport avec des sections distinctes pour la détection de prise en charge, l’empreinte WebGL, le hachage du rapport, le hachage d’image et l’image rendue. Le code de la page et son script montrent l’ordre de collecte, mais télécharger ces fichiers n’exécute pas le rapport dans un navigateur. Les constats ci-dessous constituent donc une lecture du code source, et non le résultat d’un profil utilisé en direct.

Le script essaie les noms de contexte dans cet ordre : webgl2, webgl, moz-webgl, webkit-3d et webgl2-compute. Pour chaque candidat, il crée un canevas et appelle getContext ; il conserve le premier contexte exploitable et poursuit avec celui-ci. Atteindre un candidat de repli n’équivaut pas à réussir dès le premier, même si les deux pages affichent finalement des lignes.

Deux détails de cette boucle comptent lorsqu’un rapport paraît faux. D’abord, le canevas est créé à une taille fixe de 256 par 128 et réutilisé pour l’étape de dessin : les dimensions du tampon de dessin décrivent donc ce canevas, pas la fenêtre du navigateur. Ensuite, chaque tentative passe failIfMajorPerformanceCaveat: false et écarte un contexte dont isContextLost() renvoie déjà vrai. Un candidat qui échoue à l’un des deux tests est ignoré sans message et la boucle continue, ce qui explique qu’un nom de repli produise un rapport complet alors que le premier ne produit rien.

Le collecteur conserve aussi tous les contextes obtenus, et pas seulement celui qui est sélectionné. Le sélecteur de contexte de la page est construit à partir de cette liste : le nombre de noms proposés enregistre donc combien de tentatives ont réussi. Si le sélecteur n’affiche que webgl, c’est que webgl2 a été tenté puis rejeté ; cela n’indique ni la raison ni une absence de WebGL2 dans le navigateur en général.

Étape	Action du script public	Ce qu’une sortie absente permet de circonscrire
Découverte du contexte	Essaie les noms candidats sur un nouveau canevas	Si un contexte candidat a été obtenu ; pas pourquoi les champs suivants manquent
Lignes de paramètres	Résout chaque ID en constante du contexte, puis transmet cette constante à getParameter	Quelle requête ordinaire n’a produit aucune valeur affichable
Rendu de débogage	Demande WEBGL_debug_renderer_info et lit ses constantes non masquées uniquement si un objet est renvoyé	Si cette branche facultative a fourni une valeur ; pas l’identité du GPU
Précision	Appelle séparément des fonctions de précision des nuanceurs	Si la fonction de précision a produit un résumé exploitable
Empreinte d’image	Dessine une autre scène, lit un tampon de pixels, le sérialise et calcule une empreinte	Si le parcours de rendu/lecture s’est achevé ; pas si le collecteur de paramètres a fonctionné
Empreinte du rapport	Sérialise l’objet collecté et condense cette sérialisation	Si l’objet sérialisé est resté stable entre deux captures ; pas si une ligne était correcte

Ce tableau aide à lire le rapport sans énumérer toutes les causes possibles d’un échec du navigateur. Des étapes différentes peuvent laisser la même zone vide, et la page ne montre pas toujours laquelle a échoué. Le guide général sur l’empreinte WebGL traite la surface plus large et les contrôles de profil documentés ; cette page interprète précisément le pipeline BrowserLeaks.

Paramètres ordinaires et données facultatives du rendu

Pour les lignes ordinaires, BrowserLeaks parcourt les éléments .pname, lit l’ID de chacun, résout ce nom sur le contexte WebGL sélectionné et transmet à getParameter la constante obtenue. Le tableau sert ainsi d’inventaire des requêtes, mais chaque ligne n’apporte de preuve que sur une requête dans un contexte donné. Elle ne décrit pas entièrement le GPU, et une ligne vide ne révèle pas si la requête a été omise, si sa valeur n’a pas été affichée par l’interface ou si un échec antérieur s’est produit.

Utiliser les ID d’éléments comme noms de propriété a une conséquence : les noms des lignes viennent de la page, tandis que les constantes interrogées viennent du contexte WebGL sélectionné. Dans le script publié, n désigne ce contexte et chaque ID listé est interrogé par getParameter(n[id]). Une constante de la spécification absente du balisage ne peut pas apparaître, et ajouter un ID correspondant à une propriété du contexte modifierait l’objet collecté sans changer le navigateur.

Après la boucle, le collecteur fusionne trois sources non paramétriques dans le même objet : les attributs renvoyés par getContextAttributes(), les propriétés drawingBufferColorSpace et unpackColorSpace, et la liste des extensions prises en charge. Les attributs de contexte sont les valeurs avec lesquelles le contexte a été créé, pas des valeurs que le navigateur rapporte sur son matériel, et les deux propriétés d’espace colorimétrique sont des chaînes qui suivent la configuration du canevas. Les lire dans un tableau plat est commode, mais elles répondent à d’autres questions qu’une ligne de getParameter.

Les champs de fabricant et de rendu non masqués suivent une autre branche. Le script appelle d’abord getExtension('WEBGL_debug_renderer_info') ; il ne lit UNMASKED_RENDERER_WEBGL et UNMASKED_VENDOR_WEBGL que s’il reçoit un objet d’extension. MDN précise que getExtension() renvoie un objet lorsque l’extension est disponible et null dans le cas contraire. Ce contrat explique la condition de la branche, mais pas l’absence d’une chaîne non masquée dans un rapport précis. L'analyse des limites de vie privée de WEBGL_debug_renderer_info distingue cet état API des affirmations d'identité.

Deux autres paramètres passent par leur propre extension et non par la liste ordinaire : MAX_DRAW_BUFFERS_WEBGL depuis WEBGL_draw_buffers, et MAX_TEXTURE_MAX_ANISOTROPY_EXT depuis la première de EXT_texture_filter_anisotropic, WEBKIT_EXT_texture_filter_anisotropic ou MOZ_EXT_texture_filter_anisotropic qui répond. Les deux sont conditionnés par une recherche d’extension : ils peuvent donc rester vides pour la même raison que le rendu non masqué. Dans le balisage, ces lignes voisinent avec les paramètres ordinaires, ce qui rend la différence facile à manquer.

Gardez ces cas séparés dans la note du rapport :

Observation	Formulation étayée	Conclusion non étayée
Ligne de rendu ordinaire présente, ligne non masquée vide	La ligne ordinaire s’affiche ; la valeur facultative non masquée ne s’affiche pas	« Le navigateur cache un GPU précis »
La recherche d’extension ne renvoie aucun objet	La branche facultative n’avait aucun objet à interroger	« Un outil de confidentialité l’a bloquée »
Aucun contexte n’est sélectionné	Ce collecteur n’a pas poursuivi avec un contexte choisi	« Le navigateur n’a pas de GPU »
Champ absent d’un rapport enregistré	L’artefact enregistré ne contient pas ce champ	« L’appel API d’origine a échoué »

Chaque conclusion non étayée invente une cause qui n’a pas été observée. Une seconde capture peut vérifier si la même étape se répète, mais elle ne prouve pas une cause sans noter les conditions qui ont changé.

Précision et pixels sont distincts

La précision des nuanceurs provient d’appels à getShaderPrecisionFormat, et non d’une déduction depuis la chaîne du rendu de débogage. Un résumé de précision et une étiquette de rendu peuvent donc différer sans que l’un soit une copie corrompue de l’autre. Si le consommateur du rapport les expose, notez séparément l’étape du nuanceur, la classe de précision, la plage et la précision renvoyées, ainsi que toute exception ou absence.

Le rapport présente deux résumés de précision différents. L’un compare le résultat haute précision en virgule flottante au résultat moyenne précision pour la même étape de nuanceur et retient le résultat moyen lorsque le haut signale une précision nulle. L’autre réduit deux requêtes distinctes, HIGH_FLOAT et HIGH_INT, à une courte étiquette highp/mediump et highp/lowp. Une seule étiquette du tableau représente donc jusqu’à trois appels auxiliaires, et une valeur qui paraît grossière peut venir du repli plutôt que du support réel de précision du navigateur.

L’empreinte d’image suit encore un autre parcours. BrowserLeaks dessine une petite scène WebGL, lit ses pixels dans un Uint8Array avec readPixels, sérialise le tableau puis calcule une empreinte de cette sérialisation. Cette empreinte décrit ce dessin dans le contexte et les conditions d’exécution sélectionnés. Ce n’est pas un paramètre API et elle ne prouve pas qu’une personne ou un appareil a été identifié.

Le dessin est un éventail fixe de segments produit par une boucle de 128 pas entre 45 et 315 degrés, tracé avec LINE_STRIP et une matrice de projection inscrite dans le script. Comme la géométrie vient de constantes, une empreinte d’image modifiée désigne le parcours de rendu, la taille du canevas, l’espace colorimétrique ou la relecture, et non un modèle de GPU différent. L’empreinte du rapport couvre une autre entrée : c’est une empreinte de l’objet sérialisé, elle change donc dès qu’une ligne collectée change, y compris celles sans rapport avec le rendu.

Pour une comparaison contrôlée, conservez la révision du rapport, la version du navigateur, le système d’exploitation, l’origine, le nom du contexte sélectionné, la fenêtre d’affichage et l’heure de collecte. Comparez des lignes de paramètres entre elles, les données d’extension avec les mêmes données, la précision avec la même requête, et les empreintes seulement si le dessin et la lecture n’ont pas changé. Si seule l’empreinte change, vérifiez les entrées du dessin et la lecture avant d’attribuer l’écart au rendu ou au profil.

Ne réduisez pas les données à un seul champ nommé « empreinte WebGL ». Cette étiquette masque l’appel qui a produit la valeur et ce qui peut être répété. Une fiche compacte avec les résultats par étape est plus utile pour diagnostiquer une exportation de rapport ou un problème de compatibilité de page.

Classer un champ absent avant de l’interpréter

Utilisez la première ligne correspondante. Le suivi permet de distinguer un problème d’étape de collecte d’un problème d’affichage du rapport ; il ne suppose aucun défaut précis du navigateur.

Deux états méritent d’être séparés avant de consulter le tableau. Une valeur affichée empty est un null ou une chaîne vide renvoyée par getParameter : une réponse vide, pas un appel manquant. Une valeur affichée undefined signifie que l’objet collecté n’avait aucune clé pour cette ligne, ce qui désigne l’étape de collecte plutôt que la requête. Les deux étiquettes se ressemblent sur une capture et mènent à des vérifications différentes.

Donnée absente	Première vérification	Suivi répétable
Toutes les sections WebGL	Si le contrôle de prise en charge et la découverte du contexte ont été exécutés	Rechargez une fois avec la même origine et la même version ; capturez le contexte choisi ou l’étape exacte de l’échec
Un paramètre	Si l’ID de ligne correspondant existe dans la révision téléchargée	Répétez cette requête dans une page de diagnostic que vous contrôlez et conservez le type/la valeur renvoyé ou l’exception
Fabricant ou rendu non masqué uniquement	Si la branche facultative a reçu un objet d’extension	Notez séparément la disponibilité de l’extension et la ligne ordinaire ; ne déduisez pas un blocage de l’absence
Résumé de précision	Quelle étape de nuanceur et quelle classe de précision ont été interrogées	Répétez le même appel et conservez le résultat ou l’exception
Empreinte d’image uniquement	Si le dessin, readPixels, la sérialisation et l’empreinte sont terminés	Conservez la révision du dessin et le résultat de lecture ; ne comparez pas des scènes différentes
Empreinte du rapport uniquement	Si une ligne collectée a changé entre les captures	Comparez d’abord les valeurs ligne par ligne ; une empreinte différente sans ligne différente signale un changement d’ordre de sérialisation

Si deux captures diffèrent, notez ce qui est resté constant et ce qui a changé. Une révision de page, un contexte de repli, une origine, une configuration d’affichage ou une scène différente peut modifier le parcours sans prouver que l’identité du navigateur a changé. À l’inverse, des valeurs identiques dans un rapport ne prouvent pas l’équivalence d’applications sans lien.

La page conserve un bouton de clés brutes qui réécrit la première colonne du tableau. Le basculer ne change que l’étiquette vue par le lecteur, pas l’objet collecté : deux captures de la même collecte peuvent donc différer dans cette colonne. Pour vérifier que deux rapports ont collecté les mêmes lignes, comparez les noms de clé, pas les étiquettes.

Utiliser une fiche de rapport contrôlée

Ce schéma de fiche n’est pas une sortie d’exemple. Remplissez-le à partir du rapport et de votre capture ; ne copiez pas une valeur attendue dans un champ d’observation.

{
  "toolUrl": "https://browserleaks.com/webgl",
  "capturedAt": "YYYY-MM-DDTHH:mm:ssZ",
  "pageRevision": "enregistrer l’URL du script ou le hachage du contenu",
  "browserBuild": "noter la version réelle",
  "origin": "noter l’origine du rapport",
  "selectedContext": "noter le nom réel du contexte ou null",
  "ordinaryParameterRows": "présent, absent ou erreur par ligne",
  "debugRendererExtension": "objet, null ou non atteinte",
  "precisionChecks": "noter chaque classe interrogée et le résultat",
  "pixelRead": "terminée, absente ou erreur",
  "imageDigest": "noter uniquement si elle apparaît réellement"
}

Ce schéma conserve la révision et l’état de collecte avec les valeurs afin qu’une comparaison ultérieure répète le même parcours. Il ne comporte volontairement aucun champ de verdict : déterminer si une application accepte un environnement exige des preuves issues de son contexte documenté et autorisé.

Une fiche remplie à partir d’une capture répond à une question plus étroite qu’une fiche remplie à partir de plusieurs. Une capture établit qu’une branche a produit une valeur dans les conditions notées. Plusieurs captures avec une condition modifiée peuvent montrer si cette branche y est sensible, mais seulement si tous les autres champs sont restés identiques. Le schéma enregistre les conditions ; il n’attribue pas de note à la page.

FAQ

Un rendu non masqué vide signifie-t-il que l’extension a été bloquée ?

Non. Cela signifie que le rapport enregistré ne montre pas cette valeur. Notez si la branche de l’extension a été atteinte et ce que getExtension() a renvoyé avant de formuler une conclusion plus précise.

L’empreinte d’image est-elle un autre identifiant de GPU ?

C’est une empreinte des pixels rendus par le script. Elle peut servir à comparer le même procédé de dessin, mais elle n’identifie pas à elle seule un GPU, un appareil ou une personne.

BotBrowser garantit-il que ces champs correspondent à BrowserLeaks ?

Non. BotBrowser documente des contrôles de profil pour valider des surfaces du navigateur dans un cadre autorisé. Le rapport dépend de son script, de la révision de la page et des conditions d’exécution ; aucun réglage ne garantit un résultat ou un classement tiers.

Sources

• Rapport WebGL BrowserLeaks et son collecteur publié, lus comme sources le 2026-11-04.
• MDN : WebGLRenderingContext.getExtension() et getParameter().
• BotBrowser : contrôles de l’empreinte WebGL et pratiques de cohérence de l’automatisation.
• Collecte WebGL et signaux de capacité de CreepJS, pour le collecteur distinct de CreepJS.

Conclusion pratique

Interprétez un rapport WebGL BrowserLeaks comme plusieurs parcours de collecte, et non comme un résultat unique de réussite ou d’échec. Conservez séparément le contexte, les paramètres, l’extension facultative, la précision et la lecture des pixels ; répétez seulement l’étape absente dans des conditions consignées. Une comparaison défendable s’appuie sur ces étapes consignées, et une différence de rendu reste une différence de rendu.