DRM-фингерпринтинг: что раскрывают запросы EME и Widevine

Статья объясняет, какие сигналы зашифрованных медиа (EME) страница читает без запроса и без воспроизведения. BotBrowser сообщает их согласованно с профилем, но не проигрывает защищённый контент: для этого нужны CDM Widevine, лицензия и политика сервиса.

Краткое резюме

Системы ключей, уровни надёжности, матрица кодеков DRM, типы сессий и getConfiguration() отвечают из локальной платформы, поэтому VPN, приватное окно и расширения их не меняют. Сверяйте эти ответы с платформой и версией профиля, а согласованность и воспроизведение проверяйте как два отдельных вопроса.

Содержание руководства

• Смотреть видео
• Что расширения для зашифрованных медиа показывают странице
• Какие сигналы DRM сайт читает без запроса
• Почему VPN, приватные окна и расширения не меняют эти ответы
• Где сигналы DRM находятся среди других признаков платформы
• Как сверить сигналы DRM с выбранным профилем
• Что покрывает BotBrowser и что остается за его пределами

Смотреть видео

В этом англоязычном видео контролируемой локальной лабораторной странице в официальном Google Chrome на двух тестовых машинах, Ubuntu и Windows, задаётся фиксированная матрица из шестнадцати вопросов о DRM. Медиа не загружаются, лицензия не запрашивается. Десять ответов успешны, шесть отклонены, а обе машины дают один и тот же дайджест таблицы, 4753cab0, поэтому видео показывает только то, как ответы сочетаются между собой, и ничего не говорит о реальном пользователе. Профиль BotBrowser и прокси не используются. Звук английский.

Что расширения для зашифрованных медиа показывают странице

Расширения для зашифрованных медиа, сокращенно EME, это спецификация W3C, которая позволяет веб-странице работать с модулем расшифровки контента (CDM) для воспроизведения защищенного аудио и видео. Стриминговые сервисы используют ее, чтобы поток с лицензией воспроизводился в обычной вкладке без плагинов. Самый известный CDM, Widevine, входит в состав Chrome и большинства браузеров на основе Chromium. Для других платформ существуют другие системы ключей, и одна из них, Clear Key, описана в самой спецификации, чтобы любой соответствующий ей браузер мог предложить общую основу. BotBrowser может сохранять согласованными значения медиавозможностей одного профиля в контролируемом контексте, но не может добавить DRM-систему или лицензионный сервис, которых нет в сборке и на платформе.

Чтобы узнать об этом механизме, странице не нужно ничего воспроизводить. Перед запросом лицензии страница спрашивает браузер, может ли он работать с определенной системой ключей и набором медиаконфигураций. Такой вопрос входит в обычное воспроизведение, а ответ помогает стриминговому плееру выбрать между вариантами контента. Тот же вопрос может задать и скрипт без всякого плеера, без запроса разрешений и без видимых изменений на экране.

Центральный вызов, navigator.requestMediaKeySystemAccess, принимает имя системы ключей и список запрошенных конфигураций. Если браузер может удовлетворить хотя бы одну конфигурацию, промис завершается объектом MediaKeySystemAccess. Если нет, промис отклоняется. Оба исхода несут информацию, а скрипт может за считаные мгновения повторить вызов с множеством разных конфигураций. Вызов доступен только в защищенных контекстах, то есть на практике на обычной странице HTTPS.

Поэтому данные о возможностях DRM уместны в любом серьезном разговоре о фингерпринтинге браузера. Сам по себе результат не является устойчивым идентификатором. Многие используют ту же операционную систему и ту же версию Chrome и дадут те же ответы. Зато результат дает набор сведений о платформе и оборудовании, которые трудно получить другими API, и этот набор дополняет картину, которую сайт складывает из множества сигналов.

Какие сигналы DRM сайт читает без запроса

В то, что может узнать скрипт, вносят вклад несколько частей поверхности EME. Их стоит разделять, потому что каждая меняется по своим причинам и требует отдельной проверки.

• Поддержка систем ключей. Widevine, Clear Key, PlayReady и FairPlay называются каждая своей строкой системы ключей. Какие из них принимает браузер, во многом зависит от операционной системы и сборки браузера. Браузер, который принимает систему ключей, привязанную к одной платформе, многое сообщает странице о среде, где он работает.
• Уровни надежности. Для Widevine запрошенная конфигурация может указывать уровень надежности: программное шифрование, программное декодирование, аппаратное шифрование, аппаратное декодирование или полная аппаратная защита. Принятие уровня отражает, сколько аппаратной защиты обеспечивают устройство и CDM.
• Матрица кодеков DRM. Кодеки, которые система ключей принимает в защищенной конфигурации, не всегда совпадают с теми, что браузер сообщает для обычного воспроизведения. Сочетание контейнера, кодека и уровня надежности, которое срабатывает, образует собственную небольшую таблицу.
• Типы сессий и типы данных инициализации. Конфигурация перечисляет поддерживаемые типы сессий и принимаемые форматы данных инициализации, например общий формат шифрования для контента MP4. Временные и постоянные сессии это разные возможности.
• Объекты конфигурации. Когда запрос успешен, getConfiguration() возвращает конфигурацию, которую браузер действительно принял. Объект включает принятые возможности и требования distinctiveIdentifier и persistentState. Такие детали, как порядок и точный набор полей этого объекта, могут различаться на разных платформах.

Каждый из этих сигналов легко запросить и дешево повторить. Скрипт может запросить десятки сочетаний и записать, какие из них завершились успешно. Справочник MDN по requestMediaKeySystemAccess описывает параметры и поведение при отклонении, а спецификация W3C определяет словарь конфигурации, который возвращает успешный запрос.

Clear Key заслуживает отдельного замечания. Поскольку его определяет спецификация, ответить за него может любой соответствующий ей браузер, поэтому он служит исходной точкой, а не признаком платформы. В проверке согласованности он нужен как контроль: если Clear Key отвечает нормально, а система ключей, привязанная к платформе, ведет себя странно, проблема лежит в слое DRM, а не в странице или сети. Возвращаемые им детали, например поддерживаемые типы данных инициализации, все же могут немного отличаться между сборками браузера.

Для вас важно слово «тихо». Ни один из этих запросов не показывает уведомление, не требует действия пользователя и не оставляет видимого следа. Страница может выполнить их во время загрузки. Спецификация W3C содержит соображения о приватности: открытые возможности и идентификаторы могут помогать узнавать пользователя, и именно это беспокойство лежит в основе темы.

Важно также точно понимать, чего эти сигналы не делают. Данные о возможностях DRM не называют человека и сами по себе не выделяют одно устройство среди миллионов. Они сужают круг. Сайт, который объединяет их с признаками экрана, шрифтов, аудио, кодеков и сети, получает куда более четкую картину, чем от любого сигнала по отдельности. Именно в этом смысле запросы DRM вносят вклад в идентификацию, и только в этом смысле здесь используется термин.

Почему VPN, приватные окна и расширения не меняют эти ответы

Повторите ту же конфигурацию requestMediaKeySystemAccess() до и после смены маршрута: поля keySystem и robustness остаются локальными характеристиками.

Тот, кто заботится о приватности, часто сначала обращается к VPN, приватному окну или расширению браузера. Все три разумны для других задач, и ни одно не затрагивает описанные выше сигналы.

VPN меняет сетевой маршрут и видимый IP-адрес. Запрос возможностей EME никогда не использует сеть. Он обращается к браузеру, браузер обращается к установленному CDM, и ответ рождается из программной и аппаратной части локальной машины. Включение или выключение VPN, как и смена страны, не меняет ни набор присутствующих систем ключей, ни уровни надежности, которые способно обеспечить устройство.

Приватное окно меняет то, как браузер хранит cookie, историю и данные сайтов в течение сессии. Оно не устанавливает и не удаляет CDM и не меняет оборудование. Поддержка систем ключей, уровни надежности и матрица кодеков в приватном окне такие же, как в обычном. Приватный режим хорошо защищает от узнавания по cookie, но данные о возможностях DRM не являются сохраненным состоянием, поэтому очищать нечего.

Расширения самый соблазнительный и самый слабый вариант. Расширение, которое полностью блокирует API, ломает и все сервисы, зависящие от защищенного воспроизведения, а отсутствие API само по себе заметный и необычный выбор. Расширение, которое переписывает возвращаемые значения в скриптах страницы, обязано сохранять согласованность каждого ответа со всеми остальными, включая объекты, возвращаемые getConfiguration(), и не может добавить или убрать встроенную поддержку CDM. Такая правка на уровне скрипта обычно дает смесь, которую не сообщил бы ни один настоящий браузер, и это более заметно, чем исходный ответ.

По той же причине замены одного значения недостаточно. Конфигурация, которая заявляет аппаратную защиту на платформе без нее или перечисляет систему ключей другой операционной системы, внутренне противоречива. Согласованность всего набора ответов важнее любого отдельного ответа, и это в равной мере относится к данным о кодеках. Связанная статья о фингерпринтинге MIME и кодеков подробнее рассматривает сторону кодеков.

Удобный способ запомнить разделение: сетевые инструменты меняют то, откуда сессия якобы приходит, средства управления хранилищем меняют то, что сессия помнит, и ни то ни другое не меняет того, на что способны машина и сборка браузера. Данные о возможностях DRM описывают именно то, на что способны машина и сборка. Сдвинуть их может только изменение идентичности платформы, которую сообщает браузер, примененное сразу ко всем поверхностям.

Где сигналы DRM находятся среди других признаков платформы

Записывайте major-версию рядом с каждым результатом getConfiguration(), persistentState и distinctiveIdentifier, чтобы отличить обновление от изменения профиля.

Браузер показывает странице единую среду, и данные DRM это одно из мест, где она может перестать быть единой. Строка user agent, строка платформы, заявленные шрифты, звуковой стек, рендерер WebGL и набор возможностей DRM описывают одну и ту же машину. Когда они описывают разные машины, у сайта есть простая причина счесть сессию необычной.

Представьте сессию, которая заявляет идентичность настольной Windows, но работает на хосте Linux. Если изменены только видимые строки, поверхность DRM все еще может отражать хост. Системы ключей, уровни надежности и типы сессий могут следовать платформе хоста, тогда как все остальное указывает на Windows. Странице не нужна хитрость, чтобы это заметить. Ей достаточно сравнить два ответа.

То же рассуждение применимо к версиям браузера. Widevine и браузер получают обновления, и набор поддерживаемых уровней надежности и кодеков может меняться вместе с ними. Поэтому заявленная версия браузера и заявленный набор возможностей DRM должны относиться к одному периоду. Сочетание свежей идентичности браузера с ответами DRM старой сборки дает еще одно несоответствие, которое легко заметить.

Хорошее сравнение дает аудио. Статья об аудио-фингерпринтинге описывает, как одна и та же процедура дает разные результаты на разных звуковых стеках. DRM работает похоже: один и тот же вопрос получает разные ответы на разных платформах, а на одной платформе ответы стабильны. Стабильность делает сигнал полезным для узнавания, и она же придает смысл проверке согласованности.

Поэтому данные DRM следует считать частью идентичности платформы, а не отдельной настройкой. Профиль, описывающий платформу, должен описывать и ее поведение DRM как одну из частей. Правка отдельных ответов о возможностях вручную, по одному, оставляет слишком много мест, где картина может противоречить сама себе.

Мобильные платформы добавляют еще один слой. Профиль устройства Android описывает платформу, где аппаратная защита встречается часто, тогда как многие настольные и виртуальные среды не могут обеспечить самые высокие уровни надежности. Поверхность DRM, заявляющая аппаратное декодирование на хосте, который его явно не поддерживает, это несоответствие, которое выявляет один запрос. При выборе профиля сравните его платформу с оборудованием, на котором вы реально работаете, и считайте любой заметный разрыв поводом для проверки, а не надейтесь, что он исчезнет сам.

Как сверить сигналы DRM с выбранным профилем

Проверка начинается с письменного перечня того, что заявляет загруженный профиль. Платформа, основная версия браузера и источник профиля это три факта, от которых зависят все последующие проверки. Когда они записаны, поверхность DRM можно сравнивать с ними воспроизводимо.

1. Сначала назовите платформу профиля. Запишите операционную систему, которую описывает профиль, и системы ключей, которых вы ожидаете на этой платформе. Система ключей, привязанная к другой операционной системе, не должна появляться, а система ключей, которую предлагают все браузеры этой платформы, не должна отсутствовать.
2. Выполните запросы возможностей для каждой системы ключей. Опросите Widevine и Clear Key небольшим набором конфигураций и запишите, какие завершились успешно, а какие были отклонены. Держите конфигурации одинаковыми от запуска к запуску, чтобы различия в выводе были настоящими.
3. Сравните уровни надежности. Запросите по очереди каждый уровень надежности Widevine и запишите принятые. Принятый набор должен соответствовать аппаратному уровню, который описывает профиль, и не должен превышать того, что эта платформа может правдоподобно предложить.
4. Прочитайте объекты конфигурации. Для каждого успешного запроса прочитайте, что возвращает getConfiguration(), и запишите типы данных инициализации, возможности аудио и видео, типы сессий и значения distinctiveIdentifier и persistentState. Они должны выглядеть как вывод платформы, которую описывает профиль.
5. Повторите после перезагрузок и перезапусков. Перезагрузите страницу, закройте браузер, запустите его снова с тем же профилем и выполните те же запросы. Результаты каждый раз должны быть одинаковыми. Результат, который меняется между запусками, указывает на проблему конфигурации, а не на свойство платформы.
6. Сравните запуски с интерфейсом и без него. Если вы используете оба режима, выполните в каждом те же запросы и сравните их. Различия стоит изучить, потому что CDM, присутствующий в одном режиме и отсутствующий в другом, виден любой странице, которая спросит.

Храните результаты в короткой таблице рядом с названием профиля. Когда последующее изменение профиля, версии браузера или среды хоста меняет результат, таблица показывает, какой ответ сдвинулся. Просматривайте ее заново после каждого обновления браузера, потому что поверхность DRM может меняться с новым выпуском.

Разбирайте сбои по категориям. Система ключей, отсутствующая на платформе, где она должна быть, обычно означает, что CDM не установлен или не найден. Система ключей, присутствующая там, где ее быть не должно, указывает на расхождение между профилем и хостом. Уровень надежности, принятый при одном запуске и отклоненный при следующем, говорит о том, что среда изменилась между запусками, например сменилась версия CDM или режим запуска. Запись категории сбоя делает следующий шаг очевидным и сокращает расследование.

Эта проверка лишь сравнивает ответы DRM с профилем. Она не проверяет, станет ли конкретный стриминговый сервис воспроизводить контент. Воспроизведение зависит от CDM, сервера лицензий и политики сайта, и ничто из этого не входит в сравнение возможностей. Чистый результат здесь означает, что сигналы согласованы, и не более того.

Что покрывает BotBrowser и что остается за его пределами

BotBrowser поддерживает управляемое профилем сообщение о возможностях DRM, так что системы ключей EME, уровни надежности, типы сессий и поддержка кодеков DRM, которые может запросить страница, сообщаются согласованно с идентичностью платформы загруженного профиля, а документация BotBrowser по DRM указывает, что для этого отдельный флаг CLI не нужен. Так у вас появляется определенная основа для проверки описанными выше шагами без ручной правки отдельных ответов. BotBrowser не может поставлять или включать в комплект CDM Widevine, расшифровывать защищенный контент, гарантировать воспроизведение или одобрение лицензии, а также контролировать собственную политику DRM сайта и его решения об обнаружении.

Воспроизведение и согласованность являются разными задачами. Чтобы воспроизводить защищенный контент, нужен CDM Widevine, полученный через официальные каналы, и сопутствующая лицензия, и ничто из этого не поступает от браузера. Руководство по настройке Widevine DRM описывает сторону настройки, а документация BotBrowser о согласованности отпечатка DRM объясняет, как сообщение о возможностях следует за профилем. Когда сеанс отклонён, обзор возможностей DRM разделяет четыре проверки, которые решают, в чём причина: модуль, уровень устойчивости, путь вывода или лицензия.

При планировании теста держите два вопроса раздельно. Первый: совпадает ли поверхность DRM с профилем, на что отвечает перечень выше. Второй: воспроизводит ли конкретный сервис контент для конкретной учетной записи, что зависит от сервиса. Сессия может пройти первое и все же не пройти второе по причинам, не связанным с браузером.

В плане тестирования записывайте, на какой из двух вопросов отвечает каждый тест, и храните доказательства для каждого отдельно. Отчет о согласованности перечисляет системы ключей, уровни надежности, поля конфигурации и число совпавших запусков. Отчет о воспроизведении перечисляет сервис, тип учетной записи и источник CDM. Смешение двух отчетов затрудняет отнесение сбоев к правильной причине.

Что добавлено по сравнению со справочной страницей

Справочная страница называет поверхности EME. Добавленное сравнение отдельно записывает поддержку key system, устойчивость, настройки кодеков и воспроизведение. VPN, приватное окно или расширение не превращают ответ лицензии в возможность браузера.

Источники

• W3C: спецификация EME
• MDN: Navigator.requestMediaKeySystemAccess()
• Документация BotBrowser: согласованность отпечатка DRM
• Widevine в автоматизированных браузерах

Практический итог

Ведите два отчёта: согласованность (системы ключей, уровни надёжности, поля конфигурации) и воспроизведение (лицензия, CDM, политика сервиса). Расхождение первого с профилем указывает на профиль или хост, а отказ второго при совпавшем первом на сервис, а не на возможности браузера.