Empreinte Canvas : exports vides et erreurs
Distinguer le résultat data:, du repli PNG et de SecurityError dans un test d’empreinte Canvas.
BotBrowser Team
Vous voulez la documentation structurée pour Empreinte ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Un test d'empreinte Canvas peut échouer à produire une image avant de disposer de pixels à comparer. BotBrowser documente des contrôles du bruit Canvas et --bot-noise-seed pour des résultats cohérents. Cette configuration ne garantit pas la réussite d'un export, l'utilisation de l'encodeur demandé ou le respect de la condition origin-clean. Un condensat absent doit donc être associé à un état d'export, plutôt qu'à une explication immédiate sur l'identité du navigateur.
TL;DR
data:,est une sentinelle de résultat vide, pas un PNG vide. Une dimension nulle et un échec de sérialisation peuvent renvoyer la même valeur.- MDN documente aussi
data:,lorsque les dimensions dépassent la limite Canvas de l'implémentation. La chaîne n'identifie pas la cause. - Une image matricielle non origin-clean provoque un
SecurityErrorsynchrone ; cette vérification précède celle des dimensions nulles. - Un type d'image demandé mais non pris en charge peut se replier avec succès sur PNG. Obtenir du PNG ne prouve pas que l'encodeur demandé a fonctionné.
toBlob()expose un résultat différent : le retour immédiat estundefined, tandis que le rappel reçoit unBlobounull. L'exception de sécurité reste synchrone.
Sommaire
- Interpréter un résultat d'export
- Dimensions, propreté et ordre des exceptions
- Formats demandés et travail de sérialisation
- Cas de comparaison pour les rapports d'empreinte
- Enregistrement de diagnostic minimal
- Questions fréquentes sur les états d'export Canvas
- Conclusion pratique
Le schéma représente des résultats d'export documentés. C'est une aide à la décision issue des sources, pas une exécution capturée ni un score de détecteur.
Interpréter un résultat d'export
Le traitement habituel d'une empreinte Canvas distingue dessin, lecture, condensat et comparaison ultérieure. Un échec d'export doit être classé avant d'interpréter une comparaison de condensats comme une comparaison d'images. Si un vérificateur remplace toute exception interceptée ou tout résultat vide par une valeur fausse unique, son affichage conserve moins d'informations que l'API. Après leur suppression, il ne peut retrouver le nom de l'exception, les dimensions matricielles ni le format demandé.
Le standard HTML définit toDataURL() comme une sérialisation de l'image matricielle Canvas. Le retour est normalement une URL de données contenant l'image encodée, mais la chaîne exacte data:, est aussi un résultat spécifié. Cette URL minimale représente une ressource textuelle vide. Elle ne contient ni signature PNG ni preuve qu'une image non vide a été encodée. La qualifier d'image blanche confond l'absence d'image encodée avec une image valide dont les pixels sont transparents.
| Entrée ou phase | Résultat de toDataURL() | Résultat de toBlob() | Ce que le résultat établit |
|---|---|---|---|
| Image matricielle non origin-clean | SecurityError synchrone | SecurityError synchrone | La condition de sécurité a échoué à l'export |
| Une dimension matricielle vaut zéro | data:, | Le rappel reçoit null | Aucune image n'a été sérialisée par ce chemin |
| La sérialisation ne fournit pas de fichier | data:, | Le rappel reçoit null | L'encodeur n'a fourni aucun fichier image |
| Type demandé non pris en charge, encodage réussi | URL de données PNG | Blob PNG | L'encodage de repli a réussi |
| Type demandé pris en charge, encodage réussi | URL de données d'image | Blob d'image | Une représentation encodée a été produite |
MDN ajoute un cas lié à l'implémentation : toDataURL() renvoie data:, lorsqu'une dimension dépasse la taille Canvas maximale. Ce maximum n'est pas une constante portable. Un enregistrement limité à la sentinelle ne distingue pas ce cas d'une dimension nulle ou d'un échec du sérialiseur. Les dimensions matricielles réelles et la phase d'export constituent les éléments suivants à recueillir, plutôt qu'un périphérique graphique supposé.
L'analyse du rapport Canvas BrowserLeaks suit un chemin particulier de PNG et de condensat. Son indicateur visible de compatibilité n'est pas un rapport complet d'exceptions. Les états d'export documentés distinguent des résultats qu'un tel indicateur peut regrouper ; ils ne prouvent pas que BrowserLeaks expose chacun d'eux ou conserve la raison initiale de l'échec.
Dimensions, propreté et ordre des exceptions
L'image matricielle Canvas et la boîte d'affichage CSS de l'élément sont deux objets distincts. Les attributs width et height contrôlent les dimensions matricielles ; CSS peut modifier l'échelle de présentation. Un grand rectangle sur une capture ne prouve pas qu'une grande image matricielle a été encodée. Inversement, un petit élément peut sérialiser beaucoup plus de pixels que sa boîte visible ne le suggère. Une comparaison limitée aux captures peut donc associer des entrées matricielles différentes comme s'il s'agissait d'un même cas de comparaison.
Une dimension nulle diffère également d'un dessin qui ne peint rien. Une image matricielle non nulle peut contenir des pixels transparents et être sérialisée en image. data:, concerne l'absence de pixels dans une dimension ou l'impossibilité d'obtenir un fichier sérialisé ; il ne mesure pas l'intérêt visuel du dessin. Cette distinction évite de regrouper incorrectement un Canvas transparent et un Canvas de taille nulle dans un rapport de compatibilité.
Le drapeau origin-clean est une autre entrée indépendante. Les deux algorithmes d'export le vérifient d'abord. S'il est faux, ils lèvent SecurityError avant les étapes ultérieures. L'ordre importe lorsqu'une autre propriété de l'image est aussi problématique : une exception de sécurité interceptée ne peut être requalifiée en sentinelle de dimension nulle. Une application qui n'enregistre que « Canvas indisponible » perd l'opération qui s'est réellement arrêtée.
MDN décrit cette condition de sécurité par une image dont le contenu provient ou peut provenir d'une autre origine. Ce n'est pas le diagnostic d'une requête d'image précise. L'exception ne révèle ni tout l'historique de dessin, ni la ressource concernée, ni les en-têtes présents dans la réponse. Les journaux d'une application sous contrôle peuvent examiner ces entrées ; un panneau public d'empreinte affichant une étiquette d'erreur ne peut les déduire de cette étiquette.
Modifier la présentation d'un élément ne prouve pas que son image matricielle soit devenue origin-clean. Les dimensions CSS et le drapeau de sécurité appartiennent à des parties différentes du modèle. De même, une URL d'image valide dans un document ne prouve pas, à elle seule, que l'image peut participer à une sortie Canvas lisible. Afficher une ressource et exporter les pixels qui en dérivent correspondent à des permissions et opérations distinctes. Il faut conserver l'exception d'export au lieu de prendre un affichage réussi pour une garantie d'export.
Les limites dimensionnelles demandent la même séparation. Un navigateur peut exposer les interfaces Canvas sans pouvoir exporter une image matricielle précise. Présence de la fonction, création du contexte, dessin et sérialisation sont des étapes différentes. Un échec à la dernière ne prouve pas l'absence des interfaces précédentes. Les algorithmes cités ne donnent pas de dimension maximale universelle : un rapport multiplateforme doit conserver les dimensions demandées sans transformer la limite d'un environnement en règle applicable à tous les navigateurs.
Formats demandés et travail de sérialisation
Le type MIME demandé est une entrée, pas une garantie sur la représentation produite. Les règles HTML imposent PNG et définissent un repli vers PNG lorsque le type demandé n'est pas pris en charge. Elles considèrent aussi comme non pris en charge un type contenant des paramètres. Un appelant qui attend JPEG ne peut conclure à son utilisation parce que la méthode renvoie une chaîne non vide. Le type de média de l'URL de données ou le type du Blob produit constitue l'information pertinente.
Cette distinction précède la comparaison des valeurs encodées. Deux exports peuvent représenter un dessin équivalent dans des formats différents, donc avec des octets différents. Même à format constant, un condensat d'octets encodés décrit ces octets ; il ne prouve pas que deux décodeurs afficheraient des pixels différents. Le traitement général d'une empreinte Canvas comprend dessin et lecture ; comparer des fichiers encodés ajoute des choix de sérialisation qui ne doivent pas être attribués silencieusement à la seule surface graphique.
L'argument facultatif quality s'applique aux formats avec compression avec perte. MDN décrit des nombres de 0 à 1 ; en cas d'omission ou de valeur hors de cet intervalle, l'agent utilisateur emploie sa qualité par défaut. Une valeur numérique hors intervalle ne définit pas une branche d'erreur de qualité distincte, même si dimensions, propreté d'origine ou sérialisation peuvent encore provoquer un échec. Un format sans réglage de qualité n'en acquiert pas parce qu'un argument est fourni. Demander une valeur ne prouve donc pas que PNG l'a utilisée ni que toutes les implémentations ont configuré leur encodeur à l'identique. Conserver type et qualité demandés séparément du type retourné évite de confondre entrée ignorée ou repli avec changement de rendu.
Les métadonnées de résolution ajoutent une autre limite. La documentation décrit des métadonnées de 96dpi pour les formats capables de les encoder. Ce sont des métadonnées de fichier, pas une mesure de l'écran physique ni de la taille CSS de l'élément. Une valeur dans l'image sérialisée ne doit pas devenir une observation de densité d'écran. Séparer dimensions matricielles, disposition CSS et métadonnées encodées permet de comparer l'entrée qui a réellement changé.
toDataURL() crée en mémoire une chaîne contenant toute l'image. MDN avertit des conséquences possibles sur les performances des grandes images et des limites de longueur d'URL lors d'une affectation à src. Cet avertissement n'établit pas qu'un export ou son affectation ultérieure ont effectivement échoué. Un rapport d'image absente après l'affectation d'une très grande URL doit distinguer export et opération consommatrice suivante : ne pas afficher cette URL ne prouve pas que la sérialisation ait renvoyé data:,.
toBlob() évite cette interface de chaîne de données, mais ne garantit ni réussite universelle ni absence de mémoire utilisée. Le standard décrit toujours une copie de l'image matricielle et son encodage. Son retour immédiat vaut undefined ; le résultat image arrive par un rappel. Qualifier ce retour immédiat d'« absence d'image » interprète mal le contrat, même si le rappel reçoit ensuite un Blob valide. Le null du rappel indique l'absence de ce résultat image ; un SecurityError synchrone intervient auparavant et suit un autre chemin.
Cas de comparaison pour les rapports d'empreinte
Deux enregistrements contiennent data:,, mais leurs dimensions diffèrent. L'un peut avoir une dimension nulle tandis que l'autre demande une taille non prise en charge ou atteint un échec d'encodage. L'égalité des chaînes prouve celle de la sentinelle, pas celle d'une empreinte rendue. Il faut conserver width et height avant de conclure à une cause commune. Sans ces entrées, le classement approprié est un export vide de cause non résolue, pas une signature de périphérique identique.
Un export produit du PNG après une demande JPEG. Le fichier réussi prouve que le chemin de repli a produit du PNG. Il ne prouve pas que l'encodeur JPEG ait traité la demande. Il faut comparer types demandés et réels avant de regrouper cet enregistrement avec des résultats JPEG. Une comparaison de condensats entre ces représentations répond à une question d'égalité de fichiers ; elle ne peut identifier seule une différence du dessin Canvas initial.
Un vérificateur remplace un condensat par une étiquette fausse générique. Le changement visible peut être en aval d'un échec d'export, mais l'étiquette ne désigne pas sa branche. Le code du vérificateur ou un enregistrement de l'application sous contrôle doit établir si une exception a été interceptée, une sentinelle rejetée ou une étape d'image ultérieure échouée. L'analyse BrowserLeaks distingue affichage et diagnostic complet ; la même limite empêche d'attribuer sans preuve une branche inconnue aux réglages de confidentialité.
Un journal toBlob() indique undefined, puis le rappel indique un fichier. Ces observations sont compatibles. Le retour immédiat n'est pas le résultat image asynchrone. Les résultats de rappels doivent être comparés entre eux, au lieu de comparer le retour immédiat d'une API à l'image finale d'une autre. La phase doit accompagner le nom de la méthode dans un ticket de compatibilité, notamment lorsque des journaux de plusieurs implémentations d'export sont réunis.
Un redimensionnement CSS semble réparer la page, mais les dimensions exportées restent identiques. L'affichage et l'image matricielle répondent à des questions différentes. Une modification de disposition peut améliorer la présentation sans modifier l'image fournie au sérialiseur. Si la question concerne l'élément visible, conserver les deux ensembles de dimensions ; si elle concerne la sérialisation, conserver uniquement les dimensions matricielles. Cela évite de décrire une correction visuelle comme une modification d'entrée d'empreinte lorsque cette entrée n'a pas changé.
Un export non origin-clean lève une exception avant de renvoyer un résultat vide. L'ordre fait partie des éléments observés. Une enveloppe qui transforme l'exception en faux doit enregistrer cette conversion : le lecteur ultérieur ne peut reconstruire l'exception synchrone à partir de faux. Aucun pixel brut n'est nécessaire pour conserver cette distinction ; méthode, phase et nom d'exception suffisent à la séparer du chemin de sentinelle spécifié.
Enregistrement de diagnostic minimal
Un enregistrement utile nomme method, les dimensions matricielles width et height, requestedType, actualType, outcome et phase. En cas d'échec synchrone, il peut conserver exceptionName au lieu des données de l'image. Pour toBlob(), il doit distinguer appel immédiat et fin du rappel. Ces champs décrivent opération et résultat sans conserver toute l'URL de données, l'image encodée ou le condensat. Un schéma définit les champs qu'une application peut retenir ; seul un enregistrement réel établit la branche exécutée.
| Champ | À conserver | Ne pas en déduire |
|---|---|---|
width, height | Dimensions matricielles fournies à l'export | Dimensions de l'écran physique |
requestedType, actualType | Représentation demandée et produite | Prise en charge de tous les encodeurs demandés |
phase | Appel, exception synchrone ou fin du rappel | Que undefined immédiat soit une image échouée |
outcome | Image, sentinelle, rappel null ou exception | Identité d'un périphérique ou verdict de manipulation |
exceptionName | Classe d'exception observée lorsqu'elle est disponible | Ressource responsable provenant d'une autre origine |
Si un rapport ne contient qu'une valeur fausse interceptée, conserver cette limite plutôt que remplir exceptionName par supposition. Une information indisponible diffère d'une exception observée. Il en va de même pour les dimensions : ne pas remplacer les dimensions matricielles manquantes par une boîte CSS mesurée plus tard. Les champs dérivés peuvent aider, mais nécessitent leurs propres étiquettes pour que l'enregistrement ne paraisse pas plus précis que ses éléments de preuve.
La documentation Canvas de BotBrowser décrit --bot-noise-canvas et --bot-noise-seed. Ces contrôles concernent la cohérence des pixels produits. Ils n'établissent ni la représentation d'un export précis ni le respect de la condition de sécurité par son image. La configuration de lancement doit rester séparée de l'état d'export ; des réglages identiques ne prouvent pas que toutes les entrées d'un test d'empreinte ultérieur soient restées identiques.
L'enregistrement minimal peut aussi omettre URL complètes de ressources, identifiants de compte et contenu d'images. Une révision du code ou une étiquette de compilation suffit souvent à identifier le chemin d'export prévu. Lorsqu'une ressource précise est nécessaire à une investigation sous contrôle, appliquer la politique de conservation de l'application plutôt que publier son URL ou ses pixels. L'intérêt diagnostique vient de la branche préservée, pas de l'accumulation d'une signature d'image réutilisable.
Questions fréquentes sur les états d'export Canvas
data:, est-il un PNG valide sans dessin visible ?
Non. Le standard décrit une ressource textuelle vide. Une image matricielle non nulle avec des pixels transparents est un autre état et peut être sérialisée en image. La sentinelle ne contient pas de PNG encodé à comparer.
data:, prouve-t-il le blocage d'une empreinte Canvas ?
Non. Des dimensions nulles et un échec de sérialisation peuvent produire ce résultat ; MDN documente aussi la limite de taille de l'implémentation. La chaîne seule n'établit ni un réglage de confidentialité ni l'interprétation du détecteur.
Un format non pris en charge peut-il renvoyer une image valide ?
Oui. Le repli PNG peut réussir lorsque le type demandé n'est pas pris en charge. Conserver la représentation réelle, sans considérer toute image non vide comme la confirmation du format demandé.
SecurityError identifie-t-il l'image responsable ?
Non. Il établit l'état non origin-clean de l'image matricielle à l'export. Il ne contient pas tout l'historique de dessin et n'établit ni la ressource responsable ni sa configuration de réponse.
Le undefined immédiat de toBlob() est-il une erreur ?
Non. C'est le retour documenté de la méthode. Le rappel reçoit le Blob d'image ou null ; une exception synchrone de sécurité est distincte du retour immédiat comme du rappel ultérieur.
Existe-t-il une taille Canvas maximale commune aux navigateurs ?
Les sources citées ne donnent pas de limite numérique portable. Enregistrer dimensions demandées et état d'export observé. Ne pas transformer le maximum d'un navigateur dans un environnement en limite partagée par toutes les implémentations.
Une URL de données identique établit-elle la même identité de navigateur ?
Non. L'égalité peut concerner une image encodée ou simplement la sentinelle vide. Aucune n'établit une personne, une configuration complète ou la décision d'un site. L'état d'export doit être connu avant même d'interpréter une comparaison de fichiers.
Une graine de bruit fixe explique-t-elle une erreur d'export ?
Pas à elle seule. Les contrôles de graine visent la cohérence des pixels ; les états documentés dépendent des dimensions, de la propreté d'origine, de la représentation et de la sérialisation. Une graine seule n'établit ni les conditions remplies ni la production d'une image exportée.
Sources
- WHATWG HTML : Canvas et sérialisation des images matricielles
- MDN : HTMLCanvasElement.toDataURL
- MDN : HTMLCanvasElement.toBlob
- Documentation Canvas de BotBrowser
Conclusion pratique
Classer l'export avant de comparer une empreinte Canvas. Distinguer data:,, SecurityError synchrone, rappel null, repli PNG et image réellement encodée. Conserver les dimensions matricielles et les représentations demandée et retournée ; omettre les images brutes lorsqu'elles ne sont pas nécessaires. Le traitement d'une empreinte Canvas et l'analyse BrowserLeaks couvrent les étapes distinctes qui suivent un export réussi.
Cet article fait partie du guide : Qu'est-ce qu'une empreinte de navigateur ?
Articles Connexes
Rapport Canvas de BrowserLeaks : signaux et limites
EmpreinteEmpreinte Canvas : fonctionnement et solutions
EmpreinteRapport WebGL de CreepJS : contextes et signaux
EmpreinteEmpreinte getClientRects : cohérence DOMRect
EmpreinteMode déterministe : empreintes reproductibles
EmpreinteMoteur de rendu WebGL absent : vie privée ou contexte ?
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.