Fingerprinting WebGPU : la nouvelle génération de pistage GPU

Cet article porte sur ce que WebGPU expose à une page : les informations de l'adaptateur, l'ensemble de fonctionnalités et les limites de capacité. BotBrowser rapporte ces valeurs depuis le profil chargé ; un rapport du profil ne prouve pas que le GPU de l'hôte a exécuté la même charge.

Résumé rapide

Comparez la disponibilité de l'adaptateur, les noms des fonctionnalités et les limites dans les modes profil, réel et désactivé, et vérifiez WebGL séparément. Un adaptateur nul est attendu en mode désactivé ; en mode profil ou réel, il impose de vérifier l'hôte et les permissions.

Sommaire de la guide

• Regarder la vidéo
• Introduction
• Impact sur la vie privée
• Pourquoi cela concerne votre vie privée
• Approches de protection courantes et leurs limites
• L'approche de BotBrowser avec le profil chargé
• Configuration et utilisation
• Vérification

BotBrowser documente des modes WebGPU sélectionnables pour des tests contrôlés; il ne garantit pas la disponibilité, le masquage de tout signal ou l'identification matérielle.

Regarder la vidéo

Cette vidéo en anglais montre ce qu'une page apprend de navigator.gpu.requestAdapter() avant qu'aucun shader ne s'exécute. Une page de laboratoire locale déclare trois rapports d'adaptateur, dont un sans aucun adaptateur, et le même appel lit chacun. La même page lit ensuite le rapport du navigateur lui-même dans Google Chrome 155 officiel sous Windows, qui liste un adaptateur et dix-huit fonctionnalités, et dans Chrome 154 sous Ubuntu, où l'appel renvoie null. Le test n'a été exécuté qu'une fois et la cause n'a pas été vérifiée : il montre donc que les rapports peuvent différer, et rien sur un autre système. Aucun profil BotBrowser n'intervient. L'audio est en anglais.

Introduction

WebGPU est le successeur de WebGL, fournissant un accès moderne et de bas niveau au matériel GPU pour les charges de travail de rendu et de calcul. À mesure que les navigateurs adoptent WebGPU, une nouvelle surface de fingerprinting est introduite dont les utilisateurs soucieux de leur vie privée doivent être conscients. L'API expose les informations de l'adaptateur GPU incluant le fournisseur, l'architecture, la description de l'appareil, l'ensemble de fonctionnalités et les limites de capacité détaillées. Ces informations sont plus riches et plus structurées que ce que WebGL fournit, ce qui en fait une préoccupation croissante pour quiconque valorise sa vie privée en ligne. Dans un contexte contrôlé, BotBrowser peut garder les informations de l’adaptateur, les fonctionnalités et les limites WebGPU cohérentes avec un profil chargé ; il ne peut pas faire se comporter un matériel GPU ou un WebGPU non pris en charge comme un autre appareil.

Pour les chercheurs en vie privée, les ingénieurs d'automatisation et toute personne préoccupée par le fingerprinting de navigateur, WebGPU représente une nouvelle source significative de fuite d'identité de l'appareil.

Impact sur la vie privée

WebGPU est une API relativement nouvelle (disponible dans Chrome depuis la version 113), mais ses implications pour le fingerprinting sont déjà significatives. Bien que la spécification WebGPU ait été conçue avec certaines considérations de confidentialité, y compris des informations d'adaptateur à résolution réduite par défaut, la combinaison des signaux disponibles fournit toujours une entropie significative qui peut être utilisée pour le pistage.

Dans une comparaison, consignez Chrome 113, vendor, architecture et maxTextureDimension2D ; ce sont des champs observables, pas une identité matérielle.

Les informations GPU exposées par WebGPU incluent les champs vendeur, architecture et appareil. Bien que ceux-ci soient intentionnellement moins détaillés que les chaînes brutes de renderer de WebGL, ils distinguent toujours les familles de GPU. Différents fournisseurs GPU, les GPU intégrés versus dédiés, et les différentes architectures produisent tous des valeurs distinctes qui réduisent la configuration de votre appareil. Pour savoir ce que représente un adaptateur et quand il peut être indisponible, consultez Informations de l’adaptateur WebGPU et vie privée, qui couvre les limites de disponibilité et les solutions de repli respectueuses de la vie privée.

Au-delà des informations de base de l'adaptateur, WebGPU expose un ensemble détaillé de limites de capacité : dimensions maximales de texture, tailles maximales de buffer, tailles maximales de workgroup de calcul, et des dizaines d'autres. Ces limites varient entre les fournisseurs GPU, les architectures et les versions de pilotes. La combinaison de ces valeurs de limites crée une empreinte de capacité GPU qui est souvent plus granulaire que les informations de l'adaptateur elles-mêmes.

Les premières recherches des équipes de confidentialité des navigateurs ont noté que les valeurs de limites de WebGPU peuvent distinguer les générations spécifiques de GPU au sein de la même famille de fournisseurs. Deux GPU du même fabricant mais de lignes de produits différentes rapportent des limites différentes, même s'ils partagent le même identifiant de fournisseur. Ce niveau de granularité est préoccupant pour la vie privée car il réduit l'identification à des modèles de matériel spécifiques.

Importance croissante

À mesure que l'adoption de WebGPU augmente, particulièrement pour l'inférence IA, la visualisation avancée, les jeux et les applications créatives, l'API deviendra standard dans les navigateurs modernes. Cela signifie que le fingerprinting WebGPU deviendra plus courant, et l'absence de WebGPU pourrait elle-même devenir un signal distinctif. Une protection proactive est essentielle.

Pourquoi cela concerne votre vie privée

Exposition de l'identité GPU

Votre GPU est l'un des composants matériels les plus distinctifs de votre ordinateur. La combinaison du fournisseur, de l'architecture et des limites de capacité crée une empreinte matérielle difficile à modifier et persistante entre les sessions de navigation. WebGPU rend ces informations directement interrogeables par n'importe quel site web, sans demande de permission ni notification utilisateur.

Corrélation inter-API

Une préoccupation critique pour la vie privée est la corrélation entre WebGPU et WebGL. Les deux API accèdent au même GPU. Si l'identité GPU rapportée par une API ne correspond pas à l'autre, ou si les profils de capacité sont incohérents entre les deux API, l'incohérence elle-même devient un signal de pistage fort. Les sites web qui interrogent les deux API peuvent détecter les incohérences, c'est pourquoi toute approche de protection doit traiter les deux API ensemble. Pour voir comment WebGL expose la même identité GPU et ce que signifie la cohérence du profil dans ce cas, consultez Fingerprinting WebGL : controler l'identite GPU, qui couvre les familles de signaux WebGL et les approches de protection courantes.

Ensemble de fonctionnalités comme empreinte

L'ensemble des fonctionnalités GPU disponibles via WebGPU (comme les formats de compression de texture, le clipping de profondeur, les requêtes d'horodatage et les capacités de shaders) varie entre les modèles GPU et les versions de pilotes. La combinaison spécifique de fonctionnalités supportées agit comme une dimension de fingerprinting supplémentaire qui complète les informations de l'adaptateur et les limites de capacité.

Variations de la sortie de rendu

Comme WebGL, le rendu WebGPU produit une sortie spécifique au GPU. Les compute shaders, les pipelines de rendu et les opérations de texture produisent tous des résultats qui varient au niveau numérique entre les architectures GPU. Bien que la spécification de WebGPU soit plus stricte sur la précision que celle de WebGL, des différences d'implémentation existent toujours et peuvent être utilisées pour le fingerprinting. Pour confirmer ces signaux de rendu entre le rendu logiciel et le rendu matériel, consultez Valider la confidentialité selon le backend de rendu, qui couvre une matrice de rendu pour valider Canvas, WebGL et WebGPU.

Approches de protection courantes et leurs limites

Désactiver WebGPU est actuellement la protection la plus simple. Comme WebGPU est relativement nouveau, la plupart du contenu web ne le nécessite pas. Cependant, à mesure que l'adoption augmente, le désactiver deviendra de plus en plus impraticable. L'absence de WebGPU deviendra aussi un signal distinctif à mesure que l'API deviendra standard, rendant potentiellement votre navigateur plus identifiable plutôt que moins.

Bloquer des méthodes API individuelles ne traite qu'une partie de l'empreinte. L'ensemble de fonctionnalités et les limites de capacité restent disponibles et fournissent une entropie significative par eux-mêmes. La protection partielle est souvent pire que pas de protection car elle crée des incohérences.

La modification au niveau JavaScript des informations de l'adaptateur change le fournisseur et l'architecture rapportés mais ne change pas les limites de capacité réelles ni le comportement de rendu. Un site web qui vérifie à la fois les informations de l'adaptateur et les limites peut détecter l'incohérence immédiatement. Les approches superficielles créent de nouveaux signaux de détection plutôt que d'en supprimer.

Standardiser les limites (rapporter les valeurs minimales requises pour toutes les limites) réduirait la surface d'empreinte mais pourrait casser les applications WebGPU qui dépendent de capacités plus élevées, dégradant l'expérience utilisateur.

L'approche efficace nécessite de contrôler les informations de l'adaptateur, les fonctionnalités, les limites et le comportement de rendu depuis une source unique et cohérente. C'est exactement ce que BotBrowser fournit.

L'approche de BotBrowser avec le profil chargé

BotBrowser expose le comportement WebGPU au moyen d'options de lancement associées au profil. Elles décrivent ce qu'une page peut observer dans une version prise en charge ; elles n'ajoutent pas une capacité absente de l'hôte et ne garantissent pas qu'une application acceptera le résultat.

Contrôle complet des informations de l'adaptateur

Lorsqu'un profil est chargé, les informations de l'adaptateur correspondent au GPU profilé sur tous les champs : fournisseur, architecture, identifiant de l'appareil et description. Ces valeurs correspondent à une configuration GPU réelle capturée depuis un vrai appareil. Il n'y a pas de valeurs synthétiques ou génériques qui pourraient indiquer que l'identité a été modifiée.

Contrôle de l'ensemble de fonctionnalités

L'ensemble de fonctionnalités rapporté par l'adaptateur WebGPU correspond exactement au GPU profilé. Seules les fonctionnalités supportées par le GPU profilé sont listées, et toutes les fonctionnalités que le GPU profilé supporte sont présentes. Cela garantit que l'ensemble de fonctionnalités est cohérent avec les informations de l'adaptateur, les limites de capacité et le comportement de rendu.

Contrôle des limites de capacité

Toutes les valeurs de limites de capacité sont dérivées du profil. Les dimensions maximales de texture, tailles de buffer, tailles de workgroup de calcul et toutes les autres limites correspondent aux capacités réelles du GPU profilé. Ce ne sont pas des valeurs minimales par défaut. Elles correspondent au modèle GPU spécifique dans le profil, reflétant les caractéristiques matérielles réelles.

Cohérence WebGL-WebGPU

BotBrowser garantit que l'identité GPU rapportée par WebGPU est cohérente avec ce que WebGL rapporte. Les deux API indiquent le même fournisseur GPU, et les profils de capacité sont compatibles. Cette cohérence inter-API élimine un vecteur de détection majeur qui affecte les autres approches de protection.

Contrôle de la sortie de rendu

Combiné avec --bot-noise-seed, la sortie de rendu WebGPU devient déterministe et cohérente avec l'appareil profilé. Les résultats des compute shaders et la sortie du pipeline de rendu reflètent le comportement numérique du GPU profilé, fournissant une protection contre le fingerprinting basé sur le rendu.

Configuration et utilisation

Protection WebGPU de base

La protection WebGPU est automatique lors du chargement d'un profil :

chrome --bot-profile="path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

Options de configuration WebGPU

BotBrowser vous donne un contrôle explicite sur le comportement WebGPU via le flag --bot-webgpu :

# Utiliser les paramètres WebGPU du profil (par défaut, recommandé)
chrome --bot-profile="path/to/profile.enc" \
       --bot-webgpu=profile

# Utiliser le vrai GPU du système (quand vous avez besoin des performances GPU réelles)
chrome --bot-profile="path/to/profile.enc" \
       --bot-webgpu=real

# Désactiver entièrement WebGPU (supprime la surface de fingerprinting)
chrome --bot-profile="path/to/profile.enc" \
       --bot-webgpu=disabled

Configuration combinée WebGL et WebGPU

Pour la protection d'empreinte la plus forte, configurez les deux API GPU ensemble :

# Les deux API utilisent les données du profil (recommandé pour la cohérence)
chrome --bot-profile="path/to/profile.enc" \
       --bot-webgl=profile \
       --bot-webgpu=profile \
       --bot-noise-seed=42

Cela garantit une cohérence complète de l'identité GPU à travers les deux API, avec une sortie de rendu déterministe via la graine de bruit.

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-webgpu=profile', '--bot-noise-seed=42'],
});

const page = await browser.newPage();
await page.goto('https://example.com');

// Vérifier que l'identité WebGPU correspond au profil
const gpuInfo = await page.evaluate(async () => {
  if (!navigator.gpu) return 'WebGPU not available';
  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) return 'No adapter';
  const info = await adapter.requestAdapterInfo();
  return {
    vendor: info.vendor,
    architecture: info.architecture,
    device: info.device,
    features: [...adapter.features],
    maxTexture2D: adapter.limits.maxTextureDimension2D,
  };
});
console.log('WebGPU identity:', gpuInfo);

Intégration Puppeteer

const puppeteer = require('puppeteer');

const browser = await puppeteer.launch({
  executablePath: 'path/to/botbrowser/chrome',
  defaultViewport: null,
  args: ['--bot-profile=path/to/profile.enc', '--bot-webgpu=profile'],
});

const page = await browser.newPage();
await page.goto('https://example.com');

// Votre identité WebGPU est maintenant protégée par le profil

Vérification

Après le lancement de BotBrowser avec un profil, vérifiez votre protection WebGPU :

Vérification des informations de l'adaptateur. Vérifiez que le fournisseur, l'architecture et l'appareil correspondent au GPU cible du profil. Ils devraient refléter l'appareil profilé, pas votre matériel réel.

Vérification de l'ensemble de fonctionnalités. Confirmez que les fonctionnalités listées correspondent aux fonctionnalités attendues pour le GPU profilé. L'ensemble devrait être complet et précis.

Vérification des limites. Vérifiez plusieurs valeurs de limites et confirmez qu'elles correspondent aux capacités du GPU profilé. Les valeurs devraient être spécifiques au modèle GPU dans le profil, pas des minimums génériques.

Cohérence WebGL-WebGPU. Comparez le fournisseur GPU rapporté par WebGL avec le fournisseur rapporté par WebGPU. Ils devraient indiquer la même famille GPU, garantissant la cohérence inter-API.

Stabilité inter-sessions. Exécutez les mêmes requêtes WebGPU sur plusieurs sessions avec le même profil. Toutes les valeurs devraient être identiques à chaque fois, démontrant que votre empreinte GPU est stable et reproductible.

Bonnes pratiques

• Gardez les paramètres WebGL et WebGPU alignés. Les deux API exposent l'identité GPU. Utilisez --bot-webgl=profile et --bot-webgpu=profile ensemble pour garantir la cohérence inter-API. Des identités GPU incohérentes entre les deux API sont un signal de pistage fort.

• Utilisez des profils avec des données WebGPU. Tous les profils n'incluent pas les informations WebGPU (les profils plus anciens peuvent précéder WebGPU). Utilisez des profils actuels qui incluent les données d'adaptateur WebGPU pour garantir une protection complète.

• Envisagez de désactiver WebGPU si non nécessaire. Si votre cas d'usage ne nécessite pas WebGPU, --bot-webgpu=disabled supprime entièrement la surface de fingerprinting. C'est un choix valide tant que l'adoption de WebGPU est encore en croissance, bien que cela puisse devenir moins viable à mesure que l'API deviendra standard.

• Combinez avec --bot-noise-seed pour la sortie de rendu. Les informations de l'adaptateur et les limites sont déterministes depuis le profil. La sortie de rendu a aussi besoin de la graine de bruit pour le déterminisme. Utiliser les deux ensemble fournit la protection la plus complète de l'empreinte GPU.

• Testez la disponibilité de WebGPU. Certains profils peuvent ne pas supporter WebGPU (correspondant aux appareils où WebGPU n'est pas disponible). Vérifiez que votre profil inclut les données WebGPU si votre application en a besoin.

FAQ

Q : WebGPU est-il disponible dans tous les navigateurs ? R : Début 2026, WebGPU est disponible dans Chrome/Edge (depuis la version 113), Firefox (derrière un flag dans certaines versions) et Safari (support partiel). La disponibilité varie selon la plateforme. Les profils BotBrowser spécifient si WebGPU devrait être disponible en fonction de l'appareil profilé, vous donnant une représentation précise des configurations de navigateur réelles.

Q : Comment le fingerprinting WebGPU se compare-t-il au fingerprinting WebGL ? R : WebGPU fournit des informations d'adaptateur plus structurées et des limites de capacité plus détaillées, tandis que WebGL fournit des chaînes de renderer brutes et des empreintes basées sur le rendu. Les deux API sont importantes pour une protection complète des empreintes GPU. BotBrowser protège les deux via son système de profils, garantissant que votre identité GPU est cohérente à travers toutes les API graphiques.

Q : Puis-je utiliser WebGPU pour les charges de travail de calcul avec BotBrowser ? R : Oui. Le contrôle WebGPU de BotBrowser opère au niveau du rapport d'identité et de capacité. L'exécution de calcul réelle utilise votre matériel GPU réel pour la performance. Vous obtenez la pleine performance GPU pour vos charges de travail tout en maintenant une identité d'empreinte protégée.

Q : Et si mon profil n'inclut pas de données WebGPU ? R : Si le profil n'inclut pas de données WebGPU et que --bot-webgpu=profile est défini, WebGPU peut ne pas être disponible (correspondant à un appareil où WebGPU n'est pas supporté). Utilisez un profil plus récent qui inclut les données WebGPU si vous avez besoin de l'accès WebGPU.

Q : Désactiver WebGPU affecte-t-il WebGL ? R : Non. WebGL et WebGPU sont des API indépendantes. Désactiver WebGPU n'affecte pas la fonctionnalité WebGL. Chacune est contrôlée par son propre flag --bot-*, vous donnant un contrôle granulaire sur votre empreinte GPU.

Q : Les résultats des compute shaders WebGPU sont-ils affectés par la graine de bruit ? R : Lorsque --bot-noise-seed est défini, la sortie de rendu et de calcul qui pourrait être utilisée pour le fingerprinting inclut une variation déterministe. Les charges de travail de calcul normales qui ne touchent pas les surfaces sensibles au fingerprinting ne sont pas affectées. Vos charges de travail de calcul scientifique ou IA restent précises tandis que votre empreinte est protégée.

Résumé

WebGPU introduit une surface d'observation GPU détaillée via les informations de l'adaptateur, les fonctionnalités, les limites et la sortie de rendu. Le flag --bot-webgpu sélectionne le comportement documenté de profil, réel ou désactivé dans les versions prises en charge. Comparez les valeurs renvoyées avec WebGL et la charge de l'application, et considérez le résultat comme une observation bornée de compatibilité et de confidentialité, non comme une preuve du matériel physique ou d'un alignement universel.

Pour les sujets connexes, voir What is Browser Fingerprinting, WebGL Fingerprint Protection, Canvas Fingerprinting, et Deterministic Browser Behavior.

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

La page de référence liste les modes WebGPU. La matrice ajoutée compare la disponibilité de l'adaptateur, les fonctions et les limites en modes profil, réel et désactivé, puis vérifie WebGL séparément. Elle conserve aussi le premier champ qui change entre deux essais.

Chaque ligne fixe mode, adapter et firstChangedField afin que la comparaison de versions soit vérifiable.

Pour un essai reproductible, conservez le mode, l'identifiant du profil, le build, le résultat de la requête d'adaptateur, les noms de fonctionnalités et les limites reçues par la page. Exécutez deux fois le même scénario sans changer l'hôte, puis répétez-le en ne changeant que le mode. Un adaptateur nul en mode désactivé est attendu ; en mode profil ou réel, vérifiez l'hôte et les permissions avant d'y voir un résultat de confidentialité.

Lorsqu'une application graphique échoue, décidez d'abord si elle exige WebGPU ou si elle peut utiliser un repli WebGL. Comparez ensuite l'adaptateur, les fonctionnalités et les limites enregistrés avec l'erreur de l'application et les journaux de l'hôte. Cela sépare une décision de compatibilité d'une affirmation sur un GPU physique ou sur le classement d'un site.

Le rapport minimal comporte une ligne par mode, avec la même origine et les mêmes options de requête. Indiquez si la promesse d'adaptateur s'est résolue, sa classe, le nombre de fonctionnalités et les limites utiles. Si une valeur change, gardez les deux lignes et notez le premier champ différent.

Pour un passage de relais, joignez l'origine, les options de requête, le profil, la version, la classe de l'hôte et la ligne exacte qui a changé. Gardez un second essai avec l'hôte inchangé comme contrôle ; l'observation aide ainsi la compatibilité sans devenir une affirmation sur une personne ou un appareil physique.

Conclusion pratique

En cas d'échec, gardez le repli WebGL, vérifiez les permissions et notez le premier champ modifié (firstChangedField) avant de conclure à un changement de compatibilité.

Sources publiques

• Reference
• Reference