А, я подумал что написать адаптер который позволит вызывать как моем финальном варианте.
Да, тот вариант что вы предлагаете действительно прост в исполнении, но все равно я предпочту свой интерфейс. (плюс я не доволен кодом и сложностью lodash)
Там проблемы не только в самом интерфейсе, но и в строгости. Этот функционал в lodash просто отсуствует.
Даже если вопрос был исключительно в удобности интерфейса, написать с нуля будет проще, чем писать такой адаптер.
Да, я уже говорил, что я читал научные статьи про математическую обфускацию.
Основная проблема, которую я вижу — есть классы функций, которые нельзя безопасно обфусцировать,
и есть *некоторые* функции, для которых придумали обфускацию. Этих функций очень мало, они «скучные» или их роль может выполнить другим путем.
> обфускация ПО для противодействия поиска уязвимости по патчу
Я вижу две проблемы:
— мне дается код, который я не должен понимать и он должен предоставить мне «безопасность». Security though obscurity.
— для детектирования «атаки» может понадобиться такая функция, которую невозможно безопасно обфусцировать.
> маркировка ПО.
Зачем?
> Существование универсальной обфускации в терминах определения чёрного ящика дало бы нам полную защиту ПО от обратной разработки.
Это *совершенно* ужасная цель.
> Можно просто ограничить функциональность на ровне интерфейса
Я уже много раз говорил это, но повторюсь: DRM это фундаментально плохая идея. Она не несет *ничего* хорошего.
С тех пор как я написал свой комментарий, я прочел несколько статей об «математической» обфускации программ,
и все еще считаю, что это бесполезная штука, которая может использоваться исключительно для DRM.
> i+=2 vs i++; i++;
1. Математически, это две одинаковые программы и они скомпилируются в один и тот же машинный код оптимизирующим компилятором.
2. Если они скомпилируются в разный код, то будут отличаться по таймигу.
3. Это не программа из реального мира.
> абсолютно некорректное утверждение.
История показывает обратное — люди разбирают существующие программы и неимоверное количество кряков в прошлом это весомый аргумент в мою сторону. Какие ваши аргументы?
Технически это означает, что для начинающих программистов подсветка кода важна в большей степени, чем для опытных.
то можно сказать почему так происходит — для опытных программистов, пишущих операционные системы подсветка синтаксиса менее полезна. Но это не значит, что она вредна, или бесполезна для остальных.
Если честно, я не вижу фундаментальной разницы между ними. Да, они отличаются, но принцип — тот же.
При желании можно писать макросы как в CL: gist.github.com/m1el/084477b3db4c5f6bd202
> Дальнейшее развитие DRM
Автор не слышал новости про White-box crypto
> Проблемы Digital Rights Management
> Наверное, главная технологическая проблема — открытость платформы.
Когда уже до управляющего звена дойдет, что DRM это фундаментально сломанная идея.
И единственная проблема DRM — это факт его существования. DRM неполноценен на уровне замысла.
Проблема в мозгах тех кретинов, которые считают, что DRM может решить какую-либо проблему касающуюся мультимедиа.
Максимум того что могут все существующие имплементации DRM для мультимедиа это вызывать проблемы для конечного пользователя.
Все существующие имплементации DRM были сломаны.
DRM не работает. DRM тратит ресурсы производства. DRM плох для конечного пользователя. DRM плох для архивации. DRM плох для ремиксов. DRM плох для цитирования. DRM плох для семьи. DRM убивает котят.
> Альтернативны Digital Rights Management в книгоиздании
Не использовать DRM.
Можно использовать и DOMDocument для генерации HTML, и это подходит под мой критерий. Но апи у него очень громоздкое.
В качестве примера того что я имею в виду я выберу React.js.
А, я подумал что написать адаптер который позволит вызывать как моем финальном варианте.
Да, тот вариант что вы предлагаете действительно прост в исполнении, но все равно я предпочту свой интерфейс. (плюс я не доволен кодом и сложностью lodash)
Справедливости ради, эта библиотека решает больше вопросов чем просто сортировка :)
Там проблемы не только в самом интерфейсе, но и в строгости. Этот функционал в lodash просто отсуствует.
Даже если вопрос был исключительно в удобности интерфейса, написать с нуля будет проще, чем писать такой адаптер.
[ответ не туда]
Спасибо, такой подход это один из вариантов который я рассматривал, и правда можно довольно выразительно это сделать.
Но есть несколько замечаний:
compare_numbможно делать черезcompare_stringи не обрабатываетNaN.огр
афи
я
Основная проблема, которую я вижу — есть классы функций, которые нельзя безопасно обфусцировать,
и есть *некоторые* функции, для которых придумали обфускацию. Этих функций очень мало, они «скучные» или их роль может выполнить другим путем.
> обфускация ПО для противодействия поиска уязвимости по патчу
Я вижу две проблемы:
— мне дается код, который я не должен понимать и он должен предоставить мне «безопасность». Security though obscurity.
— для детектирования «атаки» может понадобиться такая функция, которую невозможно безопасно обфусцировать.
> маркировка ПО.
Зачем?
> Существование универсальной обфускации в терминах определения чёрного ящика дало бы нам полную защиту ПО от обратной разработки.
Это *совершенно* ужасная цель.
> Можно просто ограничить функциональность на ровне интерфейса
Я уже много раз говорил это, но повторюсь: DRM это фундаментально плохая идея. Она не несет *ничего* хорошего.
и все еще считаю, что это бесполезная штука, которая может использоваться исключительно для DRM.
> i+=2 vs i++; i++;
1. Математически, это две одинаковые программы и они скомпилируются в один и тот же машинный код оптимизирующим компилятором.
2. Если они скомпилируются в разный код, то будут отличаться по таймигу.
3. Это не программа из реального мира.
> абсолютно некорректное утверждение.
История показывает обратное — люди разбирают существующие программы и неимоверное количество кряков в прошлом это весомый аргумент в мою сторону. Какие ваши аргументы?
При желании можно писать макросы как в CL:
gist.github.com/m1el/084477b3db4c5f6bd202
js: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label
rust: stackoverflow.com/questions/22905752/named-breaks-in-for-loops-in-rust
Автор не слышал новости про White-box crypto
> Проблемы Digital Rights Management
> Наверное, главная технологическая проблема — открытость платформы.
Когда уже до управляющего звена дойдет, что DRM это фундаментально сломанная идея.
И единственная проблема DRM — это факт его существования. DRM неполноценен на уровне замысла.
Проблема в мозгах тех кретинов, которые считают, что DRM может решить какую-либо проблему касающуюся мультимедиа.
Максимум того что могут все существующие имплементации DRM для мультимедиа это вызывать проблемы для конечного пользователя.
Все существующие имплементации DRM были сломаны.
DRM не работает. DRM тратит ресурсы производства. DRM плох для конечного пользователя. DRM плох для архивации. DRM плох для ремиксов. DRM плох для цитирования. DRM плох для семьи. DRM убивает котят.
> Альтернативны Digital Rights Management в книгоиздании
Не использовать DRM.
В качестве примера того что я имею в виду я выберу React.js.
Но получается криво.
Он не подразумервался как оскорбление.