Это очень трогательная тема. Я попытался представить контекст, но не ставьте вопрос на технический вопрос, а на дискуссию о праве-против-неправильном. Пожалуйста, поддержите ту сторону обсуждения, которую вы предпочитаете, с вашим кошельком и ногами, а не в комментариях или ответах.Является ли EME только тегом <object> с шифрованием?
Encrypted Media Extensions draft от 7 января 2014, составители настаивают (курсив мой):
Данная спецификация не определяет защиту контента или системы управления цифровыми правами. Скорее, он определяет общий API, который может использоваться для обнаружения, выбора и взаимодействия с такими системами, а также с более простыми системами шифрования контента. Внедрение управления цифровыми правами не требуется для соответствия этой спецификации.
Вместо этого они говорят:
Общий API поддерживает простой набор возможностей шифрования контента, оставляя функции приложения, такие как аутентификация и авторизация на авторов страниц. Это достигается за счет того, что для обеспечения оповещения о защите сообщений, зависящей от конкретной системы, должна использоваться система передачи сообщений, а не для внеполосной связи между системой шифрования и лицензией или другим сервером.
Но я полагаю, что EME что everyoneisupinarms о том, когда они говорят, что W3C 'внедряет DRM' в HTML 5.
Мое (ограниченный) понимание спецификации является :
Он определяет общий крючок для аутентификации доступа к медиафайлу на HTML-странице. Аутентификация будет выполняться на стороне сервера, а не на стороне клиента («оставляя функции приложения, такие как аутентификация и авторизация авторам страниц»), но через HTTP («требуется, чтобы сообщения, защищенные системой защиты данных, были опосредованы страницей, из-за полосы связи "). Одно очевидное использование, а мотивация для EME (цитата необходима?) - ориентированная на потребителя DRM. [1]
Предполагаемый эффект: replace client-side media wrappers (Flash, Silverlight...) с простым подключением к серверным провайдерам аутентификации.
[1] Могут ли быть другие, ориентированные на безопасность приложения EME?
Итак, если предположить, я получил все, что право, я правильно, что this ...
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="550" height="400" id="movie_name" align="middle">
<param name="movie" value="movie_name.swf"/>
<!--[if !IE]>-->
<object type="application/x-shockwave-flash" data="movie_name.swf" width="550" height="400">
<param name="movie" value="movie_name.swf"/>
<!--<![endif]-->
<a href="http://www.adobe.com/go/getflash">
<img src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif" alt="Get Adobe Flash player"/>
</a>
<!--[if !IE]>-->
</object>
<!--<![endif]-->
</object>
(где SWF-файл навязывает DRM через внутреннюю, коду на стороне клиента и/или крюки на серверную аутентификацию, выполненную в браузере через Flash)
будет заменен чем-то вроде этого (адаптировано от html5media.info)? [2]
<video src="movie_name.mp4" eme="some_drm_key_or_something_here"
width="550" height="400" controls preload id="movie_name"></video>
[2] Но где хранится файл, и как долго?
TL; DR Игнорирование или нет DRM этично/хороший бизнес/боль, является EME средством формализации механизма поставщика нейтрального, сервера зависит, нет-плагинов-требуется для аутентификации доступ к медиафайлам? Реализация может, например, добавлять атрибуты к существующим тэгам HTML5, и до тех пор, пока браузер может: a) аутентифицировать и b) воспроизвести формат файла, носитель будет доступен для просмотра.