Как предотвратить пиратство для Java-приложения веб-запуска

Question

У меня есть Java-приложение, которое я собираюсь продавать через Интернет. На данный момент я склоняюсь к развертыванию приложения с помощью веб-запуска Java. Продукт будет лицензирован для пользователя, чтобы использовать программу только на одном компьютере одновременно. Я обеспокоен пиратством с этой моделью. Я хотел бы установить некоторые функции безопасности для обеспечения соблюдения модели лицензирования. Цель состоит в том, чтобы по крайней мере затруднить для лицензированного пользователя копирование установленного продукта, включая лицензионный ключ, для нелицензированных пользователей. Вот варианты, на которые я сейчас смотрю:

1. Принудительная аутентификация пользователя на материнском корабле с именем пользователя / паролем при каждом запуске программы.

2. Просто установите лицензионный ключ где-нибудь (скрытый?) На ПК пользователя после того, как он зарегистрировался и оплатил. Во время выполнения убедитесь, что установлен действительный лицензионный ключ.

3. Использование / сборка пакета безопасности на основе аппаратного отпечатка компьютера пользователя. Этот отпечаток будет вычисляться при каждом запуске приложения и сравниваться с локально установленным лицензионным ключом с использованием некоторого вида хэша. Этот лицензионный ключ будет действительным только с этим аппаратным отпечатком.

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

Полагаю, что я ищу что-то, основанное на java, которое хотя бы в некоторой степени безопасно, легко развертывается и не доставляет неудобств пользователю. Какой подход к безопасности / лицензированию вы использовали?

РЕДАКТИРОВАТЬ: Я должен добавить, что я не обязательно ищу серебряную пулю, чтобы абсолютно все от победы над безопасностью. Всегда найдется кто-то, у кого будет достаточно времени, чтобы найти способы сделать это. Я не так обеспокоен этими парнями. Я просто пытаюсь сделать так, чтобы обычному пользователю было сложно скопировать лицензионный ключ и отправить его друзьям. Правильно реализованное решение должно убедить обычного пользователя в том, что его проще купить.

Answer 1

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

Но, в конце концов, ничто из того, что вы можете сделать, не остановит решительного пользователя от пиратства вашего программного обеспечения.

На самом деле самая эффективная стратегия разработки программного обеспечения для борьбы с пиратством - самая простая из всех:

1. Имейте отличный товар.
2. Взять справедливую цену за него.

- Джефф Этвуд

Answer 2

IMO, попытка обеспечить защиту от копирования на стороне клиента, вероятно, доставляет больше хлопот, чем стоит. Вы потратите бесчисленные часы, пытаясь перехитрить своих клиентов (часы, которые вы могли бы потратить на улучшение своего продукта), но в итоге пираты всегда победят.

У вас есть другие варианты:

1. Имейте привлекательную модель ценообразования и сделайте действительно простой для людей, чтобы купить ваш продукт. Если у вас достаточно низкий барьер для входа и относитесь к своему клиенту с уважением и доверием, а не с подозрением, вы сводите к минимуму риск пиратства.
2. Свяжите свой продукт с каким-либо онлайн-сервисом. Отдать клиента, но взимать плату за услугу. Это то, что Blizzard делает с World of Warcraft, и это одна из немногих игр, у которой нет проблем с пиратством (у них много других проблем, но это другая история).

Answer 3

Моя лучшая ставка - внедрить простое решение, которое не облагает вас большими налогами и не вызывает недовольства клиентов, чтобы предотвратить случайное пиратство Ничего сложнее, и это будет гонка вооружений. Тот, который слишком сложно выиграть.

Answer 4

Честно говоря, если программе на самом деле не нужны данные с сервера для работы (как fred-o заявил, что World of Warcraft нуждается; и это правда), то ничего вы не можете сделать на стороне клиента, который будет быть полностью дураком Все 3 идеи, которые у вас были, можно легко обойти. Сервер / вход в систему может быть немного сложнее, но я даже видел, как взломы зашли так далеко, что локально создали фиктивный сервер входа в систему, поэтому программа думает, что он аутентифицирован.

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

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

Answer 5

Из трех ваших решений:

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

Во-вторых, защита от копирования невелика, за исключением случаев, когда местоположение скрыто, и у скрытого местоположения есть свои трудности (например, некоторые люди не любят устанавливать приложения, которые любят скрывать объекты в разных местах), и не в любом случае, в безопасности.

Третий, скорее всего, будет работать, пока пользователь не сделает что-то с компьютером, который поменяет отпечаток пальца (я не знаю, что вы будете проверять), или пока он не захочет перенести приложение с одного компьютера на замену. Тогда у вас будет потенциально разгневанный пользователь. («Я заменил жесткий диск / перешел на другое подключение к локальной сети / произошел системный сбой / что угодно, и [объяснительное удаленное] просто перестало работать!»)

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

Answer 6

Я бы серьезно пересмотрел лицензионные требования, потому что их соблюдение лишит вас законных клиентов. Если вы большая компания, вы можете себе это позволить, но если вы стартап или частное лицо, вы не можете.

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

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

Answer 7

Если приложению уже не нужно подключаться к сети, чтобы выполнять свою реальную работу, звонки домой могут быть легко классифицированы как шпионское ПО.

И я не уверен, применимо ли это к Java Web Start, но поскольку брандмауэры могут блокировать звонки в ваше приложение, ваши платящие клиенты могут по-прежнему видеть, что их приложение заблокировано.

Итак: я бы не использовал то, что звонит домой время от времени.

(Что касается лицензионных ключей: если ключ работает только с определенным регистрационным именем, и если это имя отображается в каком-либо диалоговом окне «О программе», я бы не стал беспокоиться о том, чтобы сделать его аппаратно зависимым. Конечно, несколько имен и их ключи будут разделены, но что-то более сложное не стоит усилий. Если мой Mac не подведет меня, я не удивлюсь, если произойдет восстановление Time Machine в одно нажатие на новом оборудовании, из-за которого ваше приложение не запустится.)

Answer 8

Рассмотрите возможность использования JNLP, чтобы иметь ограниченный по времени компонент в вашем приложении - модуль лицензии? - которые должны регулярно обновляться через Интернет. Доступ к обновленной версии требует регистрации. Пусть

Иметь длительный льготный период, позволяющий пользователю оставаться в автономном режиме (или не желать обновляться) в течение некоторого периода перед отключением функций.