Rapport Canvas de BrowserLeaks : signaux et limites

BotBrowser peut conserver la cohérence d'un profil de navigateur déclaré lors d'une analyse Canvas autorisée, mais ne peut pas expliquer à lui seul un rapport tiers ni en déduire le verdict d'un site. La page Canvas de BrowserLeaks juxtapose plusieurs types d'éléments : disponibilité d'API, digest issu d'un dessin fixe, recherche dans ses propres données de signatures et détails du fichier PNG. Lire toutes les lignes comme un score unique masque l'opération à l'origine de chaque résultat et ce que la page a réellement établi.

TL;DR

• BrowserLeaks vérifie séparément Canvas 2D, le dessin de texte et l'export PNG en data URL avant d'afficher la section des signatures.
• Son script public dessine un motif fixe de 220×30, encode un PNG, calcule un digest MD5 à partir des octets décodés et interroge /api/canvas/<digest>.
• Le pourcentage étiqueté Uniqueness est calculé avec count et total dans la réponse ; la page publique ne précise ni population d'échantillonnage ni période de collecte.
• La taille en octets, le nombre de couleurs, les chunks et les CRC décrivent la même image générée : ils ne constituent pas quatre identités indépendantes du navigateur.
• Une recherche sans résultat, un digest partagé, un échec de capacité ou un digest différent peuvent avoir des causes distinctes. Aucun de ces cas n'identifie seul une personne ni ne prouve qu'un navigateur est un bot.

Sommaire

• Séparer les couches du rapport
• Suivre le calcul de la signature
• Interpréter le pourcentage Uniqueness affiché
• Lire séparément les détails PNG
• Utiliser un relevé de comparaison contrôlée
• Conclusion pratique

Séparer les couches du rapport

La page publique regroupe des sorties issues d'opérations différentes. Un contrôle de capacité demande si une opération est disponible ; une recherche de signature demande si le rendu d'un dessin correspond à une clé présente dans la réponse du service. La vue d'ensemble du fingerprinting Canvas explique comment un dessin et la lecture des pixels peuvent produire un signal. Ici, les identifiants et le script publics de BrowserLeaks permettent de distinguer les panneaux associés à ce signal.

Zone du rapport	Opération visible sur la page	Conclusion limitée	Ce qu'elle n'établit pas
Lignes de capacité	Contexte Canvas 2D, dessin de texte et contrôle de toDataURL() PNG	Si ces opérations précises ont réussi leurs contrôles	Que toutes les fonctions Canvas soient disponibles, ni que le navigateur soit humain ou automatisé
Signature	Un dessin fixe est encodé et ses octets sont réduits à une valeur MD5	La clé employée par cette page pour rechercher une signature	L'identité d'une personne, une correspondance de compte ou un identifiant universel de navigateur
Statistiques de signature	La réponse fournit count, total et des étiquettes de navigateur et de système d'exploitation	La manière dont la réponse actuelle décrit une clé correspondante	La population source, la période de collecte ou une probabilité de bot mesurée
Détails de l'image	Les couleurs des pixels et les chunks PNG du fichier généré sont analysés	Des propriétés du fichier produit par ce dessin	Des empreintes indépendantes de la signature ci-dessus

Le balisage attribue des identifiants distincts à canvas-support-2d, canvas-support-text et canvas-support-todataurl. La signature et le texte sur les signatures partagées ont également leurs propres éléments, tout comme la taille du fichier, le nombre de couleurs et le tableau des chunks PNG. Le code fournit ainsi une frontière vérifiable entre disponibilité d'une fonction et réponse d'un jeu de données ; une interprétation unique en vert ou en rouge effacerait cette distinction.

La ligne canvas-support-todataurl ne fournit pas un diagnostic complet d'échec. La comparaison des états d'export Canvas sépare data:,, SecurityError synchrone et repli PNG réussi avant l'interprétation du condensat d'une image.

Cette séparation sert aussi à comparer des suites de tests publiques. Ce que testent réellement les suites publiques de détection distingue les contrôles exécutés dans la page des contrôles de connexion en lisant les sections des suites elles-mêmes. La page Canvas de BrowserLeaks est une observation côté page : elle teste son propre dessin JavaScript et l'export d'image, pas TLS, une route proxy ou la décision d'une application concernant un compte.

Suivre le calcul de la signature

Le canvas.js publié fixe la largeur à 220 et la hauteur à 30. Il dessine un rectangle coloré puis écrit la chaîne littérale BrowserLeaks,com <canvas> 1.0 à deux positions proches avec des styles de remplissage différents. Le dessin modifie aussi la ligne de base du texte et les paramètres de police. Ces valeurs définissent l'entrée de ce test ; elles ne forment pas une référence universelle pour Canvas. Un autre texte, la disponibilité des polices, une autre pile de rendu ou une autre taille définiraient une entrée différente.

Le script demande ensuite une data URL PNG avec toDataURL('image/png'). Il vérifie que la valeur retournée commence par le préfixe de data URL PNG, décode la partie Base64 en octets, calcule MD5 sur ces octets et affiche le digest. Il interroge ensuite /api/canvas/<digest> et utilise les champs retournés pour remplir les statistiques de signature. Ces étapes sont visibles dans la source publique ; elles ne signifient pas qu'une session BotBrowser a été lancée ni qu'un digest a été observé en exécutant un navigateur.

Cette chaîne comporte plusieurs limites. Premièrement, la clé couvre les octets issus d'un dessin et d'une voie d'encodage précis ; elle ne résume pas toutes les opérations Canvas accessibles à une page. Deuxièmement, MD5 sert ici de clé de recherche compacte : sa présence ne chiffre pas l'image et ne garantit pas la confidentialité. Troisièmement, une réponse associée à ce digest décrit les données du service, pas la logique de correspondance d'un autre site. Un site peut utiliser d'autres dessins, combiner d'autres signaux ou ne pas utiliser Canvas.

La séquence déduite de la source peut être consignée sans conserver l'image :

Étape	À consigner	Limite d'interprétation
Page et script	URL et date de récupération	L'implémentation peut changer ; ne pas appliquer les constats à une version non fixée
Entrée du dessin	220×30, texte, police, ligne de base, remplissages et positions	Une entrée modifiée ne prouve pas que le moteur de rendu a changé
Export	Acceptation ou rejet de la data URL PNG	L'export est distinct de la disponibilité d'une autre API Canvas
Digest	Présence d'un digest affiché, sans l'image brute	Le digest est une clé de sortie, pas un identifiant utilisateur
Recherche	Réponse présente, absence de correspondance ou indisponibilité	Une ligne absente n'est pas une classification négative de l'automatisation

D'autres projets produisent aussi des pixels, mais suivent leur propre recette. L'analyse du cycle de graines Canvas de CreepJS suit une séquence de valeurs définie par sa source ; sa graine et son nombre de tours ne remplacent pas le dessin fixe de BrowserLeaks.

Interpréter le pourcentage Uniqueness affiché

Quand la réponse de l'API contient une entrée correspondante, le script lit count et total. Il affiche un pourcentage calculé ainsi : floor(100 × (100 − 100 × count / total)) / 100, et présente les comptes sous la forme « count of total user agents have the same signature ». Ce calcul est le complément de la part de correspondances dans la réponse. Ce n'est ni la probabilité que le visiteur actuel soit unique ni une mesure calibrée de la note qu'un détecteur de bots attribuerait à la session.

La source n'indique pas comment les user agents de la réponse ont été échantillonnés, quelles versions de navigateur sont représentées, si les entrées ont été dédupliquées ni quand les comptes ont été recueillis. Sans ces informations, la représentativité du dénominateur ne peut pas être déduite. Une formulation prudente serait « la réponse actuelle indique cette fraction pour son ensemble de user agents enregistré », et non « ce navigateur est unique parmi tous les utilisateurs ». Si la recherche ne retourne aucune entrée, la page marque la signature comme absente de la liste ; cette absence ne prouve pas que le rendu est rare ou nouveau.

Les étiquettes de navigateur et de système d'exploitation affichées sont également des valeurs de réponse. Le code affecte response[digest].browser[0][0] et response[digest].os[0][0] aux éléments de la page. Ces étiquettes décrivent l'enregistrement associé à la clé, pas une lecture directe d'un ordinateur physique. Elles peuvent aider à comprendre le regroupement effectué par le service, mais ne vérifient ni la machine, ni le profil, ni la personne, ni l'application à l'origine de la requête.

Pour une analyse de confidentialité, la route de requête mérite une attention séparée. La page envoie le digest à sa propre route /api/canvas/ pour récupérer des statistiques. Un digest dans une URL reste une donnée de requête ; il peut apparaître dans les journaux du serveur ou dans une télémétrie intermédiaire. Réduire l'image à une valeur courte ne rend pas la requête anonyme. Il ne faut pas fournir à une page de diagnostic publique l'image d'une application sensible ou des données client. Le résultat repose sur le dessin fixe de BrowserLeaks et doit rester distinct des Canvas privés d'une application.

Lire séparément les détails PNG

Le panneau d'image inspecte le même PNG que celui généré pour l'étape de signature. Le script affiche un aperçu, indique la taille en octets du fichier encodé et appelle getImageData(0, 0, 220, 30) pour compter les valeurs de pixels distinctes dans ce rectangle. Il transmet aussi les octets PNG à un analyseur qui énumère les noms de chunks, leurs longueurs, leurs CRC et certains contenus. Le balisage nomme ces lignes « File Size », « Number of Colors » et « PNG Headers ».

Ces détails peuvent aider à diagnostiquer une différence d'export ou d'encodage d'image. Si deux fichiers ont des tailles différentes, le tableau des chunks permet d'examiner le conteneur avant de supposer que les pixels ont changé. Si le nombre de couleurs change, le dessin fixe ou les valeurs de pixels peuvent avoir varié. Mais les métadonnées ne constituent pas une preuve indépendante d'un second trait de l'appareil : taille, couleurs, chunks et MD5 dérivent de la même image. Les compter comme des correspondances sans lien multiplierait une seule observation en plusieurs signaux apparents.

La norme de l'API décrit toDataURL() comme une méthode qui retourne une data URL de l'image Canvas et documente des conditions qui peuvent influer sur le résultat, notamment la propreté d'origine. La ligne visible de BrowserLeaks se limite à son propre contrôle d'export PNG. Elle ne rapporte pas toutes les raisons possibles d'un échec et ne teste pas toutes les origines, images, tous les contextes ou toutes les politiques de navigateur. Il faut distinguer « le contrôle d'export de cette page n'a pas retourné la data URL PNG attendue » d'une affirmation plus générale comme « Canvas est désactivé ».

Utiliser un relevé de comparaison contrôlée

Une comparaison reproductible nécessite de consigner l'entrée et la version de la page, pas seulement une capture d'écran. Notez l'URL de BrowserLeaks, la date de récupération, la version du navigateur, le profil du système d'exploitation, le résultat de chacun des trois contrôles de capacité et la présence ou non d'une réponse de recherche de signature. Pour répéter l'essai, gardez les conditions fixes avant de comparer les digests. Ne changez pas simultanément le profil, la version du navigateur, les polices, la fenêtre d'affichage et la voie graphique avant d'attribuer une différence à un seul facteur.

Observation	À consigner ensuite	À ne pas conclure
Capacité 2D absente	Version du navigateur, erreur de page et présence d'un contexte 2D	Que tout dessin ou tout fingerprinting est indisponible
Capacité de texte différente	Ligne exacte et version/profil utilisés	Que cette différence est à elle seule un signal d'automatisation
Export PNG non accepté	Retour de toDataURL('image/png'), préfixe attendu et erreur visible	Que le navigateur ne possède aucune implémentation Canvas
Statistiques présentes pour le digest	count et total rapportés, avec la date de la source	Que le pourcentage représente Internet entier ou une probabilité de bot
Aucune ligne statistique pour le digest	« Aucune entrée correspondante dans la réponse » et version de la page	Que le digest est nouveau, unique ou suspect
Détails PNG différents	Taille, nombre de couleurs et chunks modifiés	Que chaque champ modifié forme une empreinte indépendante

Ce relevé est volontairement plus limité qu'un profil de fingerprint complet. Il aide une équipe autorisée à répéter un test public sans conserver les pixels bruts ni transformer un résultat isolé en verdict. Un digest stable dans des conditions fixes signifie que la clé est restée identique ; prouver que les octets encodés sont identiques nécessite une comparaison octet par octet. Il ne prouve pas que toutes les surfaces visibles par une page soient stables. Un digest différent indique seulement que la clé de sortie a changé ; le tableau ci-dessus permet de comparer les conditions avant d'attribuer une cause.

FAQ

Un digest partagé signifie-t-il que deux personnes sont identiques ?

Non. Cela signifie que le dessin fixe a produit la même clé pour les observations comparées. Des rendus courants peuvent la partager, et une même personne peut obtenir une autre sortie après un changement de navigateur, de polices, de système d'exploitation ou de rendu. La recherche du service ne peut pas établir qui a émis une requête.

Le pourcentage mesure-t-il l'anonymat ?

Non. La formule dérive de count et total dans la réponse du service. La page publique ne décrit ni la population échantillonnée ni la période ; elle ne permet donc pas d'estimer l'anonymat d'une population entière.

BrowserLeaks renvoie-t-il un verdict de bot ?

La page Canvas affiche des informations de capacité, de signature et de recherche. Son balisage public ne révèle pas de verdict de bot. Un autre service peut combiner d'autres éléments, mais ce rapport ne l'établit pas.

Si la recherche ne peut pas aboutir

Le script public distingue l'absence d'une entrée de l'échec d'une requête. Si la réponse ne contient pas d'entrée pour la clé digest, ou si sa valeur est not_listed, le script ne remplit pas les statistiques de signature. Une requête rejetée ou une erreur d'analyse de réponse entre dans une branche qui affiche « Data retrieval error » et propose un lien de nouvel essai. L'écouteur empêche la navigation par défaut, affiche l'état de chargement et relance la vérification. Ce sont des états du service et de la requête, pas de nouveaux tests de capacité Canvas.

Le contrôle de capacité suit lui aussi une logique délimitée. La page vérifie d'abord l'existence d'un contexte 2D, puis fillText, puis si toDataURL('image/png') retourne une chaîne avec le préfixe attendu. Si le dessin de test déclenche une exception, le script crée un autre Canvas et réessaie ; un second échec marque le contrôle local comme non réussi. Les lignes visibles ne précisent pas l'exception : False limite le constat à ce chemin de code. Il n'identifie pas si la cause est une politique d'origine, une erreur de page, la configuration du navigateur ou l'implémentation.

Cette distinction modifie l'étape de diagnostic suivante. Pour not_listed, conservez le fait que la recherche n'a retourné aucun enregistrement et ne comparez le même dessin que si la question porte sur la reproductibilité. Pour « Data retrieval error », vérifiez d'abord la disponibilité de la requête et la réponse du service public. Pour une ligne de capacité en échec, notez laquelle des trois vérifications a échoué et la version exacte du navigateur ; ne remplacez pas la page de test par une autre en appelant le résultat une reproduction du chemin BrowserLeaks. Si un nouvel essai réussit, cela indique que la première recherche n'a pas abouti, pas que Canvas a changé.

La page interroge également l'API avec le digest dans la route. Une analyse de confidentialité doit considérer cette requête séparément du dessin local : le serveur reçoit une clé stable pour ce motif précis quand la recherche est effectuée. La source publique révèle la forme de la route, mais ne documente ni la rétention, ni les journaux, ni les contrôles d'accès côté serveur. Il ne faut supposer ni que la valeur reste uniquement dans le navigateur ni qu'elle sert à relier une activité entre sites ; le code visible ne permet pas de l'affirmer.

Sources publiques

• Page de test Canvas de BrowserLeaks
• Script Canvas de BrowserLeaks
• MDN : HTMLCanvasElement.toDataURL()
• Section Canvas de la norme HTML WHATWG
• Documentation Canvas de BotBrowser
• Référence de cohérence d'automatisation BotBrowser

Conclusion pratique

Traitez la page Canvas de BrowserLeaks comme un test documenté avec des sorties distinctes : capacité, image générée, recherche de signature et inspection PNG. Conservez le dénominateur et la date de la source lorsque vous parlez du pourcentage, et décrivez une recherche sans entrée comme telle, pas comme un verdict. Le digest sert à reproduire le dessin fixe de la page ; les étiquettes du service ne vérifient pas une identité et ne décident pas si un accès est automatisé.