Comprobaciones DRM: sistema de claves, robustez y salida

El contenido cifrado falla por cuatro razones distintas, y un equipo que solo pregunta si el DRM funciona no puede distinguirlas. Esta vista general ordena los cuatro puntos de control de una revisión de capacidad DRM y enlaza el clúster que se ocupa de cada uno: la negociación del módulo, la robustez negociada, la salida protegida y la decisión de licencia.

BotBrowser puede mantener un perfil declarado y su política de medios por contexto coherentes en un contexto autorizado cuando la compilación y la licencia lo permiten. No puede fabricar un módulo de descifrado de contenido, anular la decisión de cuenta de un proveedor ni prometer que un título concreto se reproduzca en cualquier host.

TL;DR

• Haz una sola pregunta por punto de control. Un rechazo en el paso de acceso y un rechazo en el paso de licencia son fallos distintos con responsables distintos, y presentar cualquiera de los dos como «el DRM falla» envía el ticket al equipo equivocado.
• Registra la cadena de robustez aceptada (SW_SECURE_DECODE, HW_SECURE_ALL) en lugar de convertirla en un sí o un no.
• Trata headless y headed como modos de presentación. Una pantalla virtual no es un nivel de seguridad más bajo, y un monitor físico no prueba una ruta con hardware seguro.
• Mantén el código de estado del proveedor en su propio campo. Es una decisión de política sobre una cuenta y un título, no una capacidad del navegador.

Contenido

• Cuatro puntos de control detrás de una sola pregunta
• Nombrar primero el límite del módulo
• Leer la robustez como un rango, no como un veredicto
• Mantener la protección de salida aparte del modo de presentación
• Decidir quién es dueño de la respuesta de licencia
• Registrar una tabla por cada versión

Cuatro puntos de control detrás de una sola pregunta

Los cuatro puntos de control son secuenciales, y cada uno responde a una pregunta distinta sobre la misma sesión. Confundirlos es la razón más común por la que una investigación DRM se estanca, porque la búsqueda de una causa empieza en la capa equivocada y nunca llega a la que falló de verdad.

El primer punto de control es si el navegador negociará el sistema de claves. El segundo es qué nivel de robustez acepta. El tercero es si la ruta de salida puede transportar fotogramas protegidos. El cuarto es si el servidor de licencias concede una clave para esta cuenta, región y título.

El orden importa para el diagnóstico, no solo para la limpieza. Un rechazo en el primer punto detiene la cadena, así que nada posterior se ha probado. Un aprobado en el primer punto y un rechazo en el cuarto prueban que el lado del navegador negoció con éxito y que la decisión vino del proveedor. Esos dos resultados apuntan a responsables distintos, y un ticket de soporte que solo dice "el DRM no funciona" no puede distinguirlos.

Punto de control	Llamada o evento del navegador	Valor que se registra
1 Acceso	requestMediaKeySystemAccess()	supported o NotSupportedError
2 Robustez	getConfiguration() tras una petición	cadena de robustez aceptada
3 Salida	keystatuseschange en la sesión	usable, output-restricted, expired
4 Licencia	respuesta HTTP del mensaje de licencia	código de estado y categoría de error del proveedor

Cada fila es un experimento separado con su propia categoría de fallo. Un revisor que las mantiene separadas puede nombrar la primera fila que se rompió y entregarla al equipo responsable, en lugar de reabrir toda la configuración.

Cada fila también tiene un límite que conviene declarar junto al valor. Un aprobado en el punto uno prueba que el navegador negociará el sistema de claves; no prueba que una clave pueda descifrarse ni que un título se reproduzca. Un aprobado en el punto dos prueba que el módulo aceptó un nivel; no prueba que la ruta de presentación pueda transportar fotogramas protegidos. Un estado usable en el punto tres prueba que las claves se liberaron para la sesión; no prueba que el proveedor haya autorizado la cuenta. Un HTTP 200 en el punto cuatro prueba que llegó una respuesta de licencia; no prueba que la siguiente petición, otro título u otra región vayan a funcionar. Escribir esos límites en el registro es lo que evita que una cadena de cuatro aprobados se lea como una garantía de reproducción.

Nombrar primero el límite del módulo

El módulo es la entrada de la que depende todo lo demás, y en un lanzamiento automatizado a menudo está ausente sin ningún error que lo mencione. Un navegador que no tiene módulo rechaza toda configuración para el sistema de claves, así que la sonda informa un fallo de capacidad que parece un problema de configuración y en realidad es un problema de empaquetado.

Hay dos hechos sobre el módulo que conviene declarar de forma explícita en un registro de revisión. Primero, el binario importa antes que los argumentos: una compilación de Chromium de código abierto normalmente no trae el módulo Widevine, mientras que una compilación de Google Chrome sí. Una suite que lanza una compilación de Chromium integrada probablemente informará falta de soporte sea cual sea el argumento que pase, y la solución es lanzar una compilación que pueda llevar un módulo.

Segundo, los valores predeterminados de un marco de automatización pueden desactivar el componente que hace disponible el módulo. Un lanzamiento predeterminado de Playwright incluye --disable-component-update, que es una elección razonable para un runner que no quiere tráfico de red en segundo plano, y también significa que un perfil recién creado en este entorno informó falta de soporte de Widevine en una medición publicada en el clúster. La misma sonda, con ese único argumento eliminado, informó SW_SECURE_CRYPTO y SW_SECURE_DECODE como compatibles en la misma máquina, tanto en modo headless como en modo headed. La medición ejecutó una compilación instalada de Google Chrome, no un Chromium integrado, así que no dice nada sobre una compilación que no trae ningún módulo.

Esa medición conviene leerla como un método y no como una regla universal. Aísla un argumento, no cambia nada más y compara la misma sonda antes y después. El sistema de componentes de Chrome es propio de Chrome, así que otra versión u otro sistema operativo pueden comportarse de forma distinta, y la parte reproducible es la comparación y no el resultado concreto.

Para esta revisión, la consecuencia es una regla de ubicación y no un hecho sobre Chrome: un módulo ausente nunca llega al primer punto de control, así que debe registrarse en el campo de compilación de la cabecera, no como una fila fallida. Una tabla que muestra un NotSupportedError en rojo en la primera fila contra una compilación de Chromium integrada está describiendo la cabecera, y un lector que nunca ve la cabecera lo leerá como un problema de módulo o de proveedor.

Dos lanzamientos expresan la comparación, y el segundo es el único que difiere:

const base = { executablePath: '/opt/google/chrome/chrome', headless: true };
await chromium.launch(base); // valores predeterminados del framework, incluido --disable-component-update
await chromium.launch({ ...base, ignoreDefaultArgs: ['--disable-component-update'] }); // el único cambio

Registra si el perfil era nuevo o persistente junto al resultado. Un perfil temporal repite el registro de primera ejecución en cada lanzamiento, y un resultado de un perfil de escritorio de larga vida no es evidencia sobre un contenedor de CI que crea un directorio nuevo por trabajo. Compara cosas comparables.

La mitad de la sonda que se ejecuta en la página es lo bastante corta para mantenerla junto al registro. Ejecútala con page.evaluate después de cada lanzamiento anterior; pide una configuración, imprime qué sistemas de claves se resuelven y nunca intenta la reproducción:

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 en ese bucle es un control, no un marcador de plataforma. La especificación lo define, así que todo navegador conforme responde por él, y su función aquí es separar un problema de página o de red de un problema de DRM. Si Clear Key se resuelve con normalidad mientras el sistema de claves de la plataforma rechaza toda configuración, la capa CDM es el lugar donde hay que mirar y la página no.

Leer la robustez como un rango, no como un veredicto

Una vez que el sistema de claves negocia, el navegador y el módulo acuerdan un nivel de robustez. Las cadenas son el vocabulario que usa un proveedor para decidir qué servirá: SW_SECURE_CRYPTO y SW_SECURE_DECODE mantienen el trabajo criptográfico o la decodificación en software, y HW_SECURE_ALL exige una ruta de hardware de confianza. Widevine llama nivel 3 al caso solo de software, y los niveles superiores dependen de hardware que el host puede no tener.

Un nivel de hardware rechazado no es un defecto de la configuración. Muchos entornos de escritorio y virtuales no tienen una ruta con hardware seguro, y un proveedor que sirve contenido ordinario en niveles de software funciona allí. Por eso el registro útil contiene la cadena que se aceptó realmente, junto con la configuración que se pidió, porque ese par es lo que un revisor posterior necesita para ver que la respuesta se movió.

Dos hábitos hacen fiable esta fila. Repite la configuración idéntica de ejecución en ejecución, para que una diferencia en la salida sea una diferencia real y no una pregunta distinta. Y lee el objeto de configuración devuelto en lugar de suponer que la petición se concedió tal como se escribió. Huella digital DRM enumera los campos que lleva ese objeto y lo que cada uno revela sobre la plataforma, así que este hub no los repite.

Una configuración H.264 exitosa es una celda de una matriz, no la matriz, y Huella digital DRM cubre cómo se lee esa matriz. Lo que importa en este punto de control es más estrecho: registra qué celda pediste y qué celda respondió, porque un proveedor que sirve una resolución más baja en un nivel más bajo está tomando una decisión de política que aquí solo se ve como un nivel aceptado.

Mantener la protección de salida aparte del modo de presentación

La reproducción puede empezar y luego detenerse cuando la ruta de presentación no cumple un requisito de salida protegida. La sesión informa ese estado mediante keystatuseschange, a menudo como output-restricted, y se espera que la aplicación muestre una alternativa en lugar de un fallo opaco. Este punto de control trata de la ruta de presentación y es independiente de si el sistema de claves negoció.

El error frecuente es fundir esta fila en headless frente a headed. Headless es un modo de presentación, no un nivel de seguridad. Una pantalla virtual puede cumplir o incumplir un requisito de salida por razones que no tienen nada que ver con el cambio de modo, y una ejecución headed en un monitor físico no prueba que una pantalla virtual fuera a fallar. Haz la comparación con el mismo perfil, el mismo códec y la misma robustez solicitada, y deja que el modo de presentación sea la única variable independiente.

El hub añade el orden de lectura para un cambio en la fila tres: revisa primero el campo de modo de presentación de la cabecera, después el campo de códec y después la robustez solicitada. Un movimiento de la fila tres que coincide con un cambio de modo de presentación no necesita más investigación; un movimiento con un modo de presentación idéntico apunta al fixture de salida.

Una forma limpia de mantener esto honesto es registrar el estado de salida y la alternativa que mostró la aplicación, y nada sobre un modelo de monitor o una identidad de GPU. El navegador puede decirte que ocurrió una restricción de salida. No puede decirte que una persona está mirando en una pantalla concreta, y una inferencia de ese tipo convierte un registro de capacidad en una afirmación que la medición no sostiene.

Los nombres de estado que conviene registrar vienen del mapa de estado de claves de medios y no de las etiquetas propias del reproductor. Una sesión informa usable cuando la clave está disponible, output-restricted cuando la ruta de presentación bloquea fotogramas protegidos, expired cuando se cerró la ventana de licencia, y released después de la limpieza. Asocia el mensaje que ve el usuario en la aplicación con uno de esos nombres en el registro, para que un revisor posterior compare estados en lugar de traducir textos de interfaz en cuatro idiomas.

La ruta negativa pertenece al fixture. Límites de Widevine headless enumera los casos negativos que un fixture debe ejercitar a propósito y explica por qué una alternativa probada vale más que una documentada. En este punto de control, el caso concreto que hay que añadir es una restricción de salida, porque es el único fallo que aparece después de una negociación exitosa.

Decidir quién es dueño de la respuesta de licencia

El último punto de control es el único donde el navegador informa un mensaje en lugar de tomar una decisión. La página retransmite una petición de licencia opaca al proveedor, el proveedor responde, y la sesión pasa a ser utilizable o no. Un error HTTP en esta etapa puede significar una cuenta, una región, un límite de concurrencia, un derecho caducado o una caída del servicio, y ninguno de esos es un hecho de compatibilidad del navegador.

Mantener la evidencia del navegador y la del proveedor aparte es lo que hace que un traspaso funcione, y la aportación del hub es la división de propiedad y no la mecánica de campos: la fila uno pertenece al responsable del binario y del lanzamiento, la fila cuatro al responsable del proveedor. Límites de Widevine headless expone qué campo guarda qué resultado; lo que añade esta revisión es que un ticket que solo nombra «el DRM falla» no da al equipo receptor forma de distinguir a esos dos responsables, así que la fila tiene que viajar con el ticket.

La retención sigue la misma división. Guarda el identificador de compilación, la fecha de la prueba, la etiqueta del perfil, la configuración solicitada, el nombre del resultado, el estado y una marca temporal. Elimina cookies, identificadores de cuenta, mensajes de licencia, tokens de acceso y material de claves en bruto. Un registro que solo guarda categorías todavía puede comparar versiones, que es la razón de guardarlo.

Un estado HTTP por sí solo suele ser demasiado burdo para encaminar un ticket. Un 403 puede ser un derecho que venció, un desajuste de región, un límite de concurrencia ya alcanzado en la misma cuenta o una URL firmada caducada, y el proveedor normalmente devuelve su propio código o mensaje de error junto a él. Registra ese código como categoría y deja el mensaje completo fuera del artefacto compartido, porque los mensajes de licencia pueden llevar identificadores que pertenecen a una cuenta y no a una versión. Un 429 y un 503 del mismo proveedor necesitan el mismo tratamiento y responsables distintos: el primero dice que la cuenta alcanzó un límite, el segundo que el servicio está caído, y ninguno se arregla cambiando el perfil.

Cuando un resultado cambia, cambia una entrada declarada por ejecución y deja el resto fijo. Límites de Widevine headless ya expone el orden de comparación que recomienda para las cuatro filas; este hub solo añade la regla de que la cabecera tiene que seguir idéntica en ambas ejecuciones, para que una fila movida se pueda leer como una entrada movida.

Registrar una tabla por cada versión

El artefacto que sobrevive a un ciclo de versión es una tabla pequeña con una fila por punto de control, guardada junto a una cabecera de ejecución que nunca cambia de forma entre versiones. Vale la pena fijar la cabecera una vez y reutilizarla, porque una cabecera que cambia de forma entre versiones hace imposible comparar dos tablas. Ocho campos cubren los casos que mueven un resultado de capacidad: producto y cadena de compilación completa del navegador, biblioteca de automatización y versión, sistema operativo y versión, modo de presentación, cadena de códec en prueba, si el perfil se creó nuevo, nombre del sistema de claves y robustez solicitada. Límites de Widevine headless enumera los seis primeros para su propia matriz; los dos últimos son lo que añade una revisión de capacidad.

Repite la tabla después de una actualización del navegador o de la automatización, después de un cambio de esquema de perfil y después de un cambio de runner o de pantalla, y guarda la tabla anterior junto a la nueva. La primera fila que se movió nombra entonces la capa que hay que investigar, por lo que la cabecera tiene que mantenerse fija: una fila que se movió porque la cabecera cambió no dice nada sobre el navegador.

Un ejemplo resuelto hace concreta la comparación. Supón que la versión A registra supported en el punto uno, SW_SECURE_DECODE en dos, usable en tres y HTTP 200 en cuatro con un recurso de prueba. La versión B registra supported, SW_SECURE_DECODE, luego output-restricted en tres, y la fila de licencia nunca se ejecuta porque la sesión no es utilizable. Solo se movió una fila, y se movió en la ruta de presentación, así que la siguiente acción es comparar la configuración de pantalla del runner en lugar de reabrir la pregunta del módulo o contactar al proveedor.

El caso inverso es igual de claro. Si el punto uno pasa de supported a NotSupportedError mientras la cabecera muestra la misma compilación y el mismo ciclo de vida del perfil, la diferencia vino de un argumento de lanzamiento o de una actualización de componente que no se ejecutó. Comparar la lista de argumentos con un lanzamiento simple responde eso en un paso. Si la cabecera muestra una compilación distinta, la lista de argumentos no es lo primero que hay que inspeccionar.

El clúster da a cada punto de control su tratamiento detallado. El contrato de configuración para instalar un módulo y ajustarlo a un perfil está en Configuración de Widevine DRM. La vista de huella digital, que explica qué partes de la superficie EME puede leer una página sin reproducir nada, está en Huella digital DRM. La matriz que separa los cuatro límites con un fixture por fila está en Límites de Widevine headless. La medición que aísla el argumento de lanzamiento responsable de un módulo ausente está en Disponibilidad del CDM de Widevine en navegadores automatizados.

Léelos en ese orden cuando una revisión empiece de cero: la configuración define las entradas, la huella digital explica qué es observable, la matriz de límites convierte la observación en filas y la medición de disponibilidad explica el resultado cero más común. Lee solo el que coincide con el punto de control que falló cuando una revisión ya está en marcha, porque los demás responderían preguntas que nadie hizo.

Conclusión práctica

Una revisión de capacidad DRM son cuatro preguntas, hechas en orden, cada una con su propio valor y su propio dueño. Registra el resultado de la negociación, la cadena de robustez aceptada, el estado de salida y el estado del proveedor como campos separados, y luego compara versiones buscando la primera fila que cambió. Una fila que pasa prueba que un contrato se cumplió; no prueba que un título se reproduzca, y declarar ese límite forma parte del resultado.

Fuentes públicas

• API Encrypted Media Extensions en MDN
• Encrypted Media Extensions del W3C
• Documentación de Widevine
• Configuración de Widevine en BotBrowser

Lectura siguiente

Empieza con Configuración de Widevine DRM para las entradas, y luego sigue el enlace del clúster que coincide con el punto de control que falló.