Retour au Centre de connaissances
Empreinte

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

Documentation

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 SecurityError synchrone ; 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 est undefined, tandis que le rappel reçoit un Blob ou null. L'exception de sécurité reste synchrone.

Sommaire

Les résultats Canvas séparent SecurityError synchrone, data:, ou un rappel null, et un repli PNG réussi.

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 phaseRésultat de toDataURL()Résultat de toBlob()Ce que le résultat établit
Image matricielle non origin-cleanSecurityError synchroneSecurityError synchroneLa condition de sécurité a échoué à l'export
Une dimension matricielle vaut zérodata:,Le rappel reçoit nullAucune image n'a été sérialisée par ce chemin
La sérialisation ne fournit pas de fichierdata:,Le rappel reçoit nullL'encodeur n'a fourni aucun fichier image
Type demandé non pris en charge, encodage réussiURL de données PNGBlob PNGL'encodage de repli a réussi
Type demandé pris en charge, encodage réussiURL de données d'imageBlob d'imageUne 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À conserverNe pas en déduire
width, heightDimensions matricielles fournies à l'exportDimensions de l'écran physique
requestedType, actualTypeReprésentation demandée et produitePrise en charge de tous les encodeurs demandés
phaseAppel, exception synchrone ou fin du rappelQue undefined immédiat soit une image échouée
outcomeImage, sentinelle, rappel null ou exceptionIdentité d'un périphérique ou verdict de manipulation
exceptionNameClasse d'exception observée lorsqu'elle est disponibleRessource 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

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.

#Canvas#fingerprinting#confidentialité

Cet article fait partie du guide : Qu'est-ce qu'une empreinte de navigateur ?

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.