Комментарии 19
Ну и как это защитит видео от копирования? Будут копировать не просто видео, а пару видео/валидный ключ. Вся логика на стороне клиента ведь
Имею аналогичное впечатление. Если менять ключ на лету — возрастет нагрузка на сервер.
Из всего имеющегося арсенала средств наиболее удобными для применения представляются следующие:
— разбить видео на части
— передавать через RTMP-разрешения или просто — по временным ссылкам
Причем все это не спасет от банального скриннинга. Возможно, добавить меру от этого:
— ватермарк в плейере с личными данными просматривающего
И все равно не спасет.
Отдавать даже «зашифрованное» видео неавторизованному клиенту — видится безрассудным.
Из всего имеющегося арсенала средств наиболее удобными для применения представляются следующие:
— разбить видео на части
— передавать через RTMP-разрешения или просто — по временным ссылкам
Причем все это не спасет от банального скриннинга. Возможно, добавить меру от этого:
— ватермарк в плейере с личными данными просматривающего
И все равно не спасет.
Отдавать даже «зашифрованное» видео неавторизованному клиенту — видится безрассудным.
Ключ предполагается выдавать сервером; конечно же, в коде его никто прописывать не будет.
Что мне мешает написать расширение к браузеру, который будет перехвачивать событие и выводить ключ рядом с видео. А потом сохранить себе видео вместе с ключем.
Ничто не мешает.
Но ведь не все поставят такое расширение.
И ключ можно менять на лету. А поскольку тот же алгоритм шифрования AES — не так тяжел для современных CPU (есть аппаратные реализации типа SSE), то не так все просто получается.
Вообще, это просто технология, об абсолютной защите речь и не идет.
Но ведь не все поставят такое расширение.
И ключ можно менять на лету. А поскольку тот же алгоритм шифрования AES — не так тяжел для современных CPU (есть аппаратные реализации типа SSE), то не так все просто получается.
Вообще, это просто технология, об абсолютной защите речь и не идет.
Что мешает снять видео с экрана)
Опять же, не все видео интересно хранить у себя; гипотетический пример — то же вещание с twitch.tv в наилучшем качестве.
Расширение к браузеру для любителей свободы: при легальном доступе — пара видео/ключ отправляется в открытый источник БД, при попытке посмотреть запрещенное видео — попытаться найти уже известный ключ к этому видео. Я не думаю, что видео каждый раз будет кодироваться разными ключами для разных пользователей — представьте увеличение нагрузки на ЦПУ.
Хотя, предвидя большой спрос копирастов не исключено, что могут появиться железячные решения для шифрования контента на лету, которые разгрузят ЦПУ на раз-два.
В x86 есть некая поддержка — Расширение_системы_команд_AES
Кажется там (в webm) возможно шифрование уже пересжатого видео, так что нужно только зашифровать по новой и обновить заголовок. А это всё таки быстрее. К тому же в современных процессорах AES ускорен аппаратно.
Надо понимать, что DRM — это прежде всего про приставки, которые отдаются абоненту без пароля, с приватными ssl сертификатами, до которых вы не доберетесь, потому что JTAG разъём надежно залит какой-то дрянью.
Если честно, то мало кого волнует судьба интернет-зрителей видео, иначе не цвели бы таким пышным цветом трекеры.
Соответственно в такой схеме вы можете лишь найти подходящую плату захвата, открывающую HDCP, которую найти очень непросто.
Бесконтрольная раздача зашифрованного видео неавторизованным клиентам нужна для соображений упрощения кеширования.
Если честно, то мало кого волнует судьба интернет-зрителей видео, иначе не цвели бы таким пышным цветом трекеры.
Соответственно в такой схеме вы можете лишь найти подходящую плату захвата, открывающую HDCP, которую найти очень непросто.
Бесконтрольная раздача зашифрованного видео неавторизованным клиентам нужна для соображений упрощения кеширования.
habrahabr.ru/post/151599/ а вот этим алгоритмом шифровать нельзя? Тогда исключается возможность «прослушки» тем же браузером
Допустим таким образом можно будет защититься от расширений браузера и перехватывания трафика, но невозможно будет защититься от «пропатчивания» кода в самом браузере (на базе OpenSource версии Chromium). Например добавить туда возможность выводить все не только на экран, но и сохранять на жесткий диск. Как вариант — рисовать видео разными потоками (например один рисует одну часть картинки, второй другую, а третий черный экран, который перерисовывается четвертым. Правда это все равно не спасет от программ «захвата» экрана (:
Мне кажется это уже другой вопрос. Так можно до маразма дойти и поставлять свой сайт в комплекте с браузером, в котором можно воспроизводить контент, а в остальных запретить.
И я о том же, как ни крути, но даже если поставлять своё дополнительное ПО и блокировать возможность сграббить экран, все равно можно поставить видеокамеру и направить ее на монитор. В конце концов, ведь без доступа к оборудованию, все равно можно сделать camrip, как умудряются делать в кинотеатрах во время просмотра фильмов.
Любое подобное шифрование запросто обойдется скринрекордером, от него никак видео не защитить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация хостинга зашифрованного видеоконтента с помощью HTML5