Encrypted Media Extensions в Google Chrome: что это?

Продолжая свою борьбу за безопасность и приватность пользователей, Google Chrome внедрил технологию Encrypted Media Extensions (EME) в своем браузере. Эта технология позволяет защищать контент, который требует защиты авторских прав, используя шифрование.

Что такое Encrypted Media Extensions?

Encrypted Media Extensions (EME) — это спецификация W3C, разработанная для поддержки защищенного видео и аудио контента в веб-браузерах. Она позволяет создавать надежные видео плееры, поддерживающие шифрование контента.

EME является ключевым компонентом воспроизведения цифрового контента с защищенными авторскими правами в веб-браузерах. Благодаря EME, контент-провайдеры могут распространять и защищать свой контент, а пользователи более безопасно просматривать его.

Как работает Encrypted Media Extensions?

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

Когда пользователь открывает веб-страницу с защищенным контентом, EME в браузере Chrome автоматически запускается и проверяет, есть ли установленный DRM модуль, способный обрабатывать защищенный контент на устройстве. Если такой модуль есть, то EME запрашивает у него ключи для расшифровки контента и доступа к нему.

Поддерживаемые DRM модули

Google Chrome поддерживает несколько DRM модулей, включая:

• Widevine: разработанный Google, Widevine является одной из самых распространенных и широко используемых DRM систем.
• PlayReady: разработанный Microsoft, PlayReady также является популярным DRM решением, особенно в операционных системах Windows.
• FairPlay: разработанный Apple, FairPlay используется для защиты контента на устройствах Apple, таких как iPhone и iPad.

Защита авторских прав

С помощью Encrypted Media Extensions, веб-разработчики и контент-провайдеры могут защитить свой цифровой контент от несанкционированного доступа и распространения. Это позволяет им контролировать его использование и распространение, а также устанавливать политики ограничения для просмотра контента.

EME также позволяет веб-разработчикам создавать более удобные и безопасные плееры, которые поддерживают стандарты DRM и имеют полный контроль над своим контентом.

Заключение

Encrypted Media Extensions в Google Chrome открывают новые возможности для защиты и контроля цифрового контента с авторскими правами. Благодаря поддержке различных DRM модулей, пользователи могут безопасно просматривать зашифрованный контент, а веб-разработчики могут создавать плееры, которые соответствуют стандартам DRM и предоставляют безопасный способ воспроизведения защищенного контента.

• Можно ли обрабатывать трейнер хлоргексидином? Если нет, то чем?
• Что входит в состав трамадола?
• Вопрос по Холдем Покеру
• Metro Exodus, помогите пожалуйста.
• Как ругать щенка без рукоприкладства?
• Вопрос простой. Что за группа получилась?

• Ложь. — Что в нее входит?
• Сколько у нас известных политиков! А кого из них можно назвать ВОЖДЕМ, тем, за кем могут пойти соратники и широкие народ

Организация хостинга зашифрованного видеоконтента с помощью HTML5

Не так давно на хабре обсуждалась новая инициатива от W3С — Encrypted Media Extensions или просто EME. Попробуем же разобраться на практике, что нового и интересного нам предлагают.

Итак, задача: предположим, что есть куча интересного видеоматериала, которую хочется выложить в интернет, но не для всех, а только для хороших людей (для друзей, знакомых,… или просто за денежку). Так вот, инициатива Encrypted Media Extensions как раз и предлагает добавить весь необходимый API для клиентской части в стандарт HTML. Помимо этого в предложении от W3C рассматриваются и другие вопросы, такие как злополучный DRM, но мы их пока отложим, остановившись исключительно на клиентской части организации нашего гипотетического сервиса. Обязательное условие — поддержка браузером спецификации EME, а значит, поддерживается и базовая ключевая система Clear Key.

Итак, есть тег video и файл foo.webm , видео и аудио в котором зашифровано с помощью алгоритма AES (такая возможность поддерживается в контейнере WebM, и авторы EME воспользовались этим):

В данной ситуации EME-браузер при попытке воспроизвести foo.webm обнаружит, что контент зашифрован, остановится и будет ждать, когда ему предоставят ключ для дешифровки. Вообще, основной вариант использования (use case) состоит в том, что информация о том, как зашифрован контент, описывается прямо в контейнере; воспользуемся именно таким вариантом. Кроме того, что браузер остановится, он еще и возбудит событие needkey на самом элементе HTMLMediaElement, а приложению следует его обработать и, в конечном итоге, предоставить ключ:

Функция handleKeyNeeded() будет не очень сложной — она получает идентификатор ключа, который нужен браузеру, затем делает XHR-запрос на сервер и отдает ответ=ключ браузеру обратно (или не отдает, если того требует ситуация — это уже бизнес-логика). Мы немного упростим — пусть ключ уже у нас есть; для схемы , которую мы используем, это будет массив Uint8Array из 16 байт; тогда функция выглядит так:

function handleKeyNeeded(event) < var video = event.target; var initData = event.initData; //var message = initData; //var xmlhttp = new XMLHttpRequest(); //xmlhttp.open("POST", "http://. /getkey", false); //xmlhttp.send(message); //var key = new Uint8Array(xmlhttp.response); var key = new Uint8Array([0xeb, 0xdd, 0x62, 0xf1, 0x68, 0x14, 0xd2, 0x7b, 0x68, 0xef, 0x12, 0x2a, 0xfc, 0xe4, 0xae, 0x3c]); if (!video.keys) video.keys = video.MediaKeys("org.w3.clearkey"); if (!video.keys) throw "Could not create MediaKeys"; var keySession = video.keys.createSession(mimeType, initData); if (!keySession) throw "Could not create key session"; keySession.update(key); >

Основные действующие лица здесь:

• event.initData : идентификатор, соответствующий ему ключ нужен браузеру;
• key : собственно ключ для дешифровки;
• keySession.update(key) : этим вызовом браузер получает тот самый ключ; большего от страницы и не требуется.

Те, кому интересен остальной код функции handleKeyNeeded() (классы MediaKeys, MediaKeySession и т.д.), могут воспользоваться свежим переводом будущей спецификации EME, выполненной с помощью сервиса Catbo.

Таким образом, если бы у нас был браузер с поддержкой EME (текущей версии 2), то на странице encrypted_media_player_v2.html мы бы обнаружили на видео черного медведя, прохаживающегося по клетке (образец зашифрованного видео bear-320×240-av-enc_av.webm взят из кода Chromium). На момент написания этой статьи такого браузера, с высокой долей вероятности, нет. Однако, если чуть доработать код страницы, то медведя все-таки можно будет увидеть, воспользовавшись браузерами Google Chrome или Chromium версии 26 или выше (пока поддержка обнаружена только в них): encrypted_media_player.html.

Далее мы рассмотрим, какие доработки пришлось сделать, чтобы наш пример заработал. Во-первых, сейчас в Chrome/Chromium поддерживается 1-я версия будущей спецификации EME, от которой уже отказались авторы EME в пользу версии 2, сделав последнюю объектно-ориентированной. Однако в Chrome/Chromium включена пока только первая версия EME; кроме того, во многих местах надо навесить префикс webkit ; из-за этого функция handleKeyNeeded() изменится следующим образом:

function handleKeyNeeded(event) < . var keySystem = "webkit-org.w3.clearkey"; video.webkitGenerateKeyRequest(keySystem, event.initData); // добавление ключа video.webkitAddKey(keySystem, key, event.initData, null); >

Во-вторых, если сейчас напрямую устанавливать атрибут src тега video , то события needkey мы не дождемся. Дело в том, что в этом случае видео воспроизводится стоковым функционалом ffmpeg, который задействован в браузере, а тот не обращает внимания на всякие флаги зашифрованности в контейнере (далее идет немного технических подробностей о реализации медиа-стека именно в Chrome/Chromium). А вот если воспользоваться другим способом предоставления контента проигрывателю, то получим нужный нам результат (возбуждение события needkey ). Этот другой способ имеет название Media Source Extensions; его суть заключается в том, что коду JavaScript позволяется генерировать медиапоток для последующего воспроизведения. На деле это означает, что в браузерах от Google появилась альтернативная реализация demuxer-ов, таких как WebM и mp4; вот их-то и научили возбуждению необходимого нам события needkey. Вот соответствующий код загрузки видео с медведем в наш тег video :

function load() < var video = document.getElementById("video"); var mediaFile = "bear-320x240-av-enc_av.webm"; //video.src = mediaFile; var sourceOpened = false; function onSourceOpen(e) < if (sourceOpened) return; sourceOpened = true; var mediaType = 'video/webm; codecs="vorbis, vp8"'; var srcBuffer = mediaSource.addSourceBuffer(mediaType); var xhr = new XMLHttpRequest(); xhr.open('GET', mediaFile); xhr.responseType = 'arraybuffer'; xhr.addEventListener('load', function(e) < srcBuffer.append(new Uint8Array(e.target.response)); mediaSource.endOfStream(); >); xhr.send(); > var mediaSource = new WebKitMediaSource(); mediaSource.addEventListener('webkitsourceopen', onSourceOpen); video.src = window.URL.createObjectURL(mediaSource); . > 

Конечно же, этот код менее универсален, чем простое присваивание

video.src = "bear-320x240-av-enc_av.webm"; 

; более того, будущая спецификация EME не требует подобных ухищрений (но пока добиться работоспособности возможно только таким путем). Ждем дальнейшего развития событий.

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

Независимые браузеры более не конкурентоспособны

В 2017 году консорциум W3C принял стандарт Encrypted Media Extensions (EME), тем самым положив конец конкуренции со стороны независимых браузеров.

Теперь невозможно выпустить свой браузер, который будет воспроизводить некоторые из самых популярных материалов в интернете. Сайты вроде Netflix, Hulu, HBO и др. требуют защиты лицензионного контента. Доступ к ним возможен только по лицензионному соглашению с крупными корпорациями.

Во время разработки своего браузера Metastream я упёрся в стену, когда Google отклонил мою заявку на использование их DRM-движка Widevine для воспроизведения зашифрованного медиа. Эта проблема затрагивает и других разработчиков, и обойти её невозможно.

Подобные технологические блокировки введены в первую очередь для того, чтобы успокоить медиаиндустрию.

Капитализм, распространение медиа и пиратство

Все хотят зарабатывать, а дистрибьюторы вроде Netflix зарабатывают на продаже доступа к своему контенту. Конечно, если вы продаёте контент, кто-нибудь захочет получить его бесплатно.

Чтобы защититься от цифровых пиратов, дистрибьюторы используют инструменты под названием Digital Rights Management (DRM).

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

Это может показаться разумным в том смысле, что ценный товар должен быть оплачен, но DRM зачастую вызывает дополнительные проблемы для потребителей и авторов контента.

DRM в браузерах

Браузеры в первую очередь стремятся обеспечить всеобщий доступ к контенту в Сети. Блоги, социальные сети, видео, музыка, фотографии и т.д. Расцвет интернета стал возможен благодаря открытой веб-платформе (Open Web Platform).

Открытая веб-платформа — это совокупность открытых (бесплатных) технологий, которые позволяют работать в интернете. Используя открытую веб-платформу, каждый имеет право реализовать программный компонент веб-сайта, не требуя каких-либо согласований или выплаты лицензионных платежей.

Консорциум World Wide Web (W3C) занимается стандартизацией этих технологий, помогая им распространиться в открытом вебе.

До недавнего времени всё работало хорошо. Универсальный доступ ко всей информации осуществлялся через браузеры, такие как Firefox, Chrome, Safari и многие другие. Но с 2013 года W3C начал попытки стандартизировать DRM в веб-браузерах — при поддержке Google, Microsoft и Netflix — внедряя технологию, противоположную открытой веб-платформе.

Исторически, зашифрованный контент воспроизводился в браузерах плагинами вроде Adobe Flash и Microsoft Silverlight. Это привело к дырам в безопасности вне контроля разработчиков браузеров. Чтобы устранить эти проблемы и включить больше технологий в открытую веб-платформу, W3C предложил стандарт Encrypted Media Extensions (EME).

Encrypted Media Extensions (EME) обеспечивает совместимость, лучшую конфиденциальность, безопасность, доступность и удобство просмотра фильмов в интернете.

EME предоставляет общий API, который используется для обнаружения, выбора и взаимодействия с модулями расшифровки контента (Content Decryption Modules, CDM). Браузер должен предоставить совместимый CDM для воспроизведения зашифрованного контента.

Выбор CDM

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

Мы хотим, чтобы эта функция работала на всех сайтах, поэтому нужно предоставить CDM для таких сайтов, как Netflix. Если мы этого не сделаем, пользователям придётся постоянно переключаться на другой браузер только для этих сайтов. Нехорошо.

Скорее всего, у вашего текущего браузера есть модуль CDM. Посмотрим, какой именно.

Браузер	CDM
Chrome	Widevine
Firefox	Widevine
Safari	FairPlay
Edge	PlayReady и Widevine
Internet Explorer	PlayReady
Opera	Widevine
Brave	Widevine
Vivaldi	Widevine
Yandex	Widevine

Мы видим, что есть несколько вариантов: Widevine, PlayReady и FairPlay. Чтобы легально распространить один из этих CDM, мы должны подать заявку.

Google Widevine

На странице контактов Widevine мы видим ссылку на службу поддержки для заключения лицензионного соглашения. Форма запрашивает основную контактную информацию и требует указать название компании.

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

А теперь… мы ждём. Возможно, больше четырёх месяцев, как я. Или они пришлют лицензионное соглашение, но затем будут игнорировать вас в течение года.

Даже разработчики Brave — браузера от создателя JavaScript — столкнулись с подобными паузами в общении.

И если нам когда-нибудь пришлют лицензионное соглашение, согласно castLabs (сертифицированный партнёр по внедрению Widevine), Google ещё должна удостоверить аутентичность нашего браузера, прежде чем мы сможем использовать модуль CDM.

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

Microsoft PlayReady

Система Microsoft PlayReady требует собственных соглашений, которые чётко прописаны в разделе «Распространение загружаемого программного приложения для конечных пользователей» на странице лицензирования PlayReady.

Там много бумажной работы, но они хотя бы устанавливают временны́е рамки для всего процесса. 22 дня звучит гораздо разумнее, чем неизвестное количество времени.

Однако уже в промежуточном лицензионном соглашении (Intermediate Product License) упоминается поставка комплекта «PlayReady Device Porting Kit и PlayReady Documentation Pack» с предоплатой в размере $10 000. В случае продажи программного обеспечения конечным пользователям также взимается роялти в размере $0,35 за каждый экземпляр программы.

Apple FairPlay Streaming

По всей экосистеме Apple используется запатентованный CDM. Похоже, на сайте FairPlay нет никакой программы открытого лицензирования. В данный момент, перейдя по ссылке FairPlay Streaming Overview и войдя в систему с идентификатором Apple ID, мы видим ответ сервера HTTP 403 Forbidden.

Создание нового CDM

Но подождите, поскольку это Open Web, можно ведь просто создать свой собственный CDM! Из разъяснения W3C по поводу реализаций EME:

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

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

Обзор архитектуры Widevine DRM даёт более полную картину того, каких усилий требует создание полноценной системы. Трудно представить, что какой-то один человек или малый бизнес способен самостоятельно обеспечить воспроизведение DRM во всех веб-сервисах, которые его требуют.

Итак, какие у нас варианты?

В итоге есть два варианта: Widevine или PlayReady.

С Widevine мы застрянем на неопределённый срок в неизвестности, согласятся ли они предоставить своё решение.

В PlayReady нужно внести предоплату $10 000.

Вывод

После внедрения стандарта EME конкурентоспособность браузеров ограничена контролёрами-посредниками, что идёт вразрез с обещанием платформы Open Web:

Используя открытую веб-платформу, каждый имеет право реализовать программный компонент веб-сайта, не требуя каких-либо согласований или выплаты лицензионных платежей.

Да, стандарт EME может быть реализован кем угодно, но это спорный тезис, если требование CDM говорит об обратном.

Барьеры DRM затронули ряд браузерных приложений. Некоторые из них перечислены ниже:

• Brave — задержки в коммуникациях по Widevine.
• ElectronPlayer — нет ответа по Widevine.
• Fenêtre — нет ответа по Widevine.
• Metastream — отказ Widevine.
• Min
• Pennywise
• Wexond — нет ответа по Widevine.
• Если вы знаете о каких-то других проектах, добавляйте их в список пул-реквестом.

В конечном счёте, лучшее решение для общества — а не для прибыли — это вообще отказаться от DRM. Поскольку это маловероятно, Google, Microsoft и Apple должны работать над исправлением веб-платформы, которую они повредили.

Дополнительная литература

• W3C и совместимость. Защита будущего от настоящего
• Формальное возражение: новые браузеры и EME
• «Мысли о музыке» — Стив Джобс (2007)

При подготовке материала использовались источники:
https://sovet-kak.ru/a/encrypted-media-extensions-v-google-chrome-chto-eto
https://habr.com/ru/articles/176115/
https://habr.com/ru/post/485918/?ref=tjournal.ru