Fingerprinting DRM : ce que révèlent les requêtes EME et Widevine

Une page peut lire des signaux des Encrypted Media Extensions sans lancer aucune lecture : systèmes de clés, niveaux de robustesse, types de session et compatibilité des codecs. BotBrowser fait suivre ces réponses au profil chargé ; il ne fournit ni le CDM Widevine ni une licence, et ne garantit pas la lecture.

Résumé rapide

La surface DRM est un ensemble de réponses à navigator.requestMediaKeySystemAccess, pas une valeur unique. Interrogez Widevine et Clear Key avec les mêmes configurations à chaque exécution et comparez ce qui est résolu ou rejeté avec la plateforme du profil.

Sommaire de la guide

• Regarder la vidéo
• Ce que les Encrypted Media Extensions exposent à une page
• Les signaux DRM qu'un site peut lire sans demander
• Pourquoi les VPN, la navigation privée et les extensions ne changent pas ces réponses
• Où se situent les signaux DRM parmi les autres signaux de plateforme
• Comment vérifier les signaux DRM avec le profil choisi
• Ce que BotBrowser couvre et ce qui reste hors de son champ

Regarder la vidéo

Cette vidéo en anglais exécute une matrice fixe de seize questions DRM sur une page de laboratoire locale contrôlée, dans Google Chrome officiel, sur deux machines de test, Ubuntu et Windows. Aucun média n’est chargé et aucune licence n’est demandée. Dix réponses sont résolues, six sont refusées et les deux machines produisent le même condensé de table, 4753cab0 : la vidéo montre donc seulement comment les réponses s’articulent, et rien sur un utilisateur réel. Aucun profil BotBrowser ni proxy n’intervient. L’audio est en anglais.

Ce que les Encrypted Media Extensions exposent à une page

Encrypted Media Extensions, abrégé EME, est une spécification du W3C qui permet à une page web de coopérer avec un module de déchiffrement de contenu, ou CDM, pour lire de l'audio et de la vidéo protégés. Les services de streaming l'utilisent pour qu'un flux sous licence puisse être lu dans un onglet ordinaire, sans module externe. Le CDM le plus connu est Widevine, fourni avec Chrome et avec la plupart des navigateurs fondés sur Chromium. D'autres systèmes de clés existent pour d'autres plateformes, et l'un d'eux, Clear Key, est défini par la spécification elle-même afin que tout navigateur conforme puisse offrir une base commune. BotBrowser peut garder cohérentes les valeurs de capacité média d'un profil dans un contexte contrôlé ; il ne peut pas ajouter un système DRM ni un service de licences que la version et la plateforme ne fournissent pas.

Une page n'a pas besoin de lire quoi que ce soit pour connaître ce mécanisme. Avant de demander une licence, la page demande au navigateur s'il peut travailler avec un système de clés et un ensemble de configurations multimédias. Cette question fait partie de la lecture normale, et la réponse aide un lecteur de streaming à choisir entre plusieurs formes de contenu. La même question peut aussi être posée par un script qui n'a aucun lecteur, sans demande d'autorisation et sans aucun changement visible à l'écran.

L'appel central est navigator.requestMediaKeySystemAccess. Il reçoit le nom d'un système de clés et une liste de configurations demandées. Si le navigateur peut satisfaire au moins une configuration, la promesse est résolue avec un objet MediaKeySystemAccess. Sinon, la promesse est rejetée. Les deux issues apportent de l'information, et un script peut répéter l'appel avec de nombreuses configurations en quelques instants. L'appel n'est disponible que dans les contextes sécurisés, c'est-à-dire en pratique sur une page HTTPS ordinaire.

C'est pourquoi les données de capacités DRM ont leur place dans toute discussion sérieuse sur le fingerprinting du navigateur. Le résultat n'est pas un identifiant stable à lui seul. Beaucoup de personnes utilisent le même système d'exploitation et la même version de Chrome, et donneront les mêmes réponses. Ce que le résultat fournit, en revanche, c'est un ensemble de faits de plateforme et de matériel difficiles à lire par d'autres API, et cet ensemble s'ajoute à l'image qu'un site construit en combinant de nombreux signaux.

Les signaux DRM qu'un site peut lire sans demander

Plusieurs parties de la surface EME contribuent à ce qu'un script peut apprendre. Il est utile de les séparer, car chacune change pour des raisons différentes et demande sa propre vérification.

• Prise en charge des systèmes de clés. Widevine, Clear Key, PlayReady et FairPlay s'identifient chacun par une chaîne de système de clés. Ceux qu'un navigateur accepte dépendent fortement du système d'exploitation et de la version du navigateur. Un navigateur qui accepte un système de clés propre à une plateforme en dit long à la page sur l'endroit où il s'exécute.
• Niveaux de robustesse. Pour Widevine, une configuration demandée peut nommer un niveau de robustesse, comme le chiffrement logiciel, le décodage logiciel, le chiffrement matériel, le décodage matériel ou la protection matérielle complète. L'acceptation d'un niveau reflète la part de protection adossée au matériel qu'offrent l'appareil et le CDM.
• La matrice de codecs DRM. Les codecs qu'un système de clés accepte dans une configuration protégée ne sont pas toujours ceux que le navigateur déclare pour la lecture ordinaire. La combinaison de conteneur, de codec et de robustesse qui réussit forme son propre petit tableau.
• Types de session et types de données d'initialisation. Une configuration énumère les types de session qu'elle prend en charge et les formats de données d'initialisation qu'elle accepte, comme le format de chiffrement commun utilisé pour le contenu MP4. Les sessions temporaires et persistantes sont des capacités différentes.
• Objets de configuration. Lorsqu'une requête réussit, getConfiguration() renvoie la configuration que le navigateur a réellement acceptée. L'objet comprend les capacités acceptées ainsi que les exigences distinctiveIdentifier et persistentState. Des détails comme l'ordre et les champs exacts de cet objet peuvent varier d'une plateforme à l'autre.

Chacun de ces signaux est facile à interroger et peu coûteux à répéter. Un script peut demander des dizaines de combinaisons et noter lesquelles sont résolues. La référence MDN de requestMediaKeySystemAccess documente les paramètres et le comportement en cas de rejet, et la spécification du W3C définit le dictionnaire de configuration que renvoie une requête réussie.

Clear Key mérite une remarque à part. Comme la spécification le définit, tout navigateur conforme peut y répondre, ce qui en fait une base de référence et non un marqueur de plateforme. Sa valeur dans une vérification de cohérence est celle d'un témoin : si Clear Key est résolu normalement alors qu'un système de clés propre à une plateforme se comporte de façon étrange, le problème se situe dans la couche DRM et non dans la page ou le réseau. Les détails qu'il renvoie, comme les types de données d'initialisation pris en charge, peuvent encore différer légèrement selon les versions du navigateur.

Ce qui compte pour vous, c'est le mot silencieux. Aucune de ces requêtes n'affiche d'invite, aucune n'exige un geste de l'utilisateur et aucune ne laisse de trace visible. Une page peut les exécuter pendant son chargement. La spécification du W3C comprend des considérations de confidentialité sur la manière dont les capacités et les identifiants exposés peuvent aider à reconnaître un utilisateur, et c'est la même préoccupation qui motive ce sujet.

Il faut aussi être précis sur ce que ces signaux ne font pas. Les données de capacités DRM ne nomment pas une personne et ne distinguent pas, à elles seules, un appareil parmi des millions. Elles réduisent le champ. Un site qui les combine avec des signaux d'écran, de polices, d'audio, de codecs et de réseau obtient une image bien plus nette que celle de chacun pris séparément. C'est en ce sens que les requêtes DRM contribuent à l'identification, et c'est le seul sens dans lequel le terme est employé ici.

Pourquoi les VPN, la navigation privée et les extensions ne changent pas ces réponses

Répétez la même configuration requestMediaKeySystemAccess() avant et après le changement de route ; keySystem et robustness restent des entrées de capacité locale.

Les personnes soucieuses de leur vie privée pensent souvent d'abord à un VPN, à une fenêtre privée ou à une extension de navigateur. Ces trois outils sont raisonnables pour d'autres problèmes, et aucun ne touche les signaux décrits plus haut.

Un VPN modifie la route réseau et l'adresse IP visible. La requête de capacités EME n'utilise jamais le réseau. Elle interroge le navigateur, le navigateur interroge le CDM installé, et la réponse provient du logiciel et du matériel de la machine locale. Activer ou désactiver le VPN, ou changer de pays, ne modifie ni les systèmes de clés présents ni les niveaux de robustesse que l'appareil peut honorer.

Une fenêtre privée modifie la façon dont le navigateur conserve les cookies, l'historique et les données de site pendant une session. Elle n'installe ni ne retire de CDM et ne change pas le matériel. La prise en charge des systèmes de clés, les niveaux de robustesse et la matrice de codecs sont les mêmes dans une fenêtre privée que dans une fenêtre normale. La navigation privée protège bien contre la reconnaissance fondée sur les cookies, mais les données de capacités DRM ne sont pas un état stocké, donc il n'y a rien à effacer.

Les extensions sont l'option la plus tentante et la plus faible. Une extension qui bloque entièrement l'API casse aussi tous les services qui dépendent de la lecture protégée, et l'API manquante est en soi un choix visible et inhabituel. Une extension qui réécrit les valeurs renvoyées dans les scripts de la page doit garder chaque réponse cohérente avec toutes les autres, y compris les objets renvoyés par getConfiguration(), et elle ne peut ni ajouter ni retirer la prise en charge native du CDM. Un correctif de script de ce genre produit souvent un mélange qu'aucun vrai navigateur ne déclarerait, ce qui est plus distinctif que la réponse d'origine.

Pour la même raison, remplacer une seule valeur ne suffit pas. Une configuration qui affirme une protection adossée au matériel sur une plateforme qui n'en a pas, ou qui énumère un système de clés propre à un autre système d'exploitation, est incohérente en elle-même. La cohérence de l'ensemble des réponses compte plus que n'importe quelle réponse isolée, et cela vaut aussi pour les données de codecs. L'article associé sur le fingerprinting MIME et des codecs traite plus en détail le volet des codecs.

Une façon utile de retenir la répartition : les outils réseau changent l'endroit d'où une session semble venir, les contrôles de stockage changent ce qu'une session retient, et aucun ne change ce que la machine et la version du navigateur peuvent faire. Les données de capacités DRM décrivent ce que peuvent faire la machine et la version. Seul un changement de l'identité de plateforme déclarée par le navigateur, appliqué à toutes les surfaces ensemble, les déplace.

Où se situent les signaux DRM parmi les autres signaux de plateforme

Notez la version majeure à côté de chaque résultat de getConfiguration(), ainsi que persistentState et distinctiveIdentifier, afin de distinguer une mise à jour d’un changement de profil.

Un navigateur présente à la page un environnement cohérent, et les données DRM sont l'un des endroits où cet environnement peut cesser de l'être. La chaîne user agent, la chaîne de plateforme, les polices déclarées, la pile audio, le moteur de rendu WebGL et l'ensemble de capacités DRM décrivent la même machine. Lorsqu'ils décrivent des machines différentes, un site a une raison simple de traiter la session comme inhabituelle.

Prenons une session qui déclare une identité Windows de bureau mais s'exécute sur un hôte Linux. Si seules les chaînes visibles sont modifiées, la surface DRM peut encore refléter l'hôte. Les systèmes de clés, les niveaux de robustesse et les types de session peuvent suivre la plateforme de l'hôte alors que tout le reste indique Windows. La page n'a pas besoin d'être ingénieuse pour le remarquer. Il lui suffit de comparer deux réponses.

Le même raisonnement s'applique entre versions du navigateur. Widevine et le navigateur reçoivent des mises à jour, et l'ensemble des niveaux de robustesse et des codecs pris en charge peut évoluer avec elles. La version de navigateur déclarée et l'ensemble de capacités DRM déclaré doivent donc correspondre à la même période. Associer une identité de navigateur récente aux réponses DRM d'une ancienne version produit une autre incohérence facile à repérer.

L'audio est une comparaison utile. L'article sur le fingerprinting audio décrit comment la même routine donne des résultats différents sur des piles audio différentes. Le DRM fonctionne de façon semblable : la même question reçoit des réponses différentes sur des plateformes différentes, et les réponses sont stables sur une même plateforme. La stabilité est ce qui rend un signal utile pour la reconnaissance, et c'est aussi ce qui donne un sens à une vérification de cohérence.

C'est aussi pourquoi les données DRM doivent être traitées comme une partie de l'identité de plateforme et non comme un réglage séparé. Un profil qui décrit une plateforme doit décrire son comportement DRM comme l'une de ses parties. Modifier à la main des réponses de capacités isolées, une à une, laisse trop d'endroits où l'image peut se contredire.

Les plateformes mobiles ajoutent une couche supplémentaire. Un profil d'appareil Android décrit une plateforme où la protection adossée au matériel est courante, alors que de nombreux environnements de bureau et virtuels ne peuvent pas honorer les niveaux de robustesse les plus élevés. Une surface DRM qui affirme un décodage adossé au matériel sur un hôte qui n'en prend manifestement pas en charge est une incohérence qu'une seule requête révèle. Lorsque vous choisissez un profil, comparez sa plateforme avec le matériel sur lequel vous travaillez réellement et considérez tout écart important comme un point à vérifier plutôt qu'à supposer résolu de lui-même.

Comment vérifier les signaux DRM avec le profil choisi

La vérification commence par une liste écrite de ce qu'affirme le profil chargé. La plateforme, la version majeure du navigateur et l'origine du profil sont les trois faits dont dépendent toutes les vérifications suivantes. Une fois ceux-ci notés, la surface DRM peut être comparée à eux de façon répétable.

1. Nommez d'abord la plateforme du profil. Notez le système d'exploitation que décrit le profil et les systèmes de clés que vous attendez sur cette plateforme. Un système de clés propre à un autre système d'exploitation ne devrait pas apparaître, et un système de clés que tous les navigateurs de cette plateforme offrent ne devrait pas manquer.
2. Exécutez des requêtes de capacités pour chaque système de clés. Interrogez Widevine et Clear Key avec un petit ensemble de configurations et notez lesquelles sont résolues et lesquelles sont rejetées. Gardez les configurations identiques d'une exécution à l'autre pour que les différences de résultat soient de vraies différences.
3. Comparez les niveaux de robustesse. Demandez tour à tour chaque niveau de robustesse de Widevine et notez ceux qui sont acceptés. L'ensemble accepté doit correspondre au niveau matériel que décrit le profil et ne doit pas dépasser ce que cette plateforme peut plausiblement offrir.
4. Lisez les objets de configuration. Pour chaque requête réussie, lisez ce que renvoie getConfiguration() et notez les types de données d'initialisation, les capacités audio et vidéo, les types de session et les valeurs de distinctiveIdentifier et persistentState. Ils doivent ressembler à la sortie de la plateforme que décrit le profil.
5. Répétez après des rechargements et des redémarrages. Rechargez la page, fermez le navigateur, relancez-le avec le même profil et exécutez les mêmes requêtes. Les résultats doivent être identiques à chaque fois. Un résultat qui change d'une exécution à l'autre signale un problème de configuration et non une propriété de la plateforme.
6. Comparez les exécutions avec et sans interface. Si vous utilisez les deux modes, exécutez les mêmes requêtes dans chacun et comparez-les. Les différences méritent d'être étudiées, car un CDM présent dans un mode et absent dans l'autre est visible de toute page qui le demande.

Conservez les résultats dans un court tableau à côté du nom du profil. Lorsqu'une modification ultérieure du profil, de la version du navigateur ou de l'environnement de l'hôte change un résultat, le tableau montre quelle réponse a bougé. Relisez-le après chaque mise à jour du navigateur, car la surface DRM peut changer avec une nouvelle version.

Interprétez les échecs par catégorie. Un système de clés absent sur une plateforme où il devrait exister signifie généralement que le CDM n'a pas été installé ou n'a pas été trouvé. Un système de clés présent là où il ne devrait pas l'être indique un écart entre le profil et l'hôte. Un niveau de robustesse accepté lors d'une exécution et rejeté lors de la suivante suggère que l'environnement a changé entre les exécutions, par exemple avec une autre version du CDM ou un autre mode de lancement. Noter la catégorie d'un échec rend l'étape suivante évidente et raccourcit l'investigation.

Cette vérification compare uniquement les réponses DRM au profil. Elle ne teste pas si un service de streaming donné lira du contenu. La lecture dépend d'un CDM, d'un serveur de licences et de la politique du site, et rien de cela ne fait partie d'une comparaison de capacités. Un résultat propre ici signifie que les signaux sont cohérents, rien de plus.

Ce que BotBrowser couvre et ce qui reste hors de son champ

BotBrowser prend en charge le signalement des capacités DRM piloté par le profil, de sorte que les systèmes de clés EME, les niveaux de robustesse, les types de session et la prise en charge des codecs DRM qu'une page peut interroger sont signalés de façon cohérente avec l'identité de plateforme du profil chargé, et la documentation de BotBrowser sur le DRM indique qu'aucune option de CLI distincte n'est nécessaire pour cela. Vous disposez ainsi d'une base définie à vérifier avec les contrôles ci-dessus, sans modifier à la main des réponses isolées. BotBrowser ne peut pas fournir ni inclure le CDM Widevine, déchiffrer du contenu protégé, garantir la lecture ni l'approbation d'une licence, ni contrôler la politique DRM propre à un site et ses décisions de détection.

La lecture est une tâche distincte de la cohérence. Pour lire du contenu protégé, il faut un CDM Widevine obtenu par les canaux officiels et la licence qui l'accompagne, et rien de cela ne vient du navigateur. Le guide de configuration de Widevine DRM couvre la partie installation, et la documentation de BotBrowser sur la cohérence de l'empreinte DRM décrit comment le signalement des capacités suit le profil. Quand une session est refusée, le panorama des capacités DRM sépare les quatre vérifications qui décident si la cause est le module, un niveau de robustesse, le chemin de sortie ou la licence.

Gardez deux questions séparées lorsque vous préparez un test. La première est de savoir si la surface DRM correspond au profil, ce à quoi répond la liste ci-dessus. La seconde est de savoir si un service donné lit du contenu pour un compte donné, ce qui dépend du service. Une session peut réussir la première et échouer à la seconde pour des raisons sans rapport avec le navigateur.

Dans un plan de test, notez à quelle question chaque test répond et conservez les preuves de chacune séparément. Un rapport de cohérence énumère les systèmes de clés, les niveaux de robustesse, les champs de configuration et le nombre d'exécutions concordantes. Un rapport de lecture énumère le service, le type de compte et l'origine du CDM. Mélanger les deux rend difficile l'attribution des échecs à la bonne cause.

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

La page de référence nomme les surfaces EME. La comparaison ajoutée consigne séparément le système de clés, la robustesse, la configuration codec et la lecture. Un VPN, une fenêtre privée ou une extension ne transforme pas une réponse de licence en capacité du navigateur.

Sources publiques

• W3C : Encrypted Media Extensions
• MDN : Navigator.requestMediaKeySystemAccess()
• Documentation BotBrowser : cohérence de l'empreinte DRM
• Widevine dans les navigateurs automatisés

Conclusion pratique

Notez séparément quatre résultats : système de clés, robustesse, configuration des codecs et lecture. Que les trois premiers concordent avec le profil prouve la cohérence ; qu'un service lise le contenu dépend du CDM, de la licence et de la politique du site.