Retour au Centre de connaissances
Plateforme

Exécuter des profils de navigateur Windows sur macOS et Linux

Comment présenter un profil de navigateur Windows cohérent sur macOS ou Linux, en vérifiant aussi les limites de l'hôte, du réseau et de l'application.

BotBrowser Team

Documentation

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.

Un profil Windows sur un hôte macOS ou Linux doit être accompagné des signaux de navigateur propres à Windows. BotBrowser rapporte la plateforme et la région du profil ; il ne transforme pas l'hôte en machine Windows, et certaines valeurs dépendent toujours de lui.

Résumé rapide

Une substitution de User-Agent, une VM, Wine ou les commandes DevTools Protocol laissent des failles qu'un profil géré évite. Comparez la plateforme et la région rapportées par le profil avec les Client Hints de la requête, et notez les valeurs qui dépendent encore de l'hôte.

Sommaire de la guide

Introduction

Windows est une cible de bureau courante, mais les estimations varient selon la date, la région et la méthode. Sur Linux ou macOS, un profil Windows est utile lorsque le test couvre explicitement le comportement du navigateur Windows.

Les profils BotBrowser capturés depuis de vraies installations Windows contiennent des valeurs de plateforme visibles et documentées. Sur macOS ou Linux, ce sont des entrées à mesurer dans la session réelle ; l'hôte, l'affichage, les graphismes, le réseau et l'application peuvent encore modifier les observations.

Impact sur la vie privée : pourquoi les profils Windows sur des hôtes non-Windows

Vérifiez Win32 dans navigator.platform avant de comparer les hôtes.

L'argument de test est simple : choisissez le profil correspondant au comportement documenté que l'application doit prendre en charge. Ne choisissez pas un profil pour paraître ordinaire ni pour déduire quoi que ce soit d'un visiteur. Un hôte Linux peut exécuter un test avec profil Windows si le parcours est autorisé et si les limites de l'hôte, du réseau et de l'application sont consignées.

Pour les chercheurs en vie privée, la capacité de présenter une identité Windows depuis un hôte non-Windows permet des expériences contrôlées. Vous pouvez étudier comment les sites web adaptent leur comportement pour les utilisateurs Windows, tester la livraison de contenu spécifique à la plateforme et analyser les systèmes de pistage qui utilisent les signaux de plateforme, le tout sans maintenir une machine Windows.

Pour les tests de localisation ou de compatibilité, associez le profil à un proxy, un fuseau horaire et une locale choisis explicitement, puis vérifiez chaque entrée séparément. Ces paramètres décrivent un scénario de test et n'établissent ni identité régionale ni compatibilité universelle.

Contexte technique

Signaux de navigateur spécifiques à Windows

Une vraie session de navigateur Windows expose sa plateforme à travers de nombreux signaux :

Navigator et User-Agent : navigator.platform retourne "Win32" (même sur les systèmes 64 bits, pour la compatibilité). La chaîne User-Agent contient "Windows NT 10.0" pour Windows 10/11. navigator.userAgentData.platform retourne "Windows" avec la version de plateforme disponible via getHighEntropyValues().

Client Hints : l'en-tête HTTP Sec-CH-UA-Platform rapporte "Windows" à chaque requête. Sec-CH-UA-Platform-Version fournit la version spécifique de Windows (par ex. "15.0.0" pour Windows 11, "10.0.0" pour Windows 10).

Environnement de polices : Windows est livré avec des centaines de polices incluant Segoe UI (la police système), Calibri, Cambria, Consolas, Arial, Times New Roman, Verdana, Tahoma et bien d'autres. L'énumération des polices via CSS ou Canvas révèle cet ensemble spécifique.

Caractéristiques de rendu : Le texte peut varier selon la version du navigateur, les graphismes de l'hôte, les polices et l'affichage. Les observations Canvas doivent être mesurées sur chaque hôte pris en charge et ne constituent pas un identifiant garanti. Pour voir comment la mesure de texte transforme ces différences de polices et de rendu en signal sous-pixel, consultez Fingerprinting par mesure de texte : suivi sous-pixel, qui explique ce que measureText() expose et où s’appliquent les limites du profil.

Métriques d'écran : les résolutions d'écran courantes sous Windows (1920x1080, 1366x768, 2560x1440) et les valeurs de devicePixelRatio (typiquement 1.0 ou 1.25) diffèrent de macOS (où les écrans Retina ont couramment un DPR de 2.0) et de Linux (qui varie largement).

Chrome de fenêtre : les dimensions des décorations de fenêtre du navigateur (hauteur de la barre de titre, largeur de la barre de défilement, bordure de fenêtre) diffèrent entre les systèmes d'exploitation. Les calculs outerWidth - innerWidth et outerHeight - innerHeight révèlent ces dimensions.

Pourquoi l'usurpation simple échoue

Changer la chaîne User-Agent pour rapporter Windows ne change pas l'environnement de polices, la sortie de rendu, les métriques d'écran, les dimensions du chrome de fenêtre ni les Client Hints. Un navigateur qui prétend être Windows mais rend le texte avec les caractéristiques de FreeType et rapporte les polices Linux présente des signaux contradictoires. Ces incohérences sont faciles à identifier par l'analyse inter-signaux.

Approches courantes et leurs limites

Substitutions de User-Agent

Les frameworks comme Playwright et Puppeteer permettent de définir des chaînes User-Agent personnalisées. Cela change l'en-tête HTTP et navigator.userAgent mais laisse tous les autres signaux inchangés. navigator.platform, les listes de polices, la sortie de rendu et les Client Hints continuent tous de refléter le vrai système d'exploitation hôte.

VM Windows sur Linux

Exécuter Windows dans une machine virtuelle sur un serveur Linux fournit de véritables signaux Windows, mais le coût en ressources est élevé. Chaque VM nécessite 4-8 Go de RAM, des coeurs CPU dédiés et une licence Windows. À grande échelle, cette approche est prohibitivement coûteuse comparée à l'émulation basée sur les profils.

Wine ou couches de compatibilité

Exécuter Chrome Windows via Wine sur Linux produit un environnement de signaux mixtes. Certains signaux reflètent Windows, d'autres reflètent le système Linux sous-jacent. Le résultat est un ensemble d'incohérences qui est pire que d'exécuter l'une ou l'autre plateforme nativement.

Substitutions via DevTools Protocol

Le Chrome DevTools Protocol permet de substituer le User-Agent et certaines propriétés de plateforme. Cependant, ces substitutions sont appliquées après l'initialisation du navigateur et n'affectent pas le pipeline de rendu, le système de polices ou les premiers en-têtes HTTP comme les Client Hints lors de la navigation initiale.

L'approche de BotBrowser

Les profils BotBrowser capturés depuis des systèmes Windows contiennent des valeurs de navigateur Windows documentées dans un seul package. Charger un profil Windows applique ces valeurs au démarrage du navigateur ; cela ne transforme pas l'hôte en Windows.

Ce qu'un profil Windows contrôle

Lorsque vous chargez un profil Windows 11 Chrome sur un serveur Linux :

  • navigator.platform retourne "Win32"
  • navigator.userAgent contient "Windows NT 10.0; Win64; x64"
  • L'en-tête Sec-CH-UA-Platform rapporte "Windows"
  • Sec-CH-UA-Platform-Version rapporte la version Windows capturée
  • La disponibilité des polices peut être comparée au profil capturé dans la session réelle, selon l'hôte, la version, les permissions et le chemin de rendu
  • Le résultat des polices doit être comparé au profil capturé, selon l'hôte et la version
  • Le résultat Canvas doit être mesuré, sans supposer qu'il correspond au rendu source
  • WebGL dépend du chemin graphique de l'hôte sauf indication documentée
  • Les métriques d'écran reflètent le viewport et l'affichage de la session
  • Les dimensions de fenêtre doivent être vérifiées avec le framework et l'hôte choisis

Aucune configuration requise

Charger un profil sur un autre hôte n'établit pas automatiquement une équivalence. Le flag --bot-profile est une entrée de lancement ; vérifiez ensuite la session, l'affichage, le framework, le réseau et l'application sur chaque hôte pris en charge. Pour comparer hôtes, profils et coût d’exécution avant le déploiement avec une méthode au niveau du déploiement, consultez Évaluer la cohérence du navigateur avant le déploiement, qui couvre la matrice d’hôtes et de cibles ainsi qu’une base de référence versionnée.

Association avec Edge ou Brave

Les utilisateurs Windows utilisent couramment Microsoft Edge ou Google Chrome. BotBrowser peut exposer des valeurs documentées de marque, de locale et de fuseau horaire uniquement dans des contextes autorisés couverts par le profil et les fonctionnalités souscrites ; vérifiez-les dans la session. Pour un test Edge pris en charge :

chrome --bot-profile="profiles/win11-edge.enc" \
       --bot-browser-brand=edge

Les valeurs de marque documentées peuvent changer, notamment les marques User-Agent, les tokens Client Hints et les fonctions ; vérifiez-les dans la session sans en déduire une garantie universelle. Pour comprendre pourquoi User-Agent, Client Hints et navigator.userAgentData doivent s’accorder sur une seule marque, consultez Changement de marque : Chrome, Edge, Brave, Opera, qui explique comment définir la marque au lancement et la vérifier partout.

Configuration et utilisation

Profil Windows de base sur Linux

# Sur un serveur Linux
DISPLAY=:88 chrome \
  --bot-profile="profiles/win11-chrome-130.enc" \
  --user-data-dir="$(mktemp -d)"

Profil Windows avec identité US

DISPLAY=:88 chrome \
  --bot-profile="profiles/win11-chrome-130.enc" \
  --proxy-server=socks5://user:pass@us-proxy:1080 \
  --bot-timezone=America/New_York \
  --bot-locale=en-US \
  --bot-languages=en-US,en

Exemple Puppeteer

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: [
      '--bot-profile=profiles/win11-chrome-130.enc',
      '--bot-timezone=America/Chicago',
      '--bot-locale=en-US',
      '--bot-languages=en-US,en',
    ],
    headless: true,
    defaultViewport: null,
  });

  console.log('Ouvrez une page de test autorisée avec ces options.');
  await browser.close();
})();

Edge sur Linux avec proxy EU

DISPLAY=:88 chrome \
  --bot-profile="profiles/win11-edge.enc" \
  --bot-browser-brand=edge \
  --proxy-server=socks5://user:pass@de-proxy:1080 \
  --bot-timezone=Europe/Berlin \
  --bot-locale=de-DE \
  --bot-languages=de-DE,de,en

Vérification

Vérifiez que le profil Windows est appliqué correctement en vérifiant plusieurs catégories de signaux :

const verification = {
  platform: 'Win32',
  userAgent: '...Windows NT 10.0; Win64; x64...',
  uaPlatform: 'Windows',
  platformVersion: '15.0.0',
};
console.log('Comparez ces valeurs attendues avec la même session autorisée.');

Un profil de navigateur Windows relie des hôtes macOS et Linux à une identité cohérente

Liste opérationnelle

Séparez l'hôte d'exécution du profil du navigateur. Notez le système, la version du navigateur, l'identifiant du profil, la locale, le fuseau horaire, le proxy, le viewport et la date de chaque vérification.

Traitez le profil comme une entrée d'un contexte contrôlé. Utilisez un répertoire de données neuf, des données synthétiques et une fermeture déterministe. Le profil fournit des valeurs visibles par le navigateur ; les cookies, le stockage, les permissions, le réseau et les données applicatives suivent le cycle de vie du contexte et du service.

Vérifiez le chemin réseau avant de comparer les signaux. Confirmez le DNS, l'authentification du proxy, TLS, la région et la réponse du service. Une valeur Sec-CH-UA-Platform correcte ne prouve pas que l'adresse IP ou le service amont sont Windows.

Contrôlez les langues, les formats, le décalage horaire et le sélecteur de locale de l'application, avec la locale et le fuseau horaire déclarés séparément.

Gardez la politique de viewport et d'affichage stable. Sur Linux, configurez le service d'affichage ; sur macOS, tenez compte de l'échelle Retina. Comparez les dimensions CSS et le device-pixel ratio avec les valeurs du profil.

Utilisez une courte liste : plateforme, famille User-Agent, Client Hints, polices pertinentes, métriques d'écran et locale visible. Un résultat positif est une preuve de cette session, pas une promesse universelle.

Définissez le cycle de vie et le nettoyage. Créez un contexte par compte autorisé, ne partagez pas le stockage mutable entre workers et conservez la première erreur. Fermer le contexte n'efface pas les données du serveur.

Figez les versions de votre matrice et répétez la liste après chaque mise à jour. Comparez les hôtes en documentant les différences de GPU, chemins, affichage et réseau. BotBrowser convient aux valeurs visibles répétables, mais n'est ni une VM Windows ni un remplacement du proxy, des polices, du matériel graphique ou de la validation applicative.

Attribuez chaque observation à un responsable : profil, plateforme, réseau ou application. Une valeur visible par le navigateur ne prouve pas un fait que le profil ne contrôle pas.

Documentez les variations attendues avant une comparaison. Un worker Linux peut utiliser un affichage virtuel tandis qu'un portable macOS utilise l'échelle Retina. Notez les plages acceptables du viewport et comparez séparément les valeurs de plateforme.

Quand le profil n'est plus nécessaire, appliquez la politique de conservation. Supprimez uniquement les artefacts locaux autorisés, révoquez les identifiants de test et conservez un résultat minimal. Le fichier n'est ni une licence Windows ni une sauvegarde de la machine source.

Bonnes pratiques

  • Choisissez des profils couverts par la matrice actuelle. Les profils anciens peuvent ne pas correspondre à la version de Chrome utilisée.
  • Choisissez le proxy et la locale pour le test. Notez la région et le fuseau prévus, puis vérifiez la réponse réseau séparément des valeurs du profil.
  • Utilisez l'affichage du projet seulement si nécessaire. Les nouveaux runs headless n'ont pas besoin de DISPLAY; les runs headed ou headless=old avec Xvfb doivent utiliser DISPLAY=:88.
  • Utilisez defaultViewport: null dans Playwright et Puppeteer pour laisser le profil contrôler les dimensions du viewport plutôt que le framework.
  • Déclarez les paramètres régionaux. Un profil Windows sans valeurs correspondantes est incomplet. Définissez --bot-timezone, --bot-locale et --bot-languages pour correspondre à l'emplacement du proxy.
  • Envisagez Edge pour la couverture. Utilisez --bot-browser-brand=edge lorsque le test inclut Edge et vérifiez la marque et les fonctions dans la session.

Questions fréquentes

L'hôte Linux se révèle-t-il quelque part lors de l'exécution d'un profil Windows ?

Non. BotBrowser applique les valeurs documentées du profil dans le navigateur. Ces valeurs ne révèlent pas Linux, mais l'hôte, le réseau et le comportement de l'application doivent être vérifiés séparément.

Puis-je exécuter les profils Windows actuels ?

Oui. Les profils Windows 11 rapportent la version de plateforme appropriée dans les Client Hints. La distinction entre Windows 10 et 11 est principalement dans la valeur Sec-CH-UA-Platform-Version, qui est capturée depuis le système source.

Comparez cette valeur au registre du profil ; elle ne prouve pas que l'hôte est Windows.

Ai-je besoin des polices Windows installées sur mon serveur Linux ?

Comparez la disponibilité des polices au profil capturé dans la session réelle. Les polices de l'hôte, la version, les permissions et le chemin de rendu peuvent modifier le résultat ; le profil ne garantit pas un jeu fixe quel que soit l'hôte.

Comment fonctionne la résolution d'écran avec les profils Windows ?

Le profil peut fournir des métriques attendues, mais le viewport, l'échelle d'affichage, le framework et le matériel doivent être mesurés dans la session. Ne supposez pas que l'écran hôte est masqué ni qu'une résolution est garantie.

Puis-je utiliser le même fichier de profil sur différents systèmes d'exploitation hôtes ?

Le même fichier .enc peut être chargé sur Linux, macOS et Windows, mais le résultat doit être vérifié selon l'hôte et la version du navigateur. Le profil fournit des entrées visibles par le navigateur et ne détermine pas toutes les conditions de l'hôte.

Qu'en est-il des API spécifiques à Windows comme WMI ou DirectX ?

Les navigateurs web exposent un ensemble limité d'API de plateforme via les API web standard. BotBrowser documente les valeurs de profil pour les signaux visibles pris en charge ; les API système comme WMI ne sont pas accessibles au contenu web et le comportement dépendant de l'hôte reste hors du profil.

Y a-t-il une différence de performance lors de l'exécution de profils Windows sur Linux ?

Non. Le profil contrôle quels signaux le navigateur rapporte. Le calcul réel s'exécute toujours sur le matériel hôte à vitesse native.

Résumé

BotBrowser prend en charge des valeurs de plateforme visibles par le navigateur dans des contextes contrôlés pour des tests multiplateformes autorisés. Le profil ne fournit pas un système d'exploitation Windows et ne garantit pas des résultats identiques sur tous les hôtes ; le réseau, la région, les polices, les graphismes et l'application restent à valider par l'équipe.

La limite pratique est simple : le profil fournit des valeurs initiales visibles par le navigateur, tandis que l'équipe reste responsable du proxy, du DNS, des permissions, du viewport, du cycle de vie du framework et des assertions applicatives. Notez l'hôte et l'identifiant du profil puis répétez la même liste après chaque mise à jour.

BotBrowser peut configurer des valeurs de plateforme visibles par le navigateur pour des tests multiplateformes autorisés, mais ne fournit pas un système d'exploitation Windows et ne garantit pas des résultats identiques sur tous les hôtes. La validation du réseau, de la région, des polices, des graphismes et de l'application reste à la charge de l'équipe. Consultez la documentation d'identité BotBrowser.

Pour les sujets connexes, voir Profils de navigateur multiplateformes, Émulation Android et Changement de marque du navigateur. Consultez aussi MDN User-Agent Client Hints.

Ce que cette page ajoute à la référence

La page de référence explique l'utilisation d'un profil sur plusieurs hôtes. Le scénario ajouté compare la plate-forme et la région du profil aux Client Hints de la requête, puis consigne les valeurs qui restent liées à l'hôte. Le déploiement Linux ou macOS devient vérifiable sans le présenter comme une machine Windows.

{ "reported": "Win32", "request": "Sec-CH-UA-Platform", "hostDependent": ["screen.width", "devicePixelRatio"] }

Sources

Conclusion pratique

Examinez Linux ou macOS sans prétendre qu'il s'agit d'une machine Windows : ce que rapporte le profil doit concorder avec les Client Hints de la requête. Documentez les valeurs qui dépendent de l'hôte au lieu de les traiter comme des défauts du profil.

#Windows#Macos#Linux#multi-plateforme#profils

Cet article fait partie du guide : Surfaces de la plateforme web : carte de revue

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.