Здравствуйте, ReSanity, Вы писали:

RS>Здравствуйте, bazis1, Вы писали:

RS>>>Конкурс содержит вторую задачу "Алиса", к которой кандидатам как раз и предлагается создать "патч" (восстановить ее полную работоспособность без требования серийных ключей).
B>>полную работоспособность куска, который крутится на вашем сервере?

RS>Да, нескольких кусков кода.
и чем это отличается от "взлома RSA"? допустим у меня на сервере крутится кусок "Y = SHA1(X + SECRET)", где X — вход, Y — выход, SECRET известен только мне. Задача "восстановить работоспособность" сводится к либо выяснению SECRET, либо взлому сервера, т.е. в лоб не решается. В итоге ваш "конкурс" читается так: дадим 3К тому, кто а) взломает RSA, б) взломает SHA1.

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

Короче, ИМХО, вы изобрели теоретический велосипед с теоретически оптимальным числом колес Пи, вот только дороги ему увидеть не суждено...

Здравствуйте, bazis1, Вы писали:

RS>>Да, нескольких кусков кода.
B>и чем это отличается от "взлома RSA"? допустим у меня на сервере крутится кусок "Y = SHA1(X + SECRET)", где X — вход, Y — выход, SECRET известен только мне. Задача "восстановить работоспособность" сводится к либо выяснению SECRET, либо взлому сервера, т.е. в лоб не решается. В итоге ваш "конкурс" читается так: дадим 3К тому, кто а) взломает RSA, б) взломает SHA1.

Отличается очень сильно. Ваш "алгоритм RSA" так и останется алгоритмом RSA на стороне сервера, не более. Наша же система позволяет Вендорам за считанные минуты самим решить какие кусочки кода (желательно, ассоциированные с продуктовой политикой) они хотят сделать недоступными для взлома и анализа.

B>Только вот к защите реальных программ это не имеет никакого отношения, т.к.:
B>1. если выполнять нетривиальную функциональность на сервере, выши юзеры просто озвереют из-за задержек и необходимости постоянно быть на связи (а вдруг ваш сервер или их канал лег? а в дороге на ноутбуке запустить?)

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

Насчет необходимости "постоянно быть на связи" — такая необходимость есть только в моменты исполнения кода на стороне сервера, в остальные моменты времени канал связи не будет являться необходимостью. Интересно, почему у Вас не возникает подобных вопросов по отношению к SaaS?

B>Короче, ИМХО, вы изобрели теоретический велосипед с теоретически оптимальным числом колес Пи, вот только дороги ему увидеть не суждено...

Поверьте, Вы далеко не первый, кто нам это говорит. Однако есть как-минимум четыре далеко не глупых человека, которые с Вами не согласятся

Здравствуйте, bazis1, Вы писали:

B>допустим у меня на сервере крутится кусок "Y = SHA1(X + SECRET)", где X — вход, Y — выход, SECRET известен только мне. Задача "восстановить работоспособность" сводится к либо выяснению SECRET, либо взлому сервера, т.е. в лоб не решается.

Не в тему, но справедливости ради: вообще-то конкретно эта задача (выделенное), для хешей, построенных на функции Меркле-Дамгарда (коим и является SHA-1) решается в лоб за линейное время атакой удлинения сообщения

Здравствуйте, ReSanity, Вы писали:

RS>Здравствуйте, bazis1, Вы писали:

RS>Отличается очень сильно. Ваш "алгоритм RSA" так и останется алгоритмом RSA на стороне сервера, не более
RS>Наша же система позволяет Вендорам за считанные минуты самим решить какие кусочки кода (желательно,
RS>ассоциированные с продуктовой политикой) они хотят сделать недоступными для взлома и анализа.
это порождает массу вопросов к вам. какова производительность вашего облака? сколько вы мне выделяете памяти и дискового пространства? сколько потоков я могу создать на стороне облака? а сеть у вас есть?

или же вырезаются не любые куски кода, а только те, которые не дергают api функции, не выделяют памяти, и не сильно грузят ЦП. но как тогда вырезать бизнес-логику?


RS>Да, задержки имеют место быть, все очень сильно зависит от выбранных кусков кода
RS>(чем меньше "прыжков" исполнения между клиентом и сервером, тем меньше задержка).
RS>Достаточно быстро можно подобрать подходящие регионы кода, которые не будут
RS>вносить задержки (1) и будут весьма стойкими к атаке на "черный ящик" (2)
требованию (1) удовлетворяют только функции, отрабатывающие на стадии инитализации приложения, или же редко используемая часть функционала (вывод на печать). однако, вывод на печать вы отбрасываем сразу, т.к. передача таких объемов по сети вызовет гнев юзеров, да и сомнительно, чтобы вырезанный код работал в облаке, если он активно использует апи-функции, ран-тайм компилятора и глобальные переменные.

функции иницилизации, очевидно, не отвечают требованию (2). функция печати ему отвечает. но если разработчики решили реализовать ее в виде сервиса, но они это сделают _ПРЯМЫМИ_ руками, а не через Ж. это будет RESTful, работающий через http(s), причем серверная часть пишется с использованием серверных технологий и серверных библиотек. и она работает. в отличии от.


RS>Насчет необходимости "постоянно быть на связи" — такая необходимость есть только в моменты исполнения кода
RS>на стороне сервера, в остальные моменты времени канал связи не будет являться необходимостью. Интересно,
RS>почему у Вас не возникает подобных вопросов по отношению к SaaS?
вопрос на засыпку: сколько у вас кастомеров и вы вообще представляете какой DDoS вам они устроят по мылу и телефону? он-лайн активация это еще туда-сюда. особенно, если на активацию дается месяц времени. а вот от возможности валидации лицензии при каждом запуске очень многие разработчики отказываются, поскольку даже если у 1 из 100 кастомеров отвалится интернет в самое неподходящее время, то бурлению говен не будет пределов и гугл во первых строках поиска по названию программы покажет не сайт разработчика, а бурное обуждение богомерзкой программы.

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

B>>Короче, ИМХО, вы изобрели теоретический велосипед с теоретически оптимальным числом колес Пи, вот только дороги ему увидеть не суждено...
RS>Поверьте, Вы далеко не первый, кто нам это говорит. Однако есть как-минимум четыре далеко не глупых человека, которые с Вами не согласятся
какие-то продажи у вас будут, вероятно. но не взлетит. с таким-то отношением к безопастности... я молчу, что вырезать бинарный код само по себе занятие глупое и рискованное. к тому же это предъявляет к коду список требований, который вы нигде не упоминаете. а зря. я уже спросил: на какие ресурцы цп и оперативы может расчитывать вырезанный код? будет ли в его распоряжении диск и сеть? если да, то насколько надежно изолирован один код от другого? как быть с АПИ функциями? как быть с ран-таймом?

кстати, а вы в курсе вообще, что многие "навесные" защитные комплексы в реальности защищали функцию, возвращающую true/false и потому очень легко отламывались? вы, конечно, скажите, что "проблемы индейцев..." и далее по тексту. типа разработчики сами виноваты, что выбирают такие функции для защиты. но в действительности это не проблемы индейцев. это _ваши_ проблемы. потому что разработчик платит вам денежку и ждет, что ваша программа сама все сделает. а тут, оказывается, надо вникать в суть вещей и непостижимость мира. а у вас ни примеров, ни демонстраций, ни внятного описания, словом Н И Ч Е Г О. пусто.

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

Здравствуйте, ReSanity, Вы писали:

RS>Здравствуйте, мыщъх, Вы писали:

М>>не веб-сервис? тогда это попадон-с. а если у юзера только http и больше ничего? кстати, чем вам веб не угодил? когда REST бороздит оперативные просторы...

RS>Пока мы остановили свой выбор на собственном протоколе над TCP.
а почему не UDP? задержки у него сильно меньше будут. это же базовая матчасть. сервер у вас тоже свой собственный, как я понимаю? супер! это сильно облегчает DDoS атаки и делает вас абсолютно неконкурентоспособными, поскольку для веба абсолютно все уже есть. от дата-центров до систем защиты. к тому у пользователей как правило есть веб. но вы же не ищите легких путей ни для себя, ни для остальных. кстати, https рулит. во! а что рулит у вас?

RS> Для домашних пользователей лицензированного софта это не будет проблемой,
это вам кто сказал? отовите задницу от стула. возьмите с собой ноут и выйдите в парк подышать воздухом. там вам откроется, что веб есть, а все остальное закрыто. точно так же в гостиницах всяких, во многих отелях...

RS> для корпоративных будем рекомендовать открывать нужные TCP-порты на выход.
у вас есть опыт работы на компанию больше чем "я, жена и собака"? у таких компаний есть полиси. админы ими руководствуются. если сказано, что во внеший мир только веб и только на машинах на которых нет ничего секретного, то там тому и быть. при этом интернет может быть сильно кастрированный даже в плане веба.

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

RS> Если это станет ощутимой преградой, возможно, рассмотрим и HTTP-транспорт.
боюсь, что до этого не дойдет. вы постарались сделать проект максимально непривлекательным. и это у вас получилось, да.

RS>>>а) map-файлы (формат MSVC) — очень удобно, быстро и просто, но не является
RS>>>самым эффективным способом с точки зрения устойчивости к атакам на "черный ящик"
М>>видимо вы не достаточно качественно вырезаете. остаточная намагниченность межбитовых промежутков остается, да?
RS>Конкурсная задача "Алиса" инструментирована с помощью map-файлов. Можете посмотреть и оценить качество "вырезки".
вы уже себе противоречите по ходу. мне вот непонятно как влияет на устойчивость ко взлому выбор способа расставления маркеров?

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, ReSanity, Вы писали:

RS>>Наша же система позволяет Вендорам за считанные минуты самим решить какие кусочки кода ...
М>это порождает массу вопросов к вам. какова производительность вашего облака? сколько вы мне выделяете памяти и дискового пространства? сколько потоков я могу создать на стороне облака? а сеть у вас есть?
И самый главный вопрос: За чей счет банкет?
Похоже на то, что Вендору или Пользователю придется регулярно платить за использование ихнего облака. Если они навесят эту плату на Вендора, то ему придется распространить эту схему оплаты на своих конечных пользователей. Для того чтобы не вылететь в трубу.
И еще один вопрос: В какое Спортлото обращаться Вендору если их хакнут, заддосят или они решат выйти из бизнеса?

М>или же вырезаются не любые куски кода, а только те, которые не дергают api функции, не выделяют памяти, и не сильно грузят ЦП. но как тогда вырезать бизнес-логику?
Предполагаю, что на сервере вырезанный кусок кода исполняется эмулятором. Когда эмулятор обнаруживает вызов функции из невырезанного куска он передает управление клиенту. Клиент выполняет функцию и возвращает результат выполнения серверу. Если встречается инструкция считывающая данные из памяти, то сервер опять обращается к клиенту. Возможно клиент в этом случае сразу возвращает некоторую порцию данных, например страницу памяти.

RS>>Да, задержки имеют место быть, все очень сильно зависит от выбранных кусков кода
RS>>(чем меньше "прыжков" исполнения между клиентом и сервером, тем меньше задержка).
И появляются прыжки исполнения между клиентом и сервером.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, bazis1, Вы писали:

B>>допустим у меня на сервере крутится кусок "Y = SHA1(X + SECRET)", где X — вход, Y — выход, SECRET известен только мне. Задача "восстановить работоспособность" сводится к либо выяснению SECRET, либо взлому сервера, т.е. в лоб не решается.

KV>Не в тему, но справедливости ради: вообще-то конкретно эта задача (выделенное), для хешей, построенных на функции Меркле-Дамгарда (коим и является SHA-1) решается в лоб за линейное время атакой удлинения сообщения
круто. не знал. оно работает только для суффиксной формы, или в общем случае (скажем, X XOR SECRET)?

Здравствуйте, ReSanity, Вы писали:

RS>Отличается очень сильно. Ваш "алгоритм RSA" так и останется алгоритмом RSA на стороне сервера, не более. Наша же система позволяет Вендорам за считанные минуты самим решить какие кусочки кода (желательно, ассоциированные с продуктовой политикой) они хотят сделать недоступными для взлома и анализа.
Если продукт позволяет нетривиальные куски выполнять на сервере, то этот продукт делается в виде веб-сервиса и продается по подписке.

B>>Только вот к защите реальных программ это не имеет никакого отношения, т.к.:
B>>1. если выполнять нетривиальную функциональность на сервере, выши юзеры просто озвереют из-за задержек и необходимости постоянно быть на связи (а вдруг ваш сервер или их канал лег? а в дороге на ноутбуке запустить?)

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

RS>Насчет необходимости "постоянно быть на связи" — такая необходимость есть только в моменты исполнения кода на стороне сервера, в остальные моменты времени канал связи не будет являться необходимостью. Интересно, почему у Вас не возникает подобных вопросов по отношению к SaaS?
потому что если продукт терпим к недостаткам SaaS, то из него делается веб-сервис и ваш продукт пролетает. а если нетерпим, то ваш продукт тоже пролетает.

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

Здравствуйте, cserg, Вы писали:

C>Похоже на то, что Вендору или Пользователю придется регулярно платить за использование ихнего облака. Если они навесят эту плату на Вендора, то ему придется распространить эту схему оплаты на своих конечных пользователей. Для того чтобы не вылететь в трубу.

Стоимость серийных ключей для Вендора определяется следующими критериями:

1. максимальное время жизни лицензии (например, для триалок = количеству дней; для perpetual, то есть "вечных" лицензий приравнивается при расчетах фиксированному количеству дней, которое определяется тарифами),
2. максимальный параллелизм лицензии (максимально-возможное общее количество одновременно исполняющихся процессов с таким серийным ключом),
3. количество серийных ключей в заказе
4. тип продукта (для апгрейдов существенные скидки, патчи бесплатно, так как они без выпуска серийных ключей)

Причем у нас используются значительные скидки, которые зависят от всех перечисленных критериев.

C>И еще один вопрос: В какое Спортлото обращаться Вендору если их хакнут, заддосят или они решат выйти из бизнеса?

ООО "РеСанити", ReSanity, http://resanity.com
Подробная контактная информация указана на сайте и в расположенном там же публичном договоре.
Выходить из перспективного, не имеющего аналогов в мире, бизнеса мы не собираемся.

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

Да, Вы правы. В общих чертах это так. Технически все на порядок сложнее.

"Прыжки" исполнения на клиента производятся в нескольких случаях:

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

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

Здравствуйте, ReSanity, Вы писали:

RS>Здравствуйте, cserg, Вы писали:

RS>Стоимость серийных ключей для Вендора определяется следующими критериями:
...куча текста поскипана...
RS>Причем у нас используются значительные скидки, которые зависят от всех перечисленных критериев.

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

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

Здравствуйте, мыщъх, Вы писали:

М>то есть, вы даже сами не знаете сколько это стоит. хотя бы порядок. схема мутная и запутанная.

Почему же, мы предлагаем два похожих способа сотрудничества:

1. по публичному договору (оферте) — из расчета на shareware-сегмент
2. по приватному договору — из расчета на крупных Вендоров, либо тех shareware-Вендоров, которых не устраивают условия публичного договора

Так как мы только начинаем выходить на рынок, то сейчас будут действовать очень дешевые тарифы для shareware-сегмента. Тарифы будут опубликованы буквально на днях.

По самому дешевому тарифу, предназначенному для триалок:

один серийный ключ (триалка на 30 дней, параллелизм = 1) будет стоить 0,15 у.е. (у.е. мы приравниваем доллару США),

скидок на дни и количество лицензий по данному тарифу не предусматривается, есть скидки за параллелизм (concurrency) при которых:

один серийный ключ (триалка на 30 дней, параллелизм = 9999) будет стоить 1241,54 у.е. (то есть 0,124 у.е. за один параллельный процесс),

По дешевому тарифу, предназначенному для непосредственных продаж:

один серийный ключ (триалка на 30 дней, параллелизм = 1) будет стоить 0,30 у.е.
один серийный ключ (perpetual, параллелизм = 1) будет стоить 3,08 у.е.,

есть прогрессивная шкала скики на дни (при заказе количества дней > 360, все дни свыше идут со скидкой в 80%),
большая скидка на параллелизм (до 20%), большая скидка за количество серийных ключей в заказе (до 20%).

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

Здравствуйте, ReSanity, Вы писали:

RS>Здравствуйте, мыщъх, Вы писали:

М>>то есть, вы даже сами не знаете сколько это стоит. хотя бы порядок. схема мутная и запутанная.



RS>Так как мы только начинаем выходить на рынок, то сейчас будут действовать очень дешевые тарифы для shareware-сегмента.

RS>По самому дешевому тарифу, предназначенному для триалок:

RS> один серийный ключ (perpetual, параллелизм = 1) будет стоить 3,08 у.е.,
и это вы называете "очень дешевые тарифы?". это больше 10% от стоимости типичной шаровары. совсем чуть-чуть доплатить и хватит на аппаратный ключ. а после окончания периода действия "очень дешевых тарифов" (с) электронные ключи будут даже дешевле.

Здравствуйте, bazis1, Вы писали:

B>круто. не знал. оно работает только для суффиксной формы, или в общем случае (скажем, X XOR SECRET)?

Главное, чтобы манипулируя X, мы могли добивать параметр ф-ции хэширования произвольным значением. В случае XOR — это точо возможно, достаточно взять X большей длины, чем SECRET.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, ReSanity, Вы писали:

RS>>Здравствуйте, мыщъх, Вы писали:

М>>>то есть, вы даже сами не знаете сколько это стоит. хотя бы порядок. схема мутная и запутанная.



RS>>Так как мы только начинаем выходить на рынок, то сейчас будут действовать очень дешевые тарифы для shareware-сегмента.

RS>>По самому дешевому тарифу, предназначенному для триалок:

RS>> один серийный ключ (perpetual, параллелизм = 1) будет стоить 3,08 у.е.,
М>и это вы называете "очень дешевые тарифы?". это больше 10% от стоимости типичной шаровары. совсем чуть-чуть доплатить и хватит на аппаратный ключ. а после окончания периода действия "очень дешевых тарифов" (с) электронные ключи будут даже дешевле.

Не нашел аппаратных ключей дешевле 8-10 баксов, может подскажите вендора у кого можно за 3$ с небольшим бакса приобрести?

Да и аппаратные ключи проблемно поставлять, они никак не дружат с цифровой дистрибуцией. Дистрибутив цифрой, а ключ через DHL доставлять? =)
В этом плане ключи существенно уступают онлайну, а если ключ потерять?

Здравствуйте, bazis1, Вы писали:

B>Здравствуйте, ReSanity, Вы писали:

B>Если продукт позволяет нетривиальные куски выполнять на сервере, то этот продукт делается в виде веб-сервиса и продается по подписке.
B>потому что если продукт терпим к недостаткам SaaS, то из него делается веб-сервис и ваш продукт пролетает. а если нетерпим, то ваш продукт тоже пролетает.

Если продукт не позволяет быть выполнен в виде веб-сервиса? те же Crysis, 3DMax, CAD-ы.
Содержать свою инфраструктуру под SaaS — это очень дорогое удовольствие. SaaS продукты — ощутимо дороже, чем софт из коробки.
Если задаться вопросом: почему некоторые вендоры уходят в SaaS? Может быть их туда гонит чудовищный уровень пиратства?

B>>>Только вот к защите реальных программ это не имеет никакого отношения, т.к.:
B>>>1. если выполнять нетривиальную функциональность на сервере, выши юзеры просто озвереют из-за задержек и необходимости постоянно быть на связи (а вдруг ваш сервер или их канал лег? а в дороге на ноутбуке запустить?)
А если правильно выбирать лицензируемую функциональность, а не пытаться выстрелить себе в голову? =)

RS>>Да, задержки имеют место быть, все очень сильно зависит от выбранных кусков кода (чем меньше "прыжков" исполнения между клиентом и сервером, тем меньше задержка). Достаточно быстро можно подобрать подходящие регионы кода, которые не будут вносить задержки и будут весьма стойкими к атаке на "черный ящик".
B>не будут вендоры этим заниматься.
Если это окупится и принесет существенную прибыль, то почему нет?

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

Весьма спорно. Да, рынок десктопов сейчас сжимается, но не исчезнет никогда, причина простая: с ПК на планшеты уходят пользователи, которым компьютер был нужен только для "веселой фермы", "пасьянса", соц. сетей и т. п., они и так софт почти не покупают(ли) — это мелкая потеря для рынка коробочного софта.
Люди, которым компьютер нужен: для работы, учебы или "тяжелых игр" останутся — это и есть целевой сегмент.

Продукты лицензированные конкурентами, выходят на торрентах через 2 часа после релиза с пометкой "таблетка встроена". Да, им не требуется онлайн — это преимущество. =)
Зачем вендоры платят за это (уж незнаю, много там или нет)?

Здравствуйте, Annnimos, Вы писали:


A>Если продукт не позволяет быть выполнен в виде веб-сервиса? те же Crysis, 3DMax, CAD-ы.
A>Содержать свою инфраструктуру под SaaS — это очень дорогое удовольствие. SaaS продукты — ощутимо дороже, чем софт из коробки.
A>А если задаться вопросом: почему некоторые вендоры уходят в SaaS? Может быть их туда гонит чудовищный уровень пиратства?

B>>>>Только вот к защите реальных программ это не имеет никакого отношения, т.к.:
B>>>>1. если выполнять нетривиальную функциональность на сервере, выши юзеры просто озвереют из-за задержек и необходимости постоянно быть на связи (а вдруг ваш сервер или их канал лег? а в дороге на ноутбуке запустить?)
A>Абсолютно универсальных технологий не бывает, у любой есть, своя область применения, если эта система лицензирования не подходит Word-у это не значит, что она не подходит всем остальным видам коробочных программных продуктов.

RS>>>Да, задержки имеют место быть, все очень сильно зависит от выбранных кусков кода (чем меньше "прыжков" исполнения между клиентом и сервером, тем меньше задержка). Достаточно быстро можно подобрать подходящие регионы кода, которые не будут вносить задержки и будут весьма стойкими к атаке на "черный ящик".
B>>не будут вендоры этим заниматься.
A>Если это окупится и принесет существенную прибыль, то почему нет?

A>Продукты лицензированные конкурентами, выходят на торрентах через 2 часа после релиза с пометкой "таблетка встроена".
A>Зачем вендоры коробочных продуктов им платят деньги (уж незнаю, много там или нет), я лично не понимаю? Но да, им не требуется онлайн — это преимущество. =)

Видимо Крис недостаточно доходчиво объяснил сложившуюся на рынке ситуёвину.

Есть разные пользователи.

Жирные компании типа Raytheon и ему подобные, те самые потребители упомянутых выше CAD'ов, принципиально не используют онлайн лицензирование. Таковы внутрикорпоративные полиси. Ты можешь навешивать любую защиту при условии, что лицензирование будет работать через FlexLM (которую сломать может ребенок, а стоит она для вендора ого-го).

Компании помельче к онлайн лицензированию относятся лучше, но тоже предпочитают держать все в своих руках — чтобы информация о лицензиях (сколько, какие, когда заканчивается) всегда была под рукой. Пока еще нет доверия к "облачным" лицензиям. Сетевая лицензия с локальным сервером или аппаратным донглом — вот это любят, да еще желательно чтобы работало и под виндой, и под линюхом.

Онлайн лицензии могут сработать в комплекте с дополнительными онлайн сервисами. Например, для тех же САПРов это могут быть библиотеки компонентов/узлов, доступные онлайн. Только если продукт будет поставлять одна компания, а сервер лицензии будет у другой, вот этого точно не поймут
И, как верно заметили коллеги, работать должно через http, а не экзотические порты — задолбаешься доказывать сисадмину, что надо открыть порты за какой-то мутной надобностью. Кстати, еще один момент в работе с крупными компаниями — конечные пользователи не занимаются приобретением и контролем лицензий. Для этого есть специально обученные люди. Из документации к ReSanity не понял, такой режим работы возможен или нет. А в целом для кустарей-одиночек с мотором схема вполне пригодная.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Видимо Крис недостаточно доходчиво объяснил сложившуюся на рынке ситуёвину.
Крис это кто?

SVZ>Есть разные пользователи.
SVZ>Жирные компании типа Raytheon и ему подобные, те самые потребители упомянутых выше CAD'ов, принципиально не используют онлайн лицензирование. Таковы внутрикорпоративные полиси.
SVZ>Ты можешь навешивать любую защиту при условии, что лицензирование будет работать через FlexLM (которую сломать может ребенок, а стоит она для вендора ого-го).
SVZ>Компании помельче к онлайн лицензированию относятся лучше, но тоже предпочитают держать все в своих руках — чтобы информация о лицензиях (сколько, какие, когда заканчивается) всегда была под рукой. Пока еще нет доверия к "облачным" лицензиям. Сетевая лицензия с локальным сервером или аппаратным донглом — вот это любят, да еще желательно чтобы работало и под виндой, и под линюхом.
SVZ>Онлайн лицензии могут сработать в комплекте с дополнительными онлайн сервисами. Например, для тех же САПРов это могут быть библиотеки компонентов/узлов, доступные онлайн. Только если продукт будет поставлять одна компания, а сервер лицензии будет у другой, вот этого точно не поймут
SVZ>И, как верно заметили коллеги, работать должно через http, а не экзотические порты — задолбаешься доказывать сисадмину, что надо открыть порты за какой-то мутной надобностью.

Да, в общем-то и на урановые центрифуги, АЭС и подобные, никто не будет ставить онлайн софт, там вообще интернет запрещен под страхом смертной казни, да и софт туда абы какой вообще никак нельзя. К тому же врядли кто-то из Raytheon или того же Boeing будет сливать лицензионный софт на трекеры (но не исключено).

Сегменты, которые ты описываешь — это просто примеры сегментов не подходящих для онлайн лицензирования (по крайней мере в текущей объективной реальности), но это далеко не единственный сегмент на рынке коробочного ПО и никак не делает идею/технологию нежизнеспобной или плохой.
С игрушками и home user-ами все по-другому.
Под корпоративный сегмент, можно что-то придумать, например: засунуть облачко в железную коробочку и DHL-ом отправить корпоративному клиенту =)

SVZ>А в целом для кустарей-одиночек с мотором схема вполне пригодная.

Здравствуйте, Annnimos, Вы писали:

SVZ>>Видимо Крис недостаточно доходчиво объяснил сложившуюся на рынке ситуёвину.
A>Крис это кто?
мыщъх

A>Под корпоративный сегмент, можно что-то придумать, например: засунуть облачко в железную коробочку и DHL-ом отправить корпоративному клиенту =)

Для корпоративного сегмента стоит налегать не на защиту, а на гибкость лицензирования. Вот в этом FlexLM трудно превзойти.

Здравствуйте, ReSanity, Вы писали:

RS>Пока мы остановили свой выбор на собственном протоколе над TCP. Для домашних пользователей лицензированного софта это не будет проблемой

Многие домашние пользователи сидят за NAT'ом. Любой дешёвый wifi-роутер — это уже NAT. И средняя домохозяйка понятия не имеет, как там пробросить нужные порты на домашний компьютер.

Здравствуйте, Annnimos, Вы писали:

A>Если задаться вопросом: почему некоторые вендоры уходят в SaaS? Может быть их туда гонит чудовищный уровень пиратства?
Потому что там выше общая конверсия, проще сопровождение лидов и сбор статистики.

A>А если правильно выбирать лицензируемую функциональность, а не пытаться выстрелить себе в голову? =)
То непонятно, зачем нужен ваш продукт. Найти подобные куски довольно нетривиально, а найдя их руками заremoteить их через какой-нибудь SOAP — как раз довольно просто и никакие сторонние продукты для этого не нужны.

B>>не будут вендоры этим заниматься.
A>Если это окупится и принесет существенную прибыль, то почему нет?
Потому что не принесет. Не смогут взломать, будут кардить. Не смогут покардить, будут кусать локти и сидеть на бесплатных аналогах. "Существенную прибыль" принесет простейшая система активации, которая не позволит ленивым корпоративщикам бесконечно продлевать триал, поправив один ключик в реестре, тупо потому что это проще, чем заполнять 100500 анкет отдела закупки.

A>Весьма спорно. Да, рынок десктопов сейчас сжимается, но не исчезнет никогда, причина простая: с ПК на планшеты уходят пользователи, которым компьютер был нужен только для "веселой фермы", "пасьянса", соц. сетей и т. п., они и так софт почти не покупают(ли) — это мелкая потеря для рынка коробочного софта.
A>Люди, которым компьютер нужен: для работы, учебы или "тяжелых игр" останутся — это и есть целевой сегмент.
Дело не в том, что останется, а в том, что выводить продукт на рынок, прошедший этап быстрого роста — это как пытаться пришить новую руку взрослому человеку.

A>Продукты лицензированные конкурентами, выходят на торрентах через 2 часа после релиза с пометкой "таблетка встроена". Да, им не требуется онлайн — это преимущество. =)
A>Зачем вендоры платят за это (уж незнаю, много там или нет)?
Потому что так исторически сложилось, пока рынок рос.