Разумно ли защищать контент на стороне клиента drm'd
Обновление: этот вопрос конкретно касается защиты (шифрования / обфускации) клиентской части контента от выполнения ее перед передачей с сервера. Каковы плюсы / минусы в подходе, подобном подходу itune - в котором файлы не зашифровываются / не запутываются перед передачей.
Как я добавил в своей заметке в первоначальном вопросе, существуют контракты, которым мы должны соответствовать (как в случае с большинством сервисов, реализующих drm). Мы стремимся к свободе от drm, и большинство соглашений с контент-провайдерами заключено, но это не освобождает нас от уже существующих обязательств.
Недавно я прочитал некоторую информацию о том, как itunes / fairplay приближается к drm, и не ожидал увидеть, что сервер фактически обслуживает файлы без какой-либо защиты.
Цитата в этом ответе, кажется, отражает дух проблемы.
Цель должна просто состоять в том, чтобы "сохранить честность честных людей". Если мы пойдем дальше, произойдут только две вещи:
- Мы ведем битву, которую не можем выиграть. Те, кто хочет обмануть, преуспеют.
- Мы наносим вред честным пользователям нашего продукта, усложняя его использование.
Я не вижу никакого влияния на честных пользователей здесь, файлы будут привязаны к пользователю - независимо от того, происходит ли это на стороне клиента или сервера. Это дает еще один шанс для тех, кто в 1.
Дополнительная информация: клиентская среда Adobe Air, задействовано несколько типов контента (музыка, видео, флеш-приложения, изображения).
Таким образом, разумно ли делать честную игру itune и защищать медиа-клиента.
Примечание: я думаю, что нерушимый DRM является неразрешимой проблемой, и, поскольку большинство ищет ответ на этот вопрос, необходимость в нем связана с тем, что он уже заключил контракт с поставщиками контента... в духе разумных лучших усилий.
7 ответов
Чтобы ответить на вопрос "разумно ли это", вам нужно четко понимать, когда вы используете слово "защищать", от чего вы пытаетесь защитить...
Например, вы пытаетесь:
- авторизованные пользователи могут использовать загруженный контент через ваше приложение при определенных обстоятельствах (например, истечение срока аренды, копирование на другой компьютер и т. д.)?
- авторизованные пользователи могут использовать загруженный контент через какое-либо приложение при определенных обстоятельствах (например, истечение срока аренды, копирование на другой компьютер и т. д.)?
- неавторизованным пользователям использовать контент, полученный от авторизованных пользователей через ваше приложение?
- неавторизованным пользователям использовать контент, полученный от авторизованных пользователей через какое-либо приложение?
- Известные пользователи имеют доступ к некупленному / несанкционированному контенту из библиотеки мультимедиа на вашем сервере через ваше приложение?
- Известные пользователи имеют доступ к некупленному / несанкционированному контенту из библиотеки мультимедиа на вашем сервере через какое-либо приложение?
- неизвестные пользователи получают доступ к библиотеке мультимедиа на вашем сервере через ваше приложение?
- неизвестные пользователи получают доступ к медиатеке на вашем сервере через какое-либо приложение?
так далее...
"Любое приложение" в вышеприведенном может включать в себя такие вещи, как:
- другие программы игрока, предназначенные для взаимодействия / сотрудничества с вашим сайтом (например, для Flickr)
- программы, предназначенные для преобразования контента в другие форматы, возможно, не в форматах DRM
- враждебные программы, предназначенные для
Из статьи, которую вы связали, вы можете увидеть некоторые возможные ограничения применения DRM на стороне клиента...
Третий, первоначально используемый в PyMusique, клиенте Linux для iTunes Store, претендует на звание iTunes. Он запрашивал песни с серверов Apple, а затем загружал купленные песни, не блокируя их, как iTunes.
Четвертый, используемый в FairKeys, также притворяется iTunes; он запрашивает ключи пользователя у серверов Apple, а затем использует эти ключи для разблокировки существующих купленных песен.
Ни один из этих подходов не требовал взлома применяемого DRM или даже взлома любого из задействованных продуктов; они могут быть сделаны просто путем пассивного соблюдения протоколов, а затем имитировать их.
Возникает вопрос: пытаетесь ли вы защитить себя от подобных атак?
- Если да, то применение DRM на клиенте нецелесообразно.
- Если нет (например, вас интересуют только люди, использующие ваше приложение, как Apple/iTunes), то это может быть так.
(повторите этот процесс для каждой ситуации, о которой вы только можете подумать. Если adig nswer всегда либо "DRM, примененный клиентом, защитит меня", либо "я не пытаюсь защитить от этой ситуации", то использование DRM, примененного клиентом, является разумным..)
Обратите внимание, что для последних четырех из моих примеров, хотя DRM защитит от таких ситуаций как побочный эффект, это не лучшее место для применения этих ограничений. Такие ограничения лучше всего применять на сервере в процессе авторизации / авторизации.
Я думаю, вы можете что-то здесь упустить. Пользователи ненавидят, ненавидят, ненавидят, ненавидят DRM. Вот почему ни одна медиа-компания никогда не получает никакой поддержки, когда они пытаются ее использовать.
Главное здесь то, что в контракте говорится "разумные максимальные усилия", и я не имею ни малейшего представления о том, что это будет означать в суде.
То, что вы хотите сделать, это сделать вашего клиента счастливым с DRM, на который вы надеваете. Я не знаю, что ваш клиент думает о DRM, что он может делать, затрачивает ресурсы или знает ли ваш клиент, что DRM может действительно раздражать. Вы должны ответить на это. Вы можете попытаться обучить клиента, но это можно рассматривать как попытку объяснить некачественную работу.
Если клиент недоволен, следующей запасной позицией будет оплата без судебных разбирательств, и для этого контракт должен быть достаточно ясным. К сожалению, "разумное лучшее усилие" неясно, так что вы можете оказаться в суде. Вы можете быть в состоянии пересмотреть части договора в пользу клиента, или вы не можете.
Если ничего не помогает, вы надеетесь выиграть судебное дело.
Я не юрист, и это не юридическая консультация. Я считаю это скорее вопросом ожиданий и возможного юридического толкования, чем техническим вопросом. Я не думаю, что мы можем помочь вам здесь. Вам следует проконсультироваться с юристом, который специализируется на подобных вещах, и я даже не знаю, какую специальность рекомендовать. Если вы находитесь в США, позвоните в местную коллегию адвокатов и попросите направление.
Я не вижу никакого влияния на честных пользователей здесь, файлы будут привязаны к пользователю - независимо от того, происходит ли это на стороне клиента или сервера. Это дает еще один шанс для тех, кто в 1.
Файлы, привязанные к пользователю, требуют некоторого метода проверки наличия пользователя. Что происходит, когда ваш сервер верификации выходит из строя (или прекращает работу, как это сделал Wal-Mart)?
Не существует такого уровня DRM, который бы не затронул хотя бы некоторых "честных пользователей".
Данные могут быть скопированы До тех пор, пока клиентское оборудование, автономное, не сможет различить "хорошую" и "плохую" копии, вы в конечном итоге ограничите все общие копии и механизмы копирования. Большинство DRM-компаний имеют дело с этим фактом, говоря мне, насколько эта технология освобождает меня. Как будто люди начинают верить, когда слышат одно и то же достаточно часто...
Код не может быть защищен на клиенте. Защита кода на сервере - в значительной степени решенная проблема. Защита кода на клиенте - нет. Все современные подходы идут с скупыми ограничениями.
Воздействие работает тонкими способами. По крайней мере, у вас есть дополнительные расходы на внедрение DRM на стороне клиента (и все последующие расходы, включая орды горилл, кричащих "DMCA"). Трудно доказать, что вы возместите эти затраты с помощью увеличенный доход.
Это не просто код и криптография. Как только вы внедрили DRM на стороне клиента, вы развязали цепочку событий в области маркетинга, связей с общественностью и права. Пока они не перестают отталкивать пользователей, вам не нужно об этом беспокоиться.
Если сервер обслуживает контент без защиты, то это потому, что шифрование выполняется для каждого клиента.
Это, как говорится, проволочная акула помешает ваши лучшие планы.
Шифрование само по себе так же хорошо, как отправка логического значения, сообщающего, разрешено ли вам использовать контент, поскольку обход обычно просто изменяет ввод / вывод на один вызов API шифрования...
Вы хотите использовать сильное двоичное запутывание на стороне клиента, если хотите, чтобы защита буквально удерживалась более 5 минут. Используя расшифровку на стороне клиента, убедитесь, что данные не могут быть воспроизведены, и что единственный способ обойти систему - это восстановить всю схему двоичной защиты. Правильно сделано, это остановит всех детей.
С другой стороны, если это продукт, предназначенный для работы в операционной системе, не используйте аномалии, специфичные для процессора или операционной системы, такие как ошибки Windows PEB/TEB/syscall и ошибки процессора, это только сделает программу еще менее переносимой. чем DRM уже есть.
Да, и ответить на заголовок вопроса: Нет. Это пустая трата времени и денег, и ваш продукт не будет работать на моей усиленной системе Linux.