Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
Но с другой стороны, отсутствие поддержки DRM у HTML5 Video — это одна из причин, почему Youtube не может полностью отказаться от флеша. У каждой медали две стороны.
Простите, а какая связь между флешем и DRM? Насколько я помню с ютуба можно свободно сливать любое видео посредством определенных сайтов. Или там есть какое-то видео закодированное с помощью DRM?
Например Youtube Rentals для реализации которого в том числе нужна защита контента. Сейчас это делается при помощи RTMPE ибо при помощи HTML5 это сделать попросту невозможно.
Вот например нагугленное про Youtube rentals и DRM: tech-freedom.blogspot.com/2011/07/youtube-rentals-use-drm-to-block.html
Вот например нагугленное про Youtube rentals и DRM: tech-freedom.blogspot.com/2011/07/youtube-rentals-use-drm-to-block.html
Ну и пруф с блога ютуба про Content Protection:
apiblog.youtube.com/2010/06/flash-and-html5-tag.html
apiblog.youtube.com/2010/06/flash-and-html5-tag.html
Если мне не изменяет память, то rtmpdump может декодировать такой поток в определенных условиях.
RTMPE это оказывается DRM? А я и не знал, копируя всё видео из /proc//fd/ и сохраняя его в какой-либо файли. Смешно видеть все эти потуги изобретения DRM которые обходятся настолько просто…
Простите, а какая связь между флешем и DRM? Насколько я помню с ютуба можно свободно сливать любое видео посредством определенных сайтов. Или там есть какое-то видео закодированное с помощью DRM?
Это и хорошо. Мнимая защита «для галочки» (потом юристам можно сказать «это всё злые хакеры, а мы старались, защищали как могли») как бы есть и почти все относительно спокойны, а более-менее знающим (хотя в данном случае таки громковато звучит) людям нет проблем скачать при желании. Примерно аналогичная ситуация с CSS-шифрованием на DVD и, вроде как, аналогом на BlueRay. Если впилят в HTML5 достаточно легко обходимую «формальную» защиту — с практической точки зрения не сильно расстроюсь, хотя, идеологически очень неприятно — да, и очень хотелось бы обойтись без этого. Но действия Adobe по отношению к их Flash (отказ от поддержки одной за другой платформ) уже даже самым консервативным по-моему дают понять, что рынку надо срочно слезать с этой иглы (Flash) де-факто.
Копать-молотить!.. :(
Ну, со скоростью работы W3C… Можно не бояться ближайшие лет пять:)
Вы бы сначала спецификацию просмотрели, прежде чем делать выводы — DRM это или нет. Речь идет всего лишь о возможности для всех отдавать один зашифрованный видеопоток, который расшифровать и воспроизвести смогут лишь обладатели ключей. Такая возможность востребована и сейчас ее реализуют кто как может.
Как это связано с защитой от копирования, которой DRM по сути и является, — я не понимаю. Как это сможет причинить неудобства для легальных пользователей — у меня тоже идей нет.
Как это связано с защитой от копирования, которой DRM по сути и является, — я не понимаю. Как это сможет причинить неудобства для легальных пользователей — у меня тоже идей нет.
Всё это уже давно реализовано, достаточно только заменить в вашем посте слово «ключи» на слово «сертификаты». Беда лишь в том, что эти самые сертификаты юзер может устанавливать и переносить с одного компьютера на другой самостоятельно, а вот в случае с DRM такую возможность у него отберут.
Почему отберут? От клиента требуется лишь возможность исполнять javascript. Даже ключи и те хранятся не у клиента, а получаются по требованию от сервера. Например, только авторизованным пользователям. Так что переносить с одного компьютера на другой клиенту фактически нечего.
А чем SSL не устроил? Или потоковое видео нельзя передавать через SSL?
Если можно, то авторизированным пользователям даём видео, перехватить его никто не сможет. Но авторизированный легальный пользователь может, конечно, сохранить это видео на диск. А если новая система призвана не допустить сохранение (копирование), то это и есть очередной DRM.
Если можно, то авторизированным пользователям даём видео, перехватить его никто не сможет. Но авторизированный легальный пользователь может, конечно, сохранить это видео на диск. А если новая система призвана не допустить сохранение (копирование), то это и есть очередной DRM.
> Речь идет всего лишь о возможности для всех отдавать один зашифрованный видеопоток, который расшифровать и воспроизвести смогут лишь обладатели ключей.
Первый абзац: habrahabr.ru/company/intel/blog/138507/#comment_4624917
И зачем всё это?
> Почему отберут? От клиента требуется лишь возможность исполнять javascript.
В каком месте будет находиться указанный на схеме CDM в случае СПО? (Например Firefox и Chromium, не Chrome.) Представитель от Netflix внятного ответа на этот вопрос дать не смог. Посмотрим, как это получится у вас.
Первый абзац: habrahabr.ru/company/intel/blog/138507/#comment_4624917
И зачем всё это?
> Почему отберут? От клиента требуется лишь возможность исполнять javascript.
В каком месте будет находиться указанный на схеме CDM в случае СПО? (Например Firefox и Chromium, не Chrome.) Представитель от Netflix внятного ответа на этот вопрос дать не смог. Посмотрим, как это получится у вас.
> И зачем всё это?
Затем, что стриминг видео контента может стать неплохим бизнесом и возможно даже вытеснить диски. Как я понял, предложенный черновик спецификиции может стать заменой всяческим велосипедам по организации стриминга видео по подписке или с иными видами ограниченного доступа. У разработчика будет API для реализации клиентского приложения на javascript.
> В каком месте будет находиться указанный на схеме CDM в случае СПО?
В том же месте, где находятся кодеки для воспроизведения видео.
Затем, что стриминг видео контента может стать неплохим бизнесом и возможно даже вытеснить диски. Как я понял, предложенный черновик спецификиции может стать заменой всяческим велосипедам по организации стриминга видео по подписке или с иными видами ограниченного доступа. У разработчика будет API для реализации клиентского приложения на javascript.
> В каком месте будет находиться указанный на схеме CDM в случае СПО?
В том же месте, где находятся кодеки для воспроизведения видео.
> Затем, что стриминг видео контента может стать неплохим бизнесом и возможно даже вытеснить диски.
Нет, вы не поняли. И зачем всё это шифровать? (Точнее вопрос сформулирован по ссылке.)
> В том же месте, где находятся кодеки для воспроизведения видео.
Как и ожидалось, внятного ответа не последовало. Проигрыватели DVD и Blu-ray от СПО вынуждены полагаться на незаконные в США libdvdcss и libaacs (чтобы создать которые пришлось приложить немалые усилия в процессе обратной разработки). Где место СПО в стандарте, я вас спрашиваю? (Ключевое слово — «стандарт».)
Нет, вы не поняли. И зачем всё это шифровать? (Точнее вопрос сформулирован по ссылке.)
> В том же месте, где находятся кодеки для воспроизведения видео.
Как и ожидалось, внятного ответа не последовало. Проигрыватели DVD и Blu-ray от СПО вынуждены полагаться на незаконные в США libdvdcss и libaacs (чтобы создать которые пришлось приложить немалые усилия в процессе обратной разработки). Где место СПО в стандарте, я вас спрашиваю? (Ключевое слово — «стандарт».)
> И зачем всё это шифровать?
Напомню, что предложенный черновик спецификации — это не замена HTMLMediaElement, а расширение. Если разработчику не нужно ограничение доступа к его видео — он не обязан использовать шифрование. Если нужно, то шифрование самого контента — самый очевидный способ защиты.
Поправьте меня, если я не прав, но сейчас приходится решать эту проблемы всячески скрывая прямую ссылку на видео поток или генерируюя ее на лету. При этом нет возможности убедиться, что этой ссылкой воспользовался именно тот человек, кому она предназначена. Предложенный в спецификации алгоритм обмена ключами решает эту проблему.
> Где место СПО в стандарте, я вас спрашиваю?
Мне искренне жаль разработчиков проигрывателей DVD и Blu-ray, но сейчас речь не о них. Если вы уделите немного времени на прочтение самой спецификации, то убедитесь, что нет никаких причин считать, что open source разработчики будут ущемлены в правах. Спецификация не предполагает использование зашитых мастерключей, закладок и покупку сертификатов. Она состоит лишь из алгоритма обмена ключами, API под javascript и подразумевает использование стандартных алгоритмов дешифрования, таких как AES.
Напомню, что предложенный черновик спецификации — это не замена HTMLMediaElement, а расширение. Если разработчику не нужно ограничение доступа к его видео — он не обязан использовать шифрование. Если нужно, то шифрование самого контента — самый очевидный способ защиты.
Поправьте меня, если я не прав, но сейчас приходится решать эту проблемы всячески скрывая прямую ссылку на видео поток или генерируюя ее на лету. При этом нет возможности убедиться, что этой ссылкой воспользовался именно тот человек, кому она предназначена. Предложенный в спецификации алгоритм обмена ключами решает эту проблему.
> Где место СПО в стандарте, я вас спрашиваю?
Мне искренне жаль разработчиков проигрывателей DVD и Blu-ray, но сейчас речь не о них. Если вы уделите немного времени на прочтение самой спецификации, то убедитесь, что нет никаких причин считать, что open source разработчики будут ущемлены в правах. Спецификация не предполагает использование зашитых мастерключей, закладок и покупку сертификатов. Она состоит лишь из алгоритма обмена ключами, API под javascript и подразумевает использование стандартных алгоритмов дешифрования, таких как AES.
> Если нужно
Так вы можете ответить, зачем это может быть нужно?
> Поправьте меня, если я не прав, но сейчас приходится решать эту проблемы всячески скрывая прямую ссылку на видео поток или генерируюя ее на лету.
Поправляю. Первый же легальный потребитель, сохранивший файл по своей уникальной ссылке, может делать с этим файлом всё, что угодно. Первый же. Так зачем всё это?
> Она состоит лишь из алгоритма обмена ключами, API под javascript и подразумевает использование стандартных алгоритмов дешифрования, таких как AES.
Следовательно для сохранения файла не понадобиться даже патчить Firefox, а достаточно будет написать плагин, верно? (А может даже аддона хватит?)
> Если вы уделите немного времени на прочтение самой спецификации
Если всё так, то зачем представитель Netflix писал об использовании не-свободных дополнений для расшифровки?
Так вы можете ответить, зачем это может быть нужно?
> Поправьте меня, если я не прав, но сейчас приходится решать эту проблемы всячески скрывая прямую ссылку на видео поток или генерируюя ее на лету.
Поправляю. Первый же легальный потребитель, сохранивший файл по своей уникальной ссылке, может делать с этим файлом всё, что угодно. Первый же. Так зачем всё это?
> Она состоит лишь из алгоритма обмена ключами, API под javascript и подразумевает использование стандартных алгоритмов дешифрования, таких как AES.
Следовательно для сохранения файла не понадобиться даже патчить Firefox, а достаточно будет написать плагин, верно? (А может даже аддона хватит?)
> Если вы уделите немного времени на прочтение самой спецификации
Если всё так, то зачем представитель Netflix писал об использовании не-свободных дополнений для расшифровки?
Я уже ответил, зачем это нужно. При использовании шифрования контента нет смысла прятать ссылку. Ее смогут увидеть все и все смогут скачать файл по этой ссылке. Но это будет зашифрованный файл.
Комментировать, насколько легко будет рядовому пользователю расшифровать файл и сохранить его на диск я не могу и не думаю, что кто-то может — реализации этой спецификации еще нет, соответственно дыр в ее реализации тоже. Если вы найдете предположительные дыры в самой спецификации, то, пожалуйста, сообщайте о них w3c.
> Если всё так, то зачем представитель Netflix писал об использовании не-свободных дополнений для расшифровки?
Спецификация не предполагает использование конкретного алгоритма шифрования. Поэтому я не могу ни подтвердить, ни опровергнуть слова представителя Netflix (если он действительно такое говорил).
Комментировать, насколько легко будет рядовому пользователю расшифровать файл и сохранить его на диск я не могу и не думаю, что кто-то может — реализации этой спецификации еще нет, соответственно дыр в ее реализации тоже. Если вы найдете предположительные дыры в самой спецификации, то, пожалуйста, сообщайте о них w3c.
> Если всё так, то зачем представитель Netflix писал об использовании не-свободных дополнений для расшифровки?
Спецификация не предполагает использование конкретного алгоритма шифрования. Поэтому я не могу ни подтвердить, ни опровергнуть слова представителя Netflix (если он действительно такое говорил).
> Я уже ответил, зачем это нужно. При использовании шифрования контента нет смысла прятать ссылку. Ее смогут увидеть все и все смогут скачать файл по этой ссылке. Но это будет зашифрованный файл.
Вы так и не написали, какой смысл в том, чтобы шифровать и прятать. Ещё раз:
> Первый же легальный потребитель, сохранивший файл по своей уникальной ссылке, может делать с этим файлом всё, что угодно. Первый же.
Вы осознаёте последствия этого и следовательно бессмысленность всех этих «защит»?
> Если вы найдете предположительные дыры в самой спецификации
Mozilla уже сказали своё слово, нормального ответа нет. Ни от кого, от вас в том числе.
> Спецификация не предполагает использование конкретного алгоритма шифрования.
Вне зависимости от этого, картинку можно будет в любом случае записать с видео-выхода, либо с экрана (софтом), либо захватить поток плагином, или аддоном.
Ещё раз прочитайте первый абзац: habrahabr.ru/company/intel/blog/138507/#comment_4624917 (лучше несколько раз).
Обдумайте его. А если контент будет эксклюзивным, его всё равно украдут в первые же часы, перечисленным выше способами.
> Комментировать, насколько легко будет рядовому пользователю расшифровать файл и сохранить его на диск я не могу и не думаю, что кто-то может
Это не важно совершенно. Достаточно одного не-простого пользователя, чтобы остальные уже могли не напрягаясь сливать выложенный им файл по BitTorrent.
Вы так и не написали, какой смысл в том, чтобы шифровать и прятать. Ещё раз:
> Первый же легальный потребитель, сохранивший файл по своей уникальной ссылке, может делать с этим файлом всё, что угодно. Первый же.
Вы осознаёте последствия этого и следовательно бессмысленность всех этих «защит»?
> Если вы найдете предположительные дыры в самой спецификации
Mozilla уже сказали своё слово, нормального ответа нет. Ни от кого, от вас в том числе.
> Спецификация не предполагает использование конкретного алгоритма шифрования.
Вне зависимости от этого, картинку можно будет в любом случае записать с видео-выхода, либо с экрана (софтом), либо захватить поток плагином, или аддоном.
Ещё раз прочитайте первый абзац: habrahabr.ru/company/intel/blog/138507/#comment_4624917 (лучше несколько раз).
Обдумайте его. А если контент будет эксклюзивным, его всё равно украдут в первые же часы, перечисленным выше способами.
> Комментировать, насколько легко будет рядовому пользователю расшифровать файл и сохранить его на диск я не могу и не думаю, что кто-то может
Это не важно совершенно. Достаточно одного не-простого пользователя, чтобы остальные уже могли не напрягаясь сливать выложенный им файл по BitTorrent.
> Первый же легальный потребитель, сохранивший файл по своей уникальной ссылке, может делать с этим файлом всё, что угодно.
После чего он перестанет быть легальным потребителем.
> Mozilla уже сказали своё слово, нормального ответа нет. Ни от кого, от вас в том числе.
Я обладаю той же информацией, что и вы — текст спецификации. По крайней мере я его прочитал и не увидел ничего криминального. Если вас беспокоит какой-то конкретный пункт — пожалуйста, приведите его, и мы вместе попытаемся разобраться. Можно в личку. Беспокойство самой Мозилы я понять могу — они не принимали участия в составлении спецификации — не хорошо вышло.
> А если контент будет эксклюзивным, его всё равно украдут в первые же часы, перечисленным выше способами.
Идеальной защиты не бывает. Бывает только достаточный уровень защиты. В данном случае — стрим будет работать только у легальных пользователей. Нелегальным придется довольствоваться торрентами, что, согласитесь, не так удобно, как зайти на сайт, нажать кнопку и сразу же получить контент.
После чего он перестанет быть легальным потребителем.
> Mozilla уже сказали своё слово, нормального ответа нет. Ни от кого, от вас в том числе.
Я обладаю той же информацией, что и вы — текст спецификации. По крайней мере я его прочитал и не увидел ничего криминального. Если вас беспокоит какой-то конкретный пункт — пожалуйста, приведите его, и мы вместе попытаемся разобраться. Можно в личку. Беспокойство самой Мозилы я понять могу — они не принимали участия в составлении спецификации — не хорошо вышло.
> А если контент будет эксклюзивным, его всё равно украдут в первые же часы, перечисленным выше способами.
Идеальной защиты не бывает. Бывает только достаточный уровень защиты. В данном случае — стрим будет работать только у легальных пользователей. Нелегальным придется довольствоваться торрентами, что, согласитесь, не так удобно, как зайти на сайт, нажать кнопку и сразу же получить контент.
> После чего он перестанет быть легальным потребителем.
Думаю, что его последнее, что его волнует.
> Я обладаю той же информацией, что и вы — текст спецификации. По крайней мере я его прочитал и не увидел ничего криминального.
Я её не читал — ограничился просмотром обсуждения в рассылке.
> Если вас беспокоит какой-то конкретный пункт — пожалуйста, приведите его, и мы вместе попытаемся разобраться.
Меня беспокоит ответ представителя Netflix в рассылке. Или вы не до конца поняли спецификацию, или он (либо он её не читал). Одно из двух.
> Идеальной защиты не бывает. Бывает только достаточный уровень защиты.
А бывает лишняя и бесполезная защита. Вот например стриминг контента, который месяцы назад был доступен на торрентах в полном диапазоне: от пережатка для мобильного до копии оригинального BD. Скажите мне, в чём смысл его защиты в принципе? Всё пытаюсь добиться ответа на этот вопрос от сторонников DRM, но никак не получается.
> Нелегальным придется довольствоваться торрентами, что, согласитесь, не так удобно, как зайти на сайт, нажать кнопку и сразу же получить контент.
Есть например Vuze. Я им не пользовался, но если то, что рекламируют — правда, то «получить контент» в нём не намного сложнее (последовательная загрузка, встроенный плеер).
Думаю, что его последнее, что его волнует.
> Я обладаю той же информацией, что и вы — текст спецификации. По крайней мере я его прочитал и не увидел ничего криминального.
Я её не читал — ограничился просмотром обсуждения в рассылке.
> Если вас беспокоит какой-то конкретный пункт — пожалуйста, приведите его, и мы вместе попытаемся разобраться.
Меня беспокоит ответ представителя Netflix в рассылке. Или вы не до конца поняли спецификацию, или он (либо он её не читал). Одно из двух.
> Идеальной защиты не бывает. Бывает только достаточный уровень защиты.
А бывает лишняя и бесполезная защита. Вот например стриминг контента, который месяцы назад был доступен на торрентах в полном диапазоне: от пережатка для мобильного до копии оригинального BD. Скажите мне, в чём смысл его защиты в принципе? Всё пытаюсь добиться ответа на этот вопрос от сторонников DRM, но никак не получается.
> Нелегальным придется довольствоваться торрентами, что, согласитесь, не так удобно, как зайти на сайт, нажать кнопку и сразу же получить контент.
Есть например Vuze. Я им не пользовался, но если то, что рекламируют — правда, то «получить контент» в нём не намного сложнее (последовательная загрузка, встроенный плеер).
Разве что, нельзя уйти в «офлайн» без наличия интернета
Можно. Главное, чтоб при активации и установке игры интернет был.
Вы попробуйте
1. Закрыть стим
2. Отключить интернет
3. Включить стим
Он скажет что не может войти, и в офлайн режим не даст перейти, то есть, если неожиданно пропал интернет, поиграть не получится.
1. Закрыть стим
2. Отключить интернет
3. Включить стим
Он скажет что не может войти, и в офлайн режим не даст перейти, то есть, если неожиданно пропал интернет, поиграть не получится.
Странно. Мне всегда предлагал в автономном режиме запустится, в таком случае.
Приду домой, проверю еще раз.
Приду домой, проверю еще раз.
Предлагать то предлагает, но не входит, я сам очень удивился.
support.steampowered.com/kb_article.php?ref=3160-AGCB-2555
support.steampowered.com/kb_article.php?ref=3160-AGCB-2555
Только что проверил.
Отключил сеть, запустил Steam, он мгновенно предложил врубить «автономный режим», открылся, запустил Alan Wake'а и нормально поиграл.
Даже Steam Cloud не ругался.
Отключил сеть, запустил Steam, он мгновенно предложил врубить «автономный режим», открылся, запустил Alan Wake'а и нормально поиграл.
Даже Steam Cloud не ругался.
Попробуйте сделать логаут перед выходом. Автономный режим будет работать только если при последнем выходе он был подключен к учетной записи и только для этой учетной записи. Если компьютером пользуются несколько человек с различными логинами — это актуально. А раньше и вовсе надо было сперва вручную включить автономный режим с работающим интернетом.
Но в целом на текущий момент сам по себе Стим — вполне приличный компромисс. Больше всего раздражают игры со сторонними DRM и региональным маразмом. Я, например, так и не смог купить последние DLC для Fallout NV, потому что его убрали из доступных для региона. Многие игры, которые былыи переведены на русский, в Стиме русского языка не имеют. Апофеоз маразма — изначально русскоязычные игры от 1С традиционно не имеют русской версии, а те, которые они локализуют по заказу, в регионе доступны только в особой версии. Некоторые игры требуют для запуска логина в сосбственной системе, а автономного режима традиционно не имеют. Особено радует Heroes VI, который при потере коннекта выкидывает из игры с потерей всех изменений за сессию.
Но в целом на текущий момент сам по себе Стим — вполне приличный компромисс. Больше всего раздражают игры со сторонними DRM и региональным маразмом. Я, например, так и не смог купить последние DLC для Fallout NV, потому что его убрали из доступных для региона. Многие игры, которые былыи переведены на русский, в Стиме русского языка не имеют. Апофеоз маразма — изначально русскоязычные игры от 1С традиционно не имеют русской версии, а те, которые они локализуют по заказу, в регионе доступны только в особой версии. Некоторые игры требуют для запуска логина в сосбственной системе, а автономного режима традиционно не имеют. Особено радует Heroes VI, который при потере коннекта выкидывает из игры с потерей всех изменений за сессию.
Опять бедные несчастные обворованные компании пытаются нагнуть весь остальной мир, что б самим стать еще беднее и несчастнее.
Ничо, в аду им уже заготовлены специальные особые сковороды.
Ничо, в аду им уже заготовлены специальные особые сковороды.
Цитата из черновика
No «DRM» is added to the HTML5 specification, and only simple clear key decryption is required as a common baseline.
Ну и картинка без никому не нужного логотипа HTML5 из того же черновика:
Что-то мне подсказывает что отказ консорциума не помешает реализовать этот интерфейс в ie, chrome да и safari скорее всего подтянется. Это как минимум. Под ff сделают расширение, они сами по себе вряд ли на такое пойдут.
Если посмотреть на эту инициативу прагматично, то:
1) Подобная инфраструктура не усложняет взлом DRM защиты относительно существующих поприетарных решений.
2) Открытые спецификации упростят создание дампилок шифрованного содержимого.
3) Технология может пригодиться не только для DRM, но и просто для защиты от перехвата контента в сети. Например корпоративная видеотрансляция в отдалённые офисы (естественно приватная). Заворачивать каждого клиента через https или vpn — можно и пупок надорвать. Подобный концепт будет ощутимо проще масштабироваться.
По сему проблем не вижу.
PS. это лучше, чем ключи вшитые в процессор (привет Intel Insider habrahabr.ru/tag/Intel%20Insider/)
1) Подобная инфраструктура не усложняет взлом DRM защиты относительно существующих поприетарных решений.
2) Открытые спецификации упростят создание дампилок шифрованного содержимого.
3) Технология может пригодиться не только для DRM, но и просто для защиты от перехвата контента в сети. Например корпоративная видеотрансляция в отдалённые офисы (естественно приватная). Заворачивать каждого клиента через https или vpn — можно и пупок надорвать. Подобный концепт будет ощутимо проще масштабироваться.
По сему проблем не вижу.
PS. это лучше, чем ключи вшитые в процессор (привет Intel Insider habrahabr.ru/tag/Intel%20Insider/)
Ага, мозилла точно с радостью ЭТО добавит в свой браузер:>
Как по мне, то здравая инициатива. По крайней мере для тех, кто ждёт когда можно будет спокойно и легально посмотреть фильм онлайн (присутствие Netflix не случайно). В «копирастических» топиках постоянно говорят о том, что «неудобно», «не найти», «только под виндой», «проприетарный поделки» и т. п. А внедрение этой технологии во все популярные браузеры позволит «копирастам» создавать кроссбраузерные и кроссплатформенные системы video-on-demand. Вернее у них будет меньше «отмазок» почему они этого не хотят делать.
Понятно, что большинство хаброюзеров смогут записать поток «на раз», ну «на раз-два», но крупные игроки ориентируются прежде всего на массы. Если стандарт устойчив и неквалифицированному взлому, то он может быть большим шагом вперёд к нормальным легальным системам доставки контента по требованию.
Понятно, что большинство хаброюзеров смогут записать поток «на раз», ну «на раз-два», но крупные игроки ориентируются прежде всего на массы. Если стандарт устойчив и неквалифицированному взлому, то он может быть большим шагом вперёд к нормальным легальным системам доставки контента по требованию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google, Microsoft и Netflix хотят добавить DRM в HTML5