Fingerprinting ecran et fenetre : suivi d'affichage
Comment la résolution d'écran, la profondeur de couleur et les dimensions de fenêtre créent des signaux d'empreinte uniques, et comment contrôler l'identité d'affichage.
Vous préférez la doc produit maintenue ?
Cet article a une page équivalente dans le centre de documentation. Utilisez les docs pour le flux canonique, les flags à jour et la référence durable.
Introduction
La configuration d'affichage de votre navigateur révèle beaucoup de choses sur votre appareil aux sites web. La résolution d'écran, la profondeur de couleur, le ratio de pixels de l'appareil, la zone d'écran disponible et les dimensions de fenêtre sont tous accessibles via les API JavaScript standard. Aucune permission n'est nécessaire. Ces valeurs varient selon les appareils et les configurations d'écran, en faisant des composants utiles d'une empreinte de navigateur. Un affichage 1920x1080 à 1x DPI est différent d'un affichage 2560x1600 à 2x DPI, qui est différent d'un affichage 3840x2160 à 1.5x. Combinées avec d'autres signaux, les propriétés d'affichage contribuent une entropie significative à une empreinte de suivi. Cet article explique comment fonctionne le fingerprinting écran et fenêtre et comment BotBrowser fournit une identité d'affichage contrôlée et cohérente via son système de profils.
Impact sur la confidentialité
Les propriétés d'affichage font partie du fingerprinting depuis les premiers scripts de suivi. Le projet Panopticlick de l'EFF a rapporté que la résolution d'écran seule fournit environ 4,8 bits d'entropie, assez pour distinguer environ 28 groupes. Combinée avec la profondeur de couleur, le ratio de pixels de l'appareil et la zone d'écran disponible (qui révèle la taille et la position de la barre des tâches), l'empreinte d'affichage combinée peut contribuer plus de 8 bits d'entropie.
La prolifération des écrans haute résolution, des écrans ultra-larges et des configurations multi-écrans a augmenté la diversité des affichages. Il y a dix ans, la plupart des utilisateurs de bureau avaient des écrans 1920x1080. Aujourd'hui, les résolutions courantes incluent 2560x1440, 3840x2160, 2560x1600 (MacBook), 2880x1800 et diverses configurations ultra-larges. Les appareils mobiles ajoutent encore plus de variété avec des résolutions et ratios de pixels spécifiques à chaque modèle.
Une technique particulièrement efficace combine la résolution d'écran avec les dimensions de fenêtre. La différence entre la taille de l'écran et la taille de la fenêtre révèle des informations sur le chrome de l'interface du système d'exploitation : hauteur de la barre des tâches, largeur du dock, décorations de fenêtre. Ces marges diffèrent entre Windows, macOS et Linux, et entre les versions de l'OS. Un écart de 40 pixels entre screen.height et screen.availHeight suggère Windows avec une barre des tâches en bas. Un écart de 25 pixels pourrait indiquer macOS avec un dock masqué.
Contexte technique
Propriétés d'écran
L'objet screen fournit les informations d'affichage :
screen.width/screen.height: la résolution d'écran complète en pixels CSS.screen.availWidth/screen.availHeight: la zone d'écran disponible pour les fenêtres de navigateur (moins les barres des tâches, docks, etc.).screen.colorDepth: la profondeur de couleur en bits par pixel. Quasi universellement 24 sur les systèmes modernes.screen.pixelDepth: généralement égal à colorDepth.
Propriétés de fenêtre
L'objet window expose les dimensions internes et externes :
window.innerWidth/window.innerHeight: les dimensions du viewport, excluant le chrome du navigateur.window.outerWidth/window.outerHeight: les dimensions totales de la fenêtre, incluant le chrome du navigateur (barre d'outils, onglets, barre de défilement).window.screenX/window.screenY: la position de la fenêtre sur l'écran.
Ratio de pixels de l'appareil
window.devicePixelRatio: le ratio entre pixels physiques et pixels CSS. Une valeur de 2 signifie que chaque pixel CSS correspond à une grille 2x2 de pixels physiques (courant sur les écrans Retina/HiDPI).
Media queries CSS
Les media queries fournissent un accès aux caractéristiques d'affichage depuis le CSS :
@media (min-resolution: 2dppx) { /* HiDPI styles */ }
@media (color-gamut: p3) { /* Wide color gamut display */ }
@media (prefers-color-scheme: dark) { /* Dark mode */ }
JavaScript peut les interroger via window.matchMedia(), fournissant un autre moyen de lire les propriétés d'affichage.
Pourquoi ces valeurs varient
Les propriétés d'affichage dépendent de plusieurs facteurs :
- Matériel de l'écran. La résolution physique, la taille et les capacités déterminent les valeurs de base.
- Paramètres d'affichage de l'OS. Les paramètres de mise à l'échelle (100 %, 125 %, 150 %, 200 %) affectent la relation entre pixels physiques et pixels CSS.
- Configuration multi-écrans. Plusieurs affichages avec des résolutions et mises à l'échelle différentes créent des configurations uniques.
- Etat de la fenêtre du navigateur. Maximisé, fenêtré ou plein écran affecte les dimensions internes/externes.
- Chrome du système d'exploitation. La taille et la position de la barre des tâches/dock affectent la zone d'écran disponible.
La combinaison de ces facteurs crée un signal à haute entropie. Un utilisateur avec un écran ultra-large 3440x1440 à 1.25x de mise à l'échelle, avec une barre des tâches Windows de 48 pixels, a une empreinte d'affichage très distinctive.
Approches de protection courantes et leurs limites
Les extensions de navigateur qui modifient les propriétés d'écran remplacent typiquement les getters JavaScript sur les objets screen et window. Cela a plusieurs problèmes. Les media queries CSS peuvent lire les vraies valeurs indépendamment de JavaScript. L'API visualViewport fournit une autre lecture des dimensions du viewport. Les getters remplacés peuvent être détectés via l'inspection de prototype et l'analyse de timing.
Utiliser une résolution courante (régler votre affichage sur 1920x1080) réduit l'unicité mais ne traite pas les dimensions de fenêtre, la zone d'écran disponible ou le ratio de pixels de l'appareil. Cela sacrifie aussi la qualité d'affichage sur les écrans HiDPI.
Randomiser les valeurs d'affichage crée des configurations physiquement impossibles. Une largeur d'écran de 1923 pixels ne correspond à aucun vrai écran. Un ratio de pixels de 1.37 ne correspond à aucun vrai paramètre de mise à l'échelle. Ces valeurs sont détectables comme synthétiques.
Exécuter dans une machine virtuelle avec des paramètres d'affichage contrôlés aide mais introduit des signaux spécifiques à la VM. Les pilotes d'affichage VM rapportent souvent des ensembles de capacités et des combinaisons de paramètres spécifiques qui identifient la plateforme de virtualisation.
Les modes de navigateur headless présentent leur propre défi. Le Chromium headless par défaut utilise un viewport 800x600 avec un ratio de pixels de 1, ce qui est une empreinte distinctive en soi car très peu de vrais utilisateurs naviguent à cette configuration.
Approche de BotBrowser au niveau du moteur
BotBrowser contrôle toutes les propriétés liées à l'affichage au niveau du moteur Chromium via son système de profils.
Profil d'affichage complet
Quand un profil d'empreinte est chargé, BotBrowser configure :
- Dimensions d'écran (
screen.width,screen.height,screen.availWidth,screen.availHeight) pour correspondre à l'appareil profilé. - Dimensions de fenêtre (
window.innerWidth,window.innerHeight,window.outerWidth,window.outerHeight) avec des marges de chrome OS réalistes dérivées du profil. - Ratio de pixels de l'appareil correspondant à la configuration d'affichage profilée.
- Profondeur de couleur et profondeur de pixel cohérentes avec l'appareil profilé.
Alignement des media queries CSS
BotBrowser garantit que les media queries CSS retournent des valeurs cohérentes avec les propriétés JavaScript. matchMedia('(min-width: 1920px)') correspond avec screen.width. matchMedia('(resolution: 2dppx)') correspond avec devicePixelRatio. Il n'y a pas d'écart entre les requêtes d'affichage basées sur CSS et celles basées sur JavaScript.
Simulation du chrome OS
La différence entre les dimensions externe et interne de la fenêtre, et entre la taille d'écran et la zone d'écran disponible, est dérivée du système d'exploitation cible du profil. Un profil Windows inclut des bordures et dimensions de barre des tâches typiques de Windows. Un profil macOS inclut des tailles de barre de menu et de décorations de fenêtre typiques de macOS.
Contrôle du mode headless
En mode headless, BotBrowser applique la configuration d'affichage du profil au lieu du 800x600 par défaut. Cela signifie que les sessions headless ont des propriétés d'affichage indistinguables des sessions avec interface avec le même profil.
Configuration et utilisation
Protection d'affichage de base
chrome --bot-profile="/path/to/profile.enc" \
--user-data-dir="$(mktemp -d)"
Configuration fenêtre et écran
# Use profile's window settings (default for headless)
chrome --bot-profile="/path/to/profile.enc" \
--bot-config-window=profile \
--bot-config-screen=profile
# Specify exact window size
chrome --bot-profile="/path/to/profile.enc" \
--bot-config-window=1920x1080
# Specify exact screen size
chrome --bot-profile="/path/to/profile.enc" \
--bot-config-screen=2560x1440
# Full JSON customization
chrome --bot-profile="/path/to/profile.enc" \
--bot-config-window='{"innerWidth":1920,"innerHeight":1080,"devicePixelRatio":2}'
# Use real system dimensions (default for desktop headful)
chrome --bot-profile="/path/to/profile.enc" \
--bot-config-window=real \
--bot-config-screen=real
Contrôle du schéma de couleurs
chrome --bot-profile="/path/to/profile.enc" \
--bot-config-color-scheme=light
Intégration Playwright
const { chromium } = require('playwright');
const browser = await chromium.launch({
executablePath: '/path/to/botbrowser/chrome',
args: [
'--bot-profile=/path/to/profile.enc',
'--bot-config-window=profile',
'--bot-config-screen=profile'
]
});
const page = await browser.newPage();
await page.goto('https://example.com');
const screenInfo = await page.evaluate(() => ({
screenWidth: screen.width,
screenHeight: screen.height,
innerWidth: window.innerWidth,
innerHeight: window.innerHeight,
devicePixelRatio: window.devicePixelRatio
}));
console.log(screenInfo);
Intégration Puppeteer
const puppeteer = require('puppeteer');
const browser = await puppeteer.launch({
executablePath: '/path/to/botbrowser/chrome',
defaultViewport: null, // Important: use profile dimensions
args: [
'--bot-profile=/path/to/profile.enc',
'--bot-config-window=profile',
'--bot-config-screen=profile'
]
});
const page = await browser.newPage();
await page.goto('https://example.com');
Notez le paramètre defaultViewport: null dans Puppeteer. Sans cela, Puppeteer remplace le viewport par ses propres valeurs par défaut, ce qui entrerait en conflit avec les paramètres d'affichage du profil.
Vérification
Vérification des propriétés d'écran. Interrogez screen.width, screen.height, screen.availWidth, screen.availHeight et screen.colorDepth. Toutes les valeurs doivent correspondre à l'appareil cible du profil.
Vérification des dimensions de fenêtre. Interrogez window.innerWidth, window.innerHeight, window.outerWidth, window.outerHeight. Les marges entre interne et externe doivent être réalistes pour l'OS profilé.
Vérification DPI. Vérifiez que window.devicePixelRatio correspond au profil. Vérifiez que les media queries CSS pour la résolution sont en accord.
Cohérence des media queries. Utilisez window.matchMedia() pour interroger les fonctionnalités média liées à l'affichage et confirmez qu'elles s'alignent avec les valeurs de propriétés JavaScript.
Bonnes pratiques
- Utilisez
defaultViewport: nulldans Puppeteer. Cela empêche Puppeteer de remplacer les paramètres d'affichage du profil. - Utilisez
--bot-config-window=profileen mode headless. Cela applique les dimensions de fenêtre du profil au lieu du viewport headless par défaut. - Faites correspondre le profil d'affichage au cas d'utilisation. Si votre IP proxy se situe dans une région où la navigation mobile est courante, envisagez d'utiliser un profil mobile avec des dimensions d'écran appropriées.
- Ne définissez pas de résolutions irréalistes. Des valeurs comme 1920x1080, 2560x1440 et 1440x900 sont courantes. Des valeurs comme 1919x1079 ne le sont pas.
- Tenez compte du ratio de pixels de l'appareil. Les profils haute résolution rapportent des résolutions physiques plus élevées avec un DPR de 2 ou 3. Assurez-vous que le DPR de votre profil est cohérent avec la taille d'écran rapportée.
FAQ
Q : BotBrowser gère-t-il la détection multi-écrans ? R : Les profils BotBrowser décrivent une configuration d'affichage unique. Les valeurs d'écran du profil représentent le moniteur principal tel que rapporté au contenu web. Le suivi du déplacement de fenêtre multi-écrans n'est pas exposé aux pages web par défaut.
Q : Que se passe-t-il si je redimensionne la fenêtre du navigateur avec un profil chargé ?
R : window.innerWidth et window.innerHeight se mettent à jour pour refléter la taille réelle de la fenêtre (en mode avec interface avec --bot-config-window=real). En mode headless ou avec --bot-config-window=profile, les valeurs restent contrôlées par le profil.
Q : Le paramètre de schéma de couleurs affecte-t-il le rendu ?
R : Oui. --bot-config-color-scheme=dark fait que prefers-color-scheme: dark est vrai dans les media queries CSS et matchMedia(). Les sites web qui implémentent le mode sombre s'afficheront en conséquence.
Q : L'empreinte d'écran est-elle la même en mode headless et avec interface ?
R : Lors de l'utilisation de --bot-config-window=profile et --bot-config-screen=profile, oui. Sans ces flags, le mode avec interface utilise par défaut les dimensions réelles de fenêtre/écran tandis que le headless utilise le profil.
Q : BotBrowser supporte-t-il les formats ultra-larges ou non standard ? R : Les profils BotBrowser peuvent inclure n'importe quelle configuration d'écran qui existe sur du vrai matériel. Si un profil a été capturé depuis un appareil avec un écran ultra-large, ces dimensions sont disponibles.
Q : Comment l'API visualViewport interagit-elle avec la protection de BotBrowser ?
R : L'API visualViewport retourne des valeurs cohérentes avec les dimensions de fenêtre contrôlées. Il n'y a pas d'écart entre window.innerWidth et visualViewport.width.
Résumé
Les propriétés d'écran et de fenêtre font partie des signaux d'empreinte les plus couramment collectés car elles ne nécessitent aucune permission et varient largement selon les configurations matérielles. BotBrowser contrôle toutes les valeurs liées à l'affichage au niveau du moteur, incluant les dimensions d'écran, les dimensions de fenêtre, le ratio de pixels de l'appareil, la profondeur de couleur et les media queries CSS. En chargeant un profil d'empreinte complet, tous les signaux d'affichage s'alignent avec une configuration d'appareil réelle, et les sessions headless produisent la même empreinte d'affichage que les sessions avec interface.
Pour les sujets associés, consultez Qu'est-ce que le fingerprinting de navigateur, Cohérence des signaux CSS, Protection des propriétés Navigator et Comportement déterministe du navigateur.
Articles Connexes
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.