Empreinte d'écran et de fenêtre : suivi de l'affichage

Les valeurs d'écran et de fenêtre sont sensibles pour la confidentialité : une page peut observer des conditions d'affichage sans demander une permission. Elles aident la mise en page et peuvent compléter une empreinte de navigateur. Une résolution, une taille de fenêtre ou un ratio de pixels décrit ce que le contexte expose maintenant. Cela ne prouve ni une personne, ni un système, ni un moniteur physique, ni un lieu. La position relève d'une permission distincte, décrite dans Permissions de géolocalisation et précision de position.

BotBrowser peut contrôler des valeurs d'affichage visibles au navigateur pour des tests autorisés, mais ne peut pas modifier le matériel ni l'état d'affichage du système hôte.

TL;DR

• screen.width décrit l'écran que le navigateur expose, tandis que window.innerWidth décrit la zone de mise en page occupée par le document ; aucune des deux, prise seule, n'identifie un moniteur ni une fenêtre.
• availWidth et availHeight diminuent quand une interface système, un dock ou une session distante réserve de l'espace, et l'ampleur de cet écart ne nomme pas le système qui le réserve.
• devicePixelRatio suit la mise à l'échelle de l'écran et le zoom de page, alors que visualViewport.scale suit le pincement ; les deux peuvent changer dans une même session sans aucun changement matériel.
• Dans une session headful de bureau, --bot-screen et --bot-window valent real par défaut ; fixez les deux à profile pour appliquer le profil chargé, ou passez des valeurs WxH ou JSON explicites.

Sommaire

• Voir la vidéo
• Écran et zone disponible
• Fenêtre, viewports et zoom
• Confidentialité et mise en page
• Validation limitée
• Capacité et limites de BotBrowser
• Conclusion pratique

Voir la vidéo

Cette vidéo en anglais explique de quelle surface d'affichage provient chaque valeur lue par une page, exécute un test local contrôlé où un cadre redimensionné tient lieu de fenêtre, et montre ce que ces valeurs déclarées prouvent ou non. Le test utilise une seule version du navigateur sur un seul hôte, sans profil BotBrowser ni zoom ; il montre comment les surfaces se rapportent entre elles, pas ce que sont un écran, un hôte ou une personne réels. La piste audio est en anglais.

Écran et zone disponible

Screen expose notamment width, height, availWidth, availHeight, colorDepth et pixelDepth. Le navigateur signale l'écran contenant la fenêtre en pixels CSS. La zone disponible peut exclure une interface système persistante. Ce sont des observations visibles au navigateur, non un inventaire matériel. Plusieurs écrans, la mise à l'échelle, la rotation, un dock, une session distante ou des réglages d'accessibilité peuvent changer ces valeurs. Une différence de zone disponible n'identifie pas un système ni un utilisateur.

Un pixel CSS n'est pas nécessairement un pixel physique. Les media queries décrivent des conditions de rendu, pas un numéro de série ; Fingerprinting CSS : comment les styles vous suivent explique comment ces fonctions de style servent au suivi. colorDepth et pixelDepth ne prouvent ni HDR, ni gamut complet, ni calibration.

Fenêtre, viewports et zoom

window.innerWidth et innerHeight décrivent le viewport de mise en page, y compris la barre verticale présente. outerWidth et outerHeight décrivent la limite de fenêtre exposée. Leur relation dépend de l'interface, des barres, de l'état de fenêtre et de la plateforme. Le viewport visuel est la partie actuellement visible ; il peut changer avec l'interface mobile, le clavier ou le pincement. visualViewport, lorsqu'il existe, décrit cet espace en pixels CSS.

Le zoom de page et le pincement sont distincts. Le premier peut changer l'échelle CSS et devicePixelRatio; le second modifie surtout le viewport visuel. Déplacer une fenêtre vers un écran avec une autre mise à l'échelle peut aussi modifier le ratio. Ces valeurs sont des conditions actuelles, pas une identité stable.

Confidentialité et mise en page

Une combinaison d'écran, zone disponible, viewport, zoom et ratio peut compléter d'autres observations, sans démontrer qui utilise le navigateur ni quel hôte fournit chaque valeur. Ne collectez que ce dont la mise en page ou le support a besoin. Un design réactif doit s'appuyer sur le viewport de mise en page, non sur l'écran entier : une fenêtre partagée peut être bien plus étroite que screen.width.

Séparez aussi la taille CSS d'une image de ses pixels bitmap. Une ressource plus dense peut améliorer la lisibilité, sans prouver un modèle d'écran. Conservez reflow, zoom et solution accessible. Un clavier ou un viewport visuel réduit exige de repositionner un contrôle, pas de collecter une nouvelle identité.

Validation limitée

Comparez des parcours équivalents et notez le mode headed ou headless, le viewport, le zoom et la disposition d'écrans. Testez redimensionnement, changement d'écran, rotation ou dock utile, zoom de page, pincement et interface mobile. Si une API manque, gardez le parcours ordinaire. Le résultat doit décrire un comportement visible, une inconnue et une action, sans classer la personne.

Un formulaire doit conserver libellés, focus et envoi quand une personne augmente le zoom. Un contrôle flottant doit respecter clavier et contenu visible. Redessiner un canvas après déplacement de fenêtre prouve la compatibilité de ce parcours, pas une configuration permanente.

Capacité et limites de BotBrowser

BotBrowser documente des contrôles fondés sur profil pour les informations d'écran et de fenêtre signalées aux pages. Ils peuvent soutenir une cohérence d'affichage dans des tests autorisés de confidentialité et de compatibilité. Ils ne modifient pas le matériel, les réglages système ni l'énumération hors processus. Un mode de fenêtre réel peut refléter redimensionnement et plusieurs écrans. Des valeurs headless contrôlées par profil ne garantissent pas la parité avec chaque navigateur headed. Vérifiez le profil et le runtime choisis.

Voir le ratio de pixels, la confidentialité inter-surfaces et l'empreinte des permissions.

Conclusion pratique

L'ordre de la revue décide si une observation d'affichage signifie quelque chose. Nommez d'abord la surface dont dépend la tâche (Screen, le viewport de mise en page, le viewport visuel ou devicePixelRatio), puis notez le mode du navigateur, l'état de la fenêtre et le niveau de zoom qui a produit la valeur. Une comparaison entre deux sessions n'est valable que si ces conditions concordent.

Pour le travail d'interface, décidez la mise en page à partir de window.innerWidth et placez les contrôles temporaires avec visualViewport, en gardant le document lisible quand cette API manque. Traitez availWidth et availHeight comme des contraintes sur l'espace accordé à une fenêtre, pas comme une description de la plateforme.

Dans un test BotBrowser autorisé, chargez le profil prévu, fixez --bot-screen=profile et --bot-window=profile ensemble dans une session headful, puis confirmez les valeurs annoncées sur les pages du parcours. Une valeur d'affichage explique ce que le contexte du navigateur a exposé à cet instant ; elle n'identifie ni l'hôte, ni le moniteur, ni la personne.

Sources

• BotBrowser : écran et fenêtre
• W3C CSSOM View Module
• MDN: Screen
• MDN: Window
• MDN: Window.devicePixelRatio
• MDN: VisualViewport