Разумно ли защищать контент на стороне клиента drm'd - PullRequest
Новая
       35

Разумно ли защищать контент на стороне клиента drm'd

2 голосов
/ 30 ноября 2009

Обновление: этот вопрос конкретно касается защиты (шифрования / обфускации) стороны клиента контента от выполнения этого перед передачей с сервера. Каковы плюсы / минусы в подходе, подобном подходу itune - в котором файлы не зашифровываются / не запутываются перед передачей.

Как я добавил в своей заметке в первоначальном вопросе, существуют контракты, которым мы должны соответствовать (как в случае с большинством сервисов, реализующих drm). Мы стремимся к свободе от drm, и большинство соглашений с контент-провайдерами заключено, но это не освобождает нас от уже существующих обязательств.

Я недавно прочитал некоторую информацию о том, как itunes / fairplay приближается к drm, и не ожидал увидеть, что сервер фактически обслуживает файлы без какой-либо защиты.

Цитата в этом ответе , кажется, отражает дух проблемы.

Целью должно быть просто "сохранить честные люди честные ". Если мы пойдем кроме этого, только две вещи бывает:

  1. Мы ведем битву, которую не можем выиграть. Те, кто хочет обмануть, добьются успеха.
  2. Мы наносим вред честным пользователям нашего продукта, усложняя его использование.

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

Дополнительная информация: клиентская среда - Adobe Air, задействовано несколько типов контента (музыка, видео, flash-приложения, изображения).

Итак, разумно ли делать что-то вроде честной игры itune и защищать медиа-клиента.

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

Ответы [ 7 ]

9 голосов
/ 30 ноября 2009

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

6 голосов
/ 01 декабря 2009

Самое удивительное, что в контракте говорится «разумное наилучшее усилие», и я не имею ни малейшего представления о том, что это будет означать в суде.

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

Если клиент недоволен, следующей запасной позицией будет оплата без судебных разбирательств, и для этого контракт должен быть достаточно ясным. К сожалению, «разумное наилучшее усилие» неясно, поэтому вы можете оказаться в суде. Вы можете перезаключить части договора в пользу клиента или нет.

Если ничего не помогает, вы надеетесь выиграть судебное дело.

Я не юрист, и это не юридическая консультация. Я считаю это скорее вопросом ожиданий и возможного юридического толкования, чем техническим вопросом. Я не думаю, что мы можем помочь вам здесь. Вы должны проконсультироваться с юристом, который специализируется на подобных вещах, и я даже не знаю, какую специальность рекомендовать. Если вы находитесь в США, позвоните в местную коллегию адвокатов и попросите направление.

5 голосов
/ 01 декабря 2009

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

Файлы, привязанные к пользователю, требуют некоторого метода проверки того, что пользователь существует. Что происходит, когда ваш сервер верификации выходит из строя (или прекращает работу, как это сделал Wal-Mart)?

Нет такого уровня DRM, который не затрагивал бы хотя бы некоторых "честных пользователей".

4 голосов
/ 01 декабря 2009

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

Код не может быть защищен на клиенте. Защита кода на сервере является в значительной степени решенной проблемой. Защита кода на клиенте - нет. Все современные подходы идут с скупыми ограничениями.

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

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

3 голосов
/ 10 декабря 2009

Чтобы ответить на вопрос «Разумно ли это», вам нужно четко понимать, когда вы используете слово «защищать», от чего вы пытаетесь защитить ...

Например, вы пытаетесь:

  1. авторизованные пользователи могут использовать загруженный контент через ваше приложение при определенных обстоятельствах (например, истечение срока аренды, копирование на другой компьютер и т. Д.)?
  2. авторизованные пользователи могут использовать загруженный контент через из любого приложения при определенных обстоятельствах (например, истечение срока аренды, копирование на другой компьютер и т. Д.)?
  3. неавторизованные пользователи могут использовать контент, полученный от авторизованных пользователей через ваше приложение ?
  4. неавторизованные пользователи используют контент, полученный от авторизованных пользователей через любое приложение ?
  5. известных пользователей по доступу к приобретенному / неавторизованному контенту из библиотеки мультимедиа на вашем сервере через ваше приложение ?
  6. известных пользователей, получивших доступ к приобретенному / несанкционированному контенту из библиотеки мультимедиа на вашем сервере через из любого приложения ?
  7. неизвестные пользователи получают доступ к библиотеке мультимедиа на вашем сервере через ваше приложение ?
  8. неизвестные пользователи получают доступ к библиотеке мультимедиа на вашем сервере через из любого приложения ?

и т.д ...

«Любое приложение» в вышеприведенном может включать в себя такие вещи, как:

  • другие программы игрока, предназначенные для взаимодействия / сотрудничества с вашим сайтом (например, для flickr )
  • программы, предназначенные для преобразования контента в другие форматы, возможно, не в форматах DRM
  • враждебные программы, предназначенные для

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

  • Третий, первоначально использовавшийся в PyMusique, Linux-клиенте для iTunes Store, притворяется iTunes . Он запрашивал песни с серверов Apple, а затем загружал купленные песни, не блокируя их , как iTunes.

  • Четвертый, используемый в FairKeys, также притворяется iTunes ; он запрашивает ключи пользователя у серверов Apple, а затем использует эти ключи для разблокирования существующих купленных песен .

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

Таким образом, возникает вопрос: пытаетесь ли вы защититься от подобных атак?

  • Если да, то применяемое клиентом DRM - не разумно .
  • Если нет (например, вы беспокоитесь только о людях, использующих ваше приложение, как это делает Apple / iTunes), то это может быть.

(повторяйте этот процесс для каждой ситуации, о которой вы только можете подумать. Если adig nswer всегда либо «клиентское DRM защитит меня», либо «я не пытаюсь защитить от этой ситуации», затем с использованием клиентского DRM резонно .)

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

1 голос
/ 30 ноября 2009

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

Как говорится, проволочная акула помешает вашим лучшим планам.

0 голосов

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

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

С другой стороны, если это продукт, предназначенный для работы в операционной системе, не используйте аномалии, характерные для процессора или операционной системы, такие как ошибки Windows PEB / TEB / syscall и процессор, из-за этого программа будет только даже менее портативный, чем DRM, уже есть.

Да, и ответить на заголовок вопроса: Нет. Это пустая трата времени и денег, и ваш продукт не будет работать в моей усиленной системе Linux.

...