Fingerprinting DRM: qué revelan las consultas EME y Widevine

Una página puede leer señales de Encrypted Media Extensions sin reproducir nada: sistemas de claves, niveles de robustez, tipos de sesión y compatibilidad de códecs. BotBrowser hace que esas respuestas sigan al perfil cargado; no suministra el CDM de Widevine ni una licencia, y no garantiza la reproducción.

Resumen rápido

La superficie DRM es un conjunto de respuestas a navigator.requestMediaKeySystemAccess, no un valor único. Consulta Widevine y Clear Key con las mismas configuraciones en cada ejecución y compara lo que se resuelve o se rechaza con la plataforma del perfil.

Contenido de esta guía

• Ver el vídeo
• Qué exponen las Encrypted Media Extensions a una página
• Las señales DRM que un sitio puede leer sin preguntar
• Por qué las VPN, las ventanas privadas y las extensiones no cambian estas respuestas
• Dónde encajan las señales DRM entre otras señales de plataforma
• Cómo comprobar las señales DRM con el perfil elegido
• Qué cubre BotBrowser y qué queda fuera

Ver el vídeo

Este vídeo en inglés ejecuta una matriz fija de dieciséis preguntas DRM contra una página de laboratorio local controlada, en Google Chrome oficial, en dos equipos de prueba, Ubuntu y Windows. No se carga ningún contenido multimedia ni se solicita una licencia. Diez respuestas se resuelven, seis se rechazan y ambos equipos producen el mismo resumen de la tabla, 4753cab0, por lo que solo muestra cómo encajan las respuestas entre sí y nada sobre un usuario real. No interviene ningún perfil de BotBrowser ni proxy. El audio está en inglés.

Qué exponen las Encrypted Media Extensions a una página

Encrypted Media Extensions, abreviado EME, es una especificación del W3C que permite que una página web coopere con un módulo de descifrado de contenido, o CDM, para reproducir audio y vídeo protegidos. Los servicios de streaming lo usan para que una emisión con licencia se reproduzca en una pestaña normal sin complementos. El CDM más conocido es Widevine, que se incluye en Chrome y en la mayoría de los navegadores basados en Chromium. Existen otros sistemas de claves para otras plataformas, y uno de ellos, Clear Key, lo define la propia especificación para que todo navegador conforme ofrezca una base común. BotBrowser puede mantener coherentes los valores de capacidad multimedia de un perfil en un contexto controlado; no puede añadir un sistema DRM ni un servicio de licencias que la compilación y la plataforma no ofrezcan.

Una página no necesita reproducir nada para conocer este mecanismo. Antes de pedir una licencia, la página pregunta al navegador si puede trabajar con un sistema de claves y con un conjunto de configuraciones multimedia. Esa pregunta forma parte normal de la reproducción, y la respuesta ayuda a un reproductor de streaming a elegir entre formatos. La misma pregunta también puede hacerla un script que no tiene ningún reproductor, sin aviso de permisos y sin ningún cambio visible en pantalla.

La llamada central es navigator.requestMediaKeySystemAccess. Recibe el nombre de un sistema de claves y una lista de configuraciones solicitadas. Si el navegador puede satisfacer al menos una configuración, la promesa se resuelve con un objeto MediaKeySystemAccess. Si no puede, la promesa se rechaza. Ambos resultados aportan información, y un script puede repetir la llamada con muchas configuraciones distintas en pocos instantes. La llamada solo está disponible en contextos seguros, es decir, en la práctica en una página HTTPS normal.

Por eso los datos de capacidad DRM tienen su lugar en cualquier análisis serio del fingerprinting del navegador. El resultado no es un identificador estable por sí solo. Mucha gente usa el mismo sistema operativo y la misma versión de Chrome, y dará las mismas respuestas. Lo que sí ofrece el resultado es un conjunto de datos de plataforma y de hardware difícil de leer con otras API, y ese conjunto se suma al cuadro que un sitio construye al combinar muchas señales.

Las señales DRM que un sitio puede leer sin preguntar

Varias partes de la superficie EME contribuyen a lo que un script puede averiguar. Conviene separarlas, porque cada una cambia por motivos distintos y cada una necesita su propia comprobación.

• Compatibilidad con sistemas de claves. Widevine, Clear Key, PlayReady y FairPlay se identifican con una cadena de sistema de claves. Cuáles acepta un navegador depende mucho del sistema operativo y de la compilación del navegador. Un navegador que acepta un sistema de claves ligado a una plataforma le dice mucho a la página sobre el lugar donde se ejecuta.
• Niveles de robustez. En Widevine, una configuración solicitada puede nombrar un nivel de robustez, como cifrado por software, decodificación por software, cifrado por hardware, decodificación por hardware o protección completa por hardware. Que se acepte un nivel refleja cuánta protección respaldada por hardware ofrecen el dispositivo y el CDM.
• La matriz de códecs DRM. Los códecs que acepta un sistema de claves dentro de una configuración protegida no siempre coinciden con los que el navegador declara para la reproducción normal. La combinación de contenedor, códec y robustez que tiene éxito forma su propia tabla pequeña.
• Tipos de sesión y tipos de datos de inicialización. Una configuración enumera los tipos de sesión que admite y los formatos de datos de inicialización que acepta, como el formato de cifrado común usado en contenido MP4. Las sesiones temporales y las persistentes son capacidades distintas.
• Objetos de configuración. Cuando una consulta tiene éxito, getConfiguration() devuelve la configuración que el navegador aceptó realmente. El objeto incluye las capacidades aceptadas y los requisitos distinctiveIdentifier y persistentState. Detalles como el orden y los campos exactos de ese objeto pueden variar entre plataformas.

Cada una de estas señales es fácil de consultar y barata de repetir. Un script puede pedir decenas de combinaciones y anotar cuáles se resuelven. La referencia de MDN sobre requestMediaKeySystemAccess documenta los parámetros y el comportamiento de rechazo, y la especificación del W3C define el diccionario de configuración que devuelve una consulta con éxito.

Clear Key merece una nota aparte. Como la define la especificación, todo navegador conforme puede responder por él, así que funciona como línea base y no como marcador de plataforma. Su valor en una comprobación de coherencia es el de un control: si Clear Key se resuelve con normalidad mientras un sistema de claves propio de una plataforma se comporta de forma extraña, el problema está en la capa DRM y no en la página ni en la red. Los detalles que devuelve, como los tipos de datos de inicialización admitidos, aún pueden diferir un poco entre compilaciones del navegador.

Lo importante para ti es la palabra silenciosa. Ninguna de estas consultas muestra un aviso, ninguna exige un gesto del usuario y ninguna deja un rastro visible. Una página puede ejecutarlas mientras carga. La especificación del W3C incluye consideraciones de privacidad sobre cómo las capacidades y los identificadores expuestos pueden ayudar a reconocer a un usuario, y esa es la misma preocupación que motiva este tema.

También conviene ser precisos sobre lo que estas señales no hacen. Los datos de capacidad DRM no nombran a una persona y, por sí solos, no distinguen un dispositivo entre millones. Reducen el campo. Un sitio que los combina con señales de pantalla, fuentes, audio, códecs y red obtiene una imagen mucho más nítida que la que da cualquiera de ellas por separado. En ese sentido las consultas DRM contribuyen a la identificación, y es el único sentido en que se usa el término aquí.

Por qué las VPN, las ventanas privadas y las extensiones no cambian estas respuestas

Repite la misma configuración de requestMediaKeySystemAccess() antes y después de cambiar la ruta; keySystem y robustness siguen siendo entradas de capacidad local.

Quien cuida su privacidad suele recurrir primero a una VPN, a una ventana privada o a una extensión del navegador. Las tres son herramientas razonables para otros problemas, y ninguna toca las señales descritas arriba.

Una VPN cambia la ruta de red y la dirección IP visible. La consulta de capacidades EME nunca usa la red. Pregunta al navegador, el navegador pregunta al CDM instalado y la respuesta sale del software y del hardware de la máquina local. Activar o desactivar la VPN, o cambiar de país, no altera qué sistemas de claves están presentes ni qué niveles de robustez puede cumplir el dispositivo.

Una ventana privada cambia cómo guarda el navegador las cookies, el historial y los datos del sitio durante una sesión. No instala ni elimina un CDM y no cambia el hardware. La compatibilidad con sistemas de claves, los niveles de robustez y la matriz de códecs resultan iguales en una ventana privada que en una normal. La navegación privada protege bien frente al reconocimiento basado en cookies, pero los datos de capacidad DRM no son estado almacenado, así que no hay nada que borrar.

Las extensiones son la opción más tentadora y la más débil. Una extensión que bloquea la API por completo rompe también todos los servicios que dependen de la reproducción protegida, y la API ausente es en sí una decisión visible e inusual. Una extensión que reescribe valores devueltos en los scripts de la página debe mantener cada respuesta coherente con todas las demás, incluidos los objetos que devuelve getConfiguration(), y no puede añadir ni quitar compatibilidad nativa con el CDM. Un parche de este tipo en el script suele producir una mezcla que ningún navegador real informaría, lo que resulta más distintivo que la respuesta original.

Por la misma razón, sustituir un solo valor no basta. Una configuración que afirma protección respaldada por hardware en una plataforma que no la tiene, o que enumera un sistema de claves propio de otro sistema operativo, es internamente incoherente. La coherencia de todo el conjunto de respuestas importa más que cualquier respuesta aislada, y eso vale igualmente para los datos de códecs. El artículo relacionado sobre fingerprinting MIME y de códecs trata con más detalle la parte de códecs.

Una forma útil de recordar la división: las herramientas de red cambian desde dónde parece conectarse una sesión, los controles de almacenamiento cambian lo que una sesión recuerda, y ninguno cambia lo que pueden hacer la máquina y la compilación del navegador. Los datos de capacidad DRM describen lo que pueden hacer la máquina y la compilación. Solo los mueve un cambio en la identidad de plataforma que informa el navegador, aplicado a todas las superficies a la vez.

Dónde encajan las señales DRM entre otras señales de plataforma

Anota la versión mayor junto a cada resultado de getConfiguration(), persistentState y distinctiveIdentifier para separar un cambio de versión de un cambio de perfil.

Un navegador presenta a la página un entorno coherente, y los datos DRM son uno de los lugares donde ese entorno puede dejar de serlo. La cadena de user agent, la cadena de plataforma, las fuentes declaradas, la pila de audio, el renderizador WebGL y el conjunto de capacidades DRM describen la misma máquina. Cuando describen máquinas distintas, un sitio tiene un motivo sencillo para tratar la sesión como inusual.

Piensa en una sesión que declara una identidad de Windows de escritorio pero se ejecuta en un host Linux. Si solo se cambian las cadenas visibles, la superficie DRM aún puede reflejar el host. Los sistemas de claves, los niveles de robustez y los tipos de sesión pueden seguir la plataforma del host mientras todo lo demás apunta a Windows. La página no necesita ninguna astucia para notarlo. Solo tiene que comparar dos respuestas.

El mismo razonamiento vale entre versiones del navegador. Widevine y el navegador reciben actualizaciones, y el conjunto de niveles de robustez y de códecs admitidos puede cambiar con ellas. Por tanto, la versión de navegador declarada y el conjunto de capacidades DRM declarado deben corresponder al mismo periodo. Mezclar una identidad de navegador reciente con las respuestas DRM de una compilación antigua produce otra incoherencia fácil de detectar.

El audio es una comparación útil. El artículo sobre el fingerprinting de audio describe cómo la misma rutina da resultados distintos en pilas de audio distintas. El DRM funciona de forma parecida: la misma pregunta recibe respuestas distintas en plataformas distintas, y las respuestas son estables en una misma plataforma. La estabilidad es lo que hace útil una señal para reconocer, y también lo que da sentido a una comprobación de coherencia.

Por eso los datos DRM deben tratarse como parte de la identidad de plataforma y no como un ajuste independiente. Un perfil que describe una plataforma debe describir su comportamiento DRM como una de sus partes. Editar a mano respuestas de capacidad sueltas, una a una, deja demasiados puntos donde el cuadro puede contradecirse.

Las plataformas móviles añaden otra capa. Un perfil de un dispositivo Android describe una plataforma donde es común la protección respaldada por hardware, mientras que muchos entornos de escritorio y virtuales no pueden cumplir los niveles de robustez más altos. Una superficie DRM que afirma decodificación respaldada por hardware en un host que claramente no la admite es una incoherencia que una sola consulta revela. Al elegir un perfil, compara su plataforma con el hardware en el que realmente trabajas y trata cualquier diferencia grande como algo que verificar en lugar de suponer que se resolverá sola.

Cómo comprobar las señales DRM con el perfil elegido

La comprobación empieza con una lista escrita de lo que afirma el perfil cargado. La plataforma, la versión mayor del navegador y el origen del perfil son los tres datos de los que dependen todas las comprobaciones posteriores. Con ellos anotados, la superficie DRM puede compararse con ellos de forma repetible.

1. Nombra primero la plataforma del perfil. Anota el sistema operativo que describe el perfil y los sistemas de claves que esperarías en esa plataforma. Un sistema de claves propio de otro sistema operativo no debería aparecer, y uno que ofrecen todos los navegadores de esa plataforma no debería faltar.
2. Ejecuta consultas de capacidades para cada sistema de claves. Consulta Widevine y Clear Key con un conjunto pequeño de configuraciones y anota cuáles se resuelven y cuáles se rechazan. Mantén las configuraciones idénticas de una ejecución a otra para que las diferencias del resultado sean diferencias reales.
3. Compara los niveles de robustez. Pide cada nivel de robustez de Widevine por turno y anota cuáles se aceptan. El conjunto aceptado debe encajar con el nivel de hardware que describe el perfil y no debe superar lo que esa plataforma puede ofrecer de forma plausible.
4. Lee los objetos de configuración. Para cada consulta con éxito, lee lo que devuelve getConfiguration() y anota los tipos de datos de inicialización, las capacidades de audio y vídeo, los tipos de sesión y los valores de distinctiveIdentifier y persistentState. Deben parecerse a la salida de la plataforma que describe el perfil.
5. Repite entre recargas y reinicios. Recarga la página, cierra el navegador, vuelve a iniciarlo con el mismo perfil y ejecuta las mismas consultas. Los resultados deben ser idénticos cada vez. Un resultado que cambia entre ejecuciones apunta a un problema de configuración y no a una propiedad de la plataforma.
6. Compara ejecuciones con y sin interfaz. Si usas ambos modos, ejecuta las mismas consultas en cada uno y compáralas. Las diferencias merecen investigación, porque un CDM presente en un modo y ausente en el otro es visible para cualquier página que lo pregunte.

Guarda los resultados en una tabla breve junto al nombre del perfil. Cuando un cambio posterior en el perfil, en la versión del navegador o en el entorno del host altere un resultado, la tabla muestra qué respuesta se movió. Revísala de nuevo tras cada actualización del navegador, porque la superficie DRM puede cambiar con una nueva versión.

Interpreta los fallos por categorías. Un sistema de claves que falta en una plataforma donde debería existir suele indicar que el CDM no se instaló o no se encontró. Un sistema de claves que existe donde no debería apunta a una discrepancia entre el perfil y el host. Un nivel de robustez que se acepta en una ejecución y se rechaza en la siguiente sugiere que el entorno cambió entre ejecuciones, por ejemplo con otra versión del CDM o con otro modo de arranque. Anotar a qué categoría pertenece un fallo hace evidente el siguiente paso y acorta la investigación.

Esta comprobación solo compara respuestas DRM con el perfil. No prueba que un servicio de streaming concreto reproduzca contenido. La reproducción depende de un CDM, de un servidor de licencias y de la política del sitio, y nada de eso forma parte de una comparación de capacidades. Un resultado limpio aquí significa que las señales son coherentes, nada más.

Qué cubre BotBrowser y qué queda fuera

BotBrowser soporta el reporte de capacidades DRM guiado por el perfil, de modo que los sistemas de claves EME, los niveles de robustez, los tipos de sesión y la compatibilidad de códecs DRM que una página puede consultar se informan de forma coherente con la identidad de plataforma del perfil cargado, y la documentación de BotBrowser sobre DRM indica que no hace falta ningún indicador de CLI aparte para ello. Así tienes una base definida con la que verificar, con las comprobaciones anteriores, sin editar respuestas sueltas a mano. BotBrowser no puede suministrar ni incluir el CDM de Widevine, descifrar contenido protegido, garantizar la reproducción ni la aprobación de licencias, ni controlar la política DRM propia de un sitio ni sus decisiones de detección.

La reproducción es una tarea distinta de la coherencia. Para reproducir contenido protegido necesitas un CDM de Widevine obtenido por canales oficiales y la licencia que lo acompaña, y nada de eso viene del navegador. La guía de configuración de Widevine DRM cubre la parte de configuración, y la documentación de BotBrowser sobre coherencia de la huella DRM describe cómo el reporte de capacidades sigue al perfil. Cuando se rechaza una sesión, el panorama de capacidades DRM separa las cuatro comprobaciones que deciden si la causa es el módulo, un nivel de robustez, la ruta de salida o la licencia.

Mantén separadas dos preguntas al planificar una prueba. La primera es si la superficie DRM coincide con el perfil, que responde la lista anterior. La segunda es si un servicio concreto reproduce contenido para una cuenta concreta, lo que depende del servicio. Una sesión puede superar la primera y aun así fallar la segunda por motivos que nada tienen que ver con el navegador.

En un plan de pruebas, anota qué pregunta responde cada prueba y guarda las evidencias de cada una por separado. Un informe de coherencia enumera sistemas de claves, niveles de robustez, campos de configuración y cuántas ejecuciones coincidieron. Un informe de reproducción enumera el servicio, el tipo de cuenta y el origen del CDM. Mezclar ambos dificulta atribuir los fallos a la causa correcta.

Qué añade frente a la página de referencia

La página de referencia nombra las superficies EME. La comparación añadida registra por separado el sistema de claves, la robustez, la configuración de códecs y la reproducción. Una VPN, ventana privada o extensión no convierte la respuesta de licencia en capacidad del navegador.

Fuentes públicas

• W3C: Encrypted Media Extensions
• MDN: Navigator.requestMediaKeySystemAccess()
• Documentación de BotBrowser: coherencia de la huella DRM
• Widevine en navegadores automatizados

Conclusión práctica

Registra por separado cuatro resultados: sistema de claves, robustez, configuración de códecs y reproducción. Que los tres primeros coincidan con el perfil demuestra coherencia; que un servicio reproduzca depende del CDM, de la licencia y de la política del sitio.