Contrôles DRM : système de clés, robustesse, sortie

Le média chiffré échoue pour quatre raisons différentes, et une équipe qui demande seulement si le DRM fonctionne ne peut pas les distinguer. Cette vue d’ensemble ordonne les quatre points de contrôle d’une revue de capacité DRM et renvoie au cluster qui traite chacun : la négociation du module, la robustesse négociée, la sortie protégée et la décision de licence.

BotBrowser peut garder un profil déclaré et sa politique média par contexte cohérents dans un contexte autorisé lorsque la compilation et l’habilitation le permettent. Il ne peut pas fabriquer un module de déchiffrement de contenu, passer outre la décision de compte d’un fournisseur, ni promettre qu’un titre précis se lise sur n’importe quel hôte.

TL;DR

• Posez une seule question par point de contrôle. Un rejet à l’étape d’accès et un rejet à l’étape de licence sont deux échecs différents avec des responsables différents, et présenter l’un ou l’autre comme « le DRM échoue » envoie le ticket à la mauvaise équipe.
• Consignez la chaîne de robustesse acceptée (SW_SECURE_DECODE, HW_SECURE_ALL) au lieu de la convertir en oui ou non.
• Traitez headless et headed comme des modes de présentation. Un écran virtuel n’est pas un niveau de sécurité plus bas, et un moniteur physique ne prouve pas une voie matérielle sécurisée.
• Gardez le code de statut du fournisseur dans son propre champ. C’est une décision de politique sur un compte et un titre, pas une capacité du navigateur.

Sommaire

• Quatre points de contrôle derrière une seule question
• Nommer d’abord la limite du module
• Lire la robustesse comme une plage, pas comme un verdict
• Garder la protection de sortie à part du mode de présentation
• Décider qui possède la réponse de licence
• Consigner un tableau par version

Quatre points de contrôle derrière une seule question

Les quatre points de contrôle sont séquentiels, et chacun répond à une question différente sur la même session. Les confondre est la raison la plus fréquente pour laquelle une enquête DRM s’enlise, parce que la recherche d’une cause démarre dans la mauvaise couche et n’atteint jamais celle qui a réellement échoué.

Le premier point de contrôle est de savoir si le navigateur négociera le système de clés. Le deuxième est le niveau de robustesse qu’il accepte. Le troisième est de savoir si la voie de sortie peut transporter des images protégées. Le quatrième est de savoir si le serveur de licences accorde une clé pour ce compte, cette région et ce titre.

L’ordre compte pour le diagnostic, pas seulement pour la propreté. Un rejet au premier point arrête la chaîne, donc rien en aval n’a été testé. Une réussite au premier point et un rejet au quatrième prouvent que le côté navigateur a négocié avec succès et que la décision vient du fournisseur. Ces deux résultats désignent des responsables différents, et un ticket de support qui dit seulement « le DRM ne fonctionne pas » ne peut pas les distinguer.

Point de contrôle	Appel ou événement du navigateur	Valeur à consigner
1 Accès	requestMediaKeySystemAccess()	supported ou NotSupportedError
2 Robustesse	getConfiguration() après une requête	chaîne de robustesse acceptée
3 Sortie	keystatuseschange sur la session	usable, output-restricted, expired
4 Licence	réponse HTTP du message de licence	code de statut et catégorie d’erreur du fournisseur

Chaque ligne est une expérience distincte avec sa propre catégorie d’échec. Un relecteur qui les garde séparées peut nommer la première ligne qui a cassé et la remettre à l’équipe responsable, au lieu de rouvrir toute la configuration.

Chaque ligne a aussi une limite qu’il vaut la peine d’énoncer à côté de la valeur. Une réussite au point un prouve que le navigateur négociera le système de clés ; elle ne prouve pas qu’une clé peut être déchiffrée ni qu’un titre se lira. Une réussite au point deux prouve que le module a accepté un niveau ; elle ne prouve pas que la voie d’affichage peut transporter des images protégées. Un statut usable au point trois prouve que les clés ont été remises à la session ; il ne prouve pas que le fournisseur a autorisé le compte. Un HTTP 200 au point quatre prouve qu’une réponse de licence est arrivée ; il ne prouve pas que la requête suivante, un autre titre ou une autre région réussiront. Écrire ces limites dans le dossier est ce qui empêche une chaîne de quatre réussites d’être lue comme une garantie de lecture.

Nommer d’abord la limite du module

Le module est l’entrée dont tout le reste dépend, et dans un lancement automatisé il est souvent absent sans aucune erreur qui le mentionne. Un navigateur sans module rejette toute configuration pour le système de clés, donc la sonde signale un échec de capacité qui ressemble à un problème de configuration et qui est en réalité un problème de conditionnement.

Deux faits sur le module méritent d’être énoncés explicitement dans un dossier de revue. Premièrement, le binaire compte avant les arguments : une compilation Chromium open source ne fournit généralement pas le module Widevine, alors qu’une compilation Google Chrome le fournit. Une suite qui lance une compilation Chromium intégrée est susceptible de signaler une absence de prise en charge quels que soient les arguments passés, et la correction est de lancer une compilation qui peut porter un module.

Deuxièmement, les valeurs par défaut d’un framework d’automatisation peuvent désactiver le composant qui rend le module disponible. Un lancement Playwright par défaut inclut --disable-component-update, ce qui est un choix sensé pour un runner qui ne veut pas de trafic réseau en arrière-plan, et cela signifie aussi qu’un profil fraîchement créé dans cet environnement a signalé une absence de prise en charge de Widevine dans une mesure publiée dans le cluster. La même sonde, avec ce seul argument retiré, a signalé SW_SECURE_CRYPTO et SW_SECURE_DECODE comme pris en charge sur la même machine, en mode headless comme en mode headed. La mesure a exécuté une compilation Google Chrome installée, pas un Chromium intégré, donc elle ne dit rien sur une compilation qui ne fournit aucun module.

Cette mesure se lit comme une méthode plutôt que comme une règle universelle. Elle isole un argument, ne change rien d’autre et compare la même sonde avant et après. Le système de composants de Chrome appartient à Chrome, donc une autre version ou un autre système d’exploitation peut se comporter différemment, et la partie reproductible est la comparaison et non le résultat précis.

Pour cette revue, la conséquence est une règle de placement plutôt qu’un fait sur Chrome : un module absent n’atteint jamais le premier point de contrôle, donc il doit être consigné dans le champ de compilation de l’en-tête, pas comme une ligne en échec. Un tableau qui affiche un NotSupportedError rouge sur la première ligne face à une compilation Chromium intégrée décrit l’en-tête, et un lecteur qui ne voit jamais l’en-tête le lira comme un problème de module ou de fournisseur.

Deux lancements expriment la comparaison, et le second est le seul qui diffère :

const base = { executablePath: '/opt/google/chrome/chrome', headless: true };
await chromium.launch(base); // valeurs par défaut du framework, --disable-component-update inclus
await chromium.launch({ ...base, ignoreDefaultArgs: ['--disable-component-update'] }); // le seul changement

Consignez si le profil était neuf ou persistant à côté du résultat. Un profil temporaire répète l’enregistrement de première exécution à chaque lancement, et un résultat venant d’un profil de bureau de longue durée n’est pas une preuve sur un conteneur de CI qui crée un nouveau répertoire par tâche. Comparez ce qui est comparable.

La moitié de la sonde qui s’exécute dans la page est assez courte pour être conservée à côté du dossier. Exécutez-la via page.evaluate après chaque lancement ci-dessus ; elle demande une configuration, affiche quels systèmes de clés se résolvent et ne tente jamais la lecture :

const config = [
  {
    initDataTypes: ['cenc'],
    videoCapabilities: [{ contentType: 'video/mp4; codecs="avc1.42E01E"', robustness: 'SW_SECURE_DECODE' }],
  },
];
for (const keySystem of ['com.widevine.alpha', 'org.w3.clearkey']) {
  try {
    const access = await navigator.requestMediaKeySystemAccess(keySystem, config);
    const c = access.getConfiguration();
    console.log(keySystem, 'supported', c.videoCapabilities[0].robustness, c.persistentState);
  } catch (error) {
    console.log(keySystem, error.name);
  }
}

Clear Key dans cette boucle est un témoin, pas un marqueur de plateforme. La spécification le définit, donc tout navigateur conforme répond pour lui, et son rôle ici est de séparer un problème de page ou de réseau d’un problème de DRM. Si Clear Key se résout normalement alors que le système de clés de la plateforme rejette toute configuration, la couche CDM est l’endroit à examiner et la page ne l’est pas.

Lire la robustesse comme une plage, pas comme un verdict

Une fois le système de clés négocié, le navigateur et le module s’accordent sur un niveau de robustesse. Les chaînes sont le vocabulaire qu’un fournisseur utilise pour décider de ce qu’il servira : SW_SECURE_CRYPTO et SW_SECURE_DECODE gardent le travail cryptographique ou le décodage en logiciel, et HW_SECURE_ALL exige une voie matérielle de confiance. Widevine appelle niveau 3 le cas purement logiciel, et les niveaux supérieurs dépendent d’un matériel que l’hôte peut ne pas avoir.

Un niveau matériel rejeté n’est pas un défaut de la configuration. Beaucoup d’environnements de bureau et virtuels n’ont pas de voie matérielle sécurisée, et un fournisseur qui sert du contenu ordinaire à des niveaux logiciels y fonctionne. Le dossier utile contient donc la chaîne réellement acceptée, avec la configuration demandée, parce que ce couple est ce dont un relecteur ultérieur a besoin pour voir que la réponse a bougé.

Deux habitudes rendent cette ligne fiable. Répétez la configuration identique d’une exécution à l’autre, pour qu’une différence dans la sortie soit une vraie différence et non une question différente. Et lisez l’objet de configuration renvoyé au lieu de supposer que la requête a été accordée telle qu’écrite. Empreinte DRM énumère les champs que porte cet objet et ce que chacun révèle de la plateforme, donc ce hub ne les répète pas.

Une configuration H.264 réussie est une cellule d’une matrice, pas la matrice, et Empreinte DRM explique comment cette matrice se lit. Ce qui compte à ce point de contrôle est plus étroit : consignez la cellule demandée et la cellule qui a répondu, parce qu’un fournisseur qui sert une résolution plus basse à un niveau plus bas prend une décision de politique qui n’apparaît ici que comme un niveau accepté.

Garder la protection de sortie à part du mode de présentation

La lecture peut commencer puis s’arrêter lorsque la voie d’affichage ne satisfait pas une exigence de sortie protégée. La session signale cet état via keystatuseschange, souvent comme output-restricted, et l’application est censée afficher une solution de repli plutôt qu’une défaillance opaque. Ce point de contrôle concerne la voie d’affichage, et il est indépendant du fait que le système de clés ait négocié.

L’erreur fréquente est de fondre cette ligne dans headless contre headed. Headless est un mode de présentation, pas un niveau de sécurité. Un écran virtuel peut satisfaire ou manquer une exigence de sortie pour des raisons qui n’ont rien à voir avec le changement de mode, et une exécution headed sur un moniteur physique ne prouve pas qu’un écran virtuel échouerait. Faites la comparaison avec le même profil, le même codec et la même robustesse demandée, et laissez le mode de présentation être la seule variable indépendante.

Le hub ajoute l’ordre de lecture pour un changement de la ligne trois : vérifiez d’abord le champ de mode de présentation de l’en-tête, puis le champ de codec, puis la robustesse demandée. Un déplacement de la ligne trois qui coïncide avec un changement de mode de présentation ne demande pas d’enquête supplémentaire ; un déplacement avec un mode de présentation identique pointe vers le fixture de sortie.

Une manière propre de rester honnête est de consigner l’état de sortie et la solution de repli présentée par l’application, et rien sur un modèle de moniteur ou une identité de GPU. Le navigateur peut vous dire qu’une restriction de sortie s’est produite. Il ne peut pas vous dire qu’une personne regarde sur un écran particulier, et une inférence de ce genre transforme un dossier de capacité en affirmation que la mesure ne soutient pas.

Les noms d’état à consigner viennent de la table d’état des clés média et non des libellés du lecteur. Une session signale usable quand la clé est disponible, output-restricted quand la voie d’affichage bloque les images protégées, expired quand la fenêtre de licence s’est fermée, et released après le nettoyage. Faites correspondre le message visible par l’utilisateur dans l’application à l’un de ces noms dans le dossier, pour qu’un relecteur ultérieur compare des états au lieu de traduire des textes d’interface en quatre langues.

Le chemin négatif fait partie du fixture. Limites de Widevine headless énumère les cas négatifs qu’un fixture doit exercer délibérément et explique pourquoi une solution de repli testée vaut mieux qu’une solution documentée. À ce point de contrôle, le cas précis à ajouter est une restriction de sortie, parce que c’est le seul échec qui apparaît après une négociation réussie.

Décider qui possède la réponse de licence

Le dernier point de contrôle est le seul où le navigateur rapporte un message au lieu de prendre une décision. La page relaie une requête de licence opaque au fournisseur, le fournisseur répond, et la session devient utilisable ou non. Une erreur HTTP à ce stade peut signifier un compte, une région, une limite de concurrence, une habilitation expirée ou une panne de service, et aucune de ces choses n’est un fait de compatibilité du navigateur.

Garder la preuve du navigateur et celle du fournisseur séparées est ce qui fait fonctionner une passation, et l’apport du hub est la répartition de propriété plutôt que la mécanique des champs : la ligne un revient au responsable du binaire et du lancement, la ligne quatre au responsable du fournisseur. Limites de Widevine headless expose quel champ contient quel résultat ; ce que cette revue ajoute, c’est qu’un ticket qui ne nomme que « le DRM échoue » ne donne à l’équipe destinataire aucun moyen de distinguer ces deux responsables, donc la ligne doit voyager avec le ticket.

La conservation suit la même séparation. Gardez l’identifiant de compilation, la date du test, l’étiquette du profil, la configuration demandée, le nom du résultat, le statut et un horodatage. Supprimez les cookies, les identifiants de compte, les messages de licence, les jetons d’accès et le matériel de clés brut. Un dossier qui ne garde que des catégories peut encore comparer des versions, ce qui est la raison de le garder.

Un statut HTTP seul est souvent trop grossier pour router un ticket. Un 403 peut être une habilitation qui a expiré, une inadéquation de région, un plafond de concurrence déjà atteint sur le même compte ou une URL signée expirée, et le fournisseur renvoie généralement son propre code ou message d’erreur à côté. Consignez ce code comme catégorie et gardez le message complet hors de l’artefact partagé, parce que les messages de licence peuvent porter des identifiants qui appartiennent à un compte et non à une version. Un 429 et un 503 du même fournisseur demandent le même traitement et des responsables différents : le premier dit que le compte a atteint un plafond, le second que le service est en panne, et ni l’un ni l’autre ne se corrige en changeant le profil.

Quand un résultat change, changez une entrée déclarée par exécution et gardez le reste fixe. Limites de Widevine headless expose déjà l’ordre de comparaison qu’il recommande pour les quatre lignes ; ce hub ajoute seulement la règle que l’en-tête doit rester identique dans les deux exécutions, pour qu’une ligne déplacée puisse se lire comme une entrée déplacée.

Consigner un tableau par version

L’artefact qui survit à un cycle de version est un petit tableau avec une ligne par point de contrôle, conservé à côté d’un en-tête d’exécution qui ne change jamais de forme entre les versions. L’en-tête doit être fixé une fois et réutilisé, parce qu’un en-tête qui dérive rend deux tableaux impossibles à comparer. Huit champs couvrent les cas qui font bouger un résultat de capacité : produit et chaîne de compilation complète du navigateur, bibliothèque d’automatisation et version, système d’exploitation et version, mode de présentation, chaîne de codec testée, si le profil a été créé neuf, nom du système de clés et robustesse demandée. Limites de Widevine headless énumère les six premiers pour sa propre matrice ; les deux derniers sont ce qu’ajoute une revue de capacité.

Répétez le tableau après une mise à jour du navigateur ou de l’automatisation, après un changement de schéma de profil et après un changement de runner ou d’affichage, et gardez le tableau précédent à côté du nouveau. La première ligne qui a bougé nomme alors la couche à examiner, c’est pourquoi l’en-tête doit rester fixe : une ligne qui a bougé parce que l’en-tête a changé ne dit rien du navigateur.

Un exemple concret rend la comparaison tangible. Supposez que la version A consigne supported au point un, SW_SECURE_DECODE au deux, usable au trois et HTTP 200 au quatre avec une ressource de test. La version B consigne supported, SW_SECURE_DECODE, puis output-restricted au trois, et la ligne de licence ne s’exécute jamais parce que la session n’est pas utilisable. Une seule ligne a bougé, et elle a bougé sur la voie d’affichage, donc l’action suivante est de comparer la configuration d’affichage du runner au lieu de rouvrir la question du module ou de contacter le fournisseur.

Le cas inverse est tout aussi clair. Si le point un passe de supported à NotSupportedError alors que l’en-tête montre la même compilation et le même cycle de vie de profil, la différence vient d’un argument de lancement ou d’une mise à jour de composant qui ne s’est pas exécutée. Comparer la liste d’arguments avec un lancement simple répond à cela en une étape. Si l’en-tête montre une compilation différente, la liste d’arguments n’est pas la première chose à inspecter.

Le cluster donne à chaque point de contrôle son traitement détaillé. Le contrat de configuration pour installer un module et l’associer à un profil est dans Configuration de Widevine DRM. La vue d’empreinte, qui explique quelles parties de la surface EME une page peut lire sans rien lire, est dans Empreinte DRM. La matrice qui sépare les quatre limites avec un fixture par ligne est dans Limites de Widevine headless. La mesure qui isole l’argument de lancement responsable d’un module absent est dans Disponibilité du CDM Widevine dans les navigateurs automatisés.

Lisez-les dans cet ordre quand une revue part de zéro : la configuration définit les entrées, l’empreinte explique ce qui est observable, la matrice de limites transforme l’observation en lignes, et la mesure de disponibilité explique le résultat zéro le plus courant. Lisez seulement celui qui correspond au point de contrôle qui a échoué quand une revue est déjà en cours, parce que les autres répondraient à des questions que personne n’a posées.

Conclusion pratique

Une revue de capacité DRM, ce sont quatre questions, posées dans l’ordre, chacune avec sa propre valeur et son propre responsable. Consignez le résultat de la négociation, la chaîne de robustesse acceptée, l’état de sortie et le statut du fournisseur comme champs séparés, puis comparez les versions en cherchant la première ligne qui a changé. Une ligne qui réussit prouve qu’un contrat a tenu ; elle ne prouve pas qu’un titre se lit, et énoncer cette limite fait partie du résultat.

Sources publiques

• API Encrypted Media Extensions sur MDN
• Encrypted Media Extensions du W3C
• Documentation Widevine
• Configuration Widevine de BotBrowser

Lecture suivante

Commencez par Configuration de Widevine DRM pour les entrées, puis suivez le lien du cluster qui correspond au point de contrôle qui a échoué.