Библиотека Javascript: запутывать или не запутывать - который является [закрытым] вопросом

Google Closure Complier запутывает ваш код после того, как вы закончите его писать. То есть напишите свой код, прогоните его через компилятор и опубликуйте оптимизированные (и запутанные) js.

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

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

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

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

Причина, по которой Google и подобные компании не страдают от целого ряда конкурентов по вырезанию и вставке, заключается в том, что JavaScript является лишь частью пакета. Чтобы иметь хоть какую-то степень контроля над тем, как и где эти вещи используются, большой компонент должен быть основан на сервере. Хорошая новость в том, что вы можете использовать такие вещи, как Node.js, чтобы упростить разделение клиентского и серверного кода без необходимости повторной реализации частей на совершенно другом языке.

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

Вы можете увидеть элементы этого в том, как Google переходит к мета-библиотеке, которая просто служит загрузчиком для других их библиотек. Это шаг к объединению вызовов нагрузки для Google Apps, Google AdSense, Google Maps, Google Adwords и так далее.

Если вы хотите быть немного умным, вы можете быть похожими на Карты Google и добавить яд в свои библиотеки JavaScript, поскольку они обслуживаются динамически, чтобы они работали только в определенном субдомене. Это требует создания их по мере необходимости, и, хотя его всегда можно удалить с достаточным опытом, это предотвращает массовое копирование и вставку ваших файлов JavaScript. Вставить умный вызов, который проверяет document.href, несложно, и найти все эти экземпляры в агрессивно свернутом файле было бы особенно раздражающим и, вероятно, не стоит затраченных усилий.

Стандартный ответ на вопросы обфускации: Достаточно ли использования обфускатора для защиты моего кода JavaScript?

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

Как я могу управлять этими рисками (будучи умеет отлаживать ошибочный код, обеспечение / минимизация против ошибки обфускации)

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

Каков ваш опыт использования запутанный код в производстве environment?

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

Напишите свой веб-сайт во флэш-памяти, а еще лучше - в Silverlight. Это даст вашей компании непревзойденный графический интерфейс, от которого ваши конкуренты будут лить слюнки. Но скомпилированный характер flash / dotnet не позволит им легко проникнуть в ваш код. Для вас это беспроигрышная ситуация;)

Хотя обфускация в целом - это плохо, ИМХО, с Javascript ситуация немного другая. Идея состоит не в том, чтобы запутать сам Javascript, а в том, чтобы получить более короткую длину кода (полоса пропускания стоит дорого, и новички могут просто разозлиться, ожидая, пока ваш Javascript загрузится в первый раз). Первоначально называемая минификацией (с такими программами, как minify), она претерпела значительные изменения, и теперь доступен полный компилятор, такой как компилятор YUI и Google Closure Compiler. Такой компилятор выполняет статическую проверку (что хорошо, но только если вы следуете правилам компилятора), минификацию (например, замените это длинное имя переменной на «ab») и многие другие методы оптимизации. В конце концов, у вас есть лучшее из обоих миров: кодирование в нескомпилированном коде и развертывание скомпилированного (минифицированного и запутанного) кода.К сожалению, вам, конечно же, придется протестировать его более тщательно.

Вы можете принять бизнес-модель с открытым исходным кодом и лицензировать свои скрипты по лицензии GPL или Creative Commons BY-NC-ND или аналогичной

Факты обфускации JavaScript:

• Никто не может предложить 100% обфускацию JavaScript без взлома. Это означает, что со временем и знаниями любую обфускацию можно «отменить».
• Сократите! = Обфускация: Когда вы минимизируете, ваша цель: уменьшить размер кода. Минифицированный код выглядит совершенно по-другому и его гораздо сложнее читать (подсказка: jsbeautifier.com). Обфукация преследует совершенно другую цель: защитить код. Используемые преобразования пытаются защитить запутанный код от отладки и подслушивания. Обфускация может даже создать еще более крупную версию исходного кода, что полностью противоречит целям минификации.
• Обфускация! = Шифрование - это очевидная ошибка, которую часто делают люди.
• Обфускация должна значительно усложнить отладку, это одна из ее целей. Таким образом, если все сделано правильно, вы можете потерять много времени, пытаясь отладить запутанный код. Тем не менее, если это сделано правильно, появление новых ошибок является редкой проблемой, и вы можете легко определить, является ли это ошибкой запутывания, с помощью временная замена кода на не обфусцированный код.
• Обфускация - это НЕ пустая трата времени - это инструмент. При правильном использовании вы можете заставить других тратить кучу времени;)

Фантастика обфускации Javascript: (я пропущу этот раздел;))

Ответ на Q2 - Предлагаемые инструменты обфускации:

• Для обширного списка обфускаторов javascript : malwareguru.org . Мой личный выбор - jscrambler.com.

Ответ на вопрос 3 - опыт использования обфусцированного кода

• На сегодняшний день нет новых ошибок, вносимых обфускацией.
• Намного лучшее удержание клиентов. Они должны прийти к источнику, чтобы получить его;)
• Некоторые антивирусные инструменты сообщают о случайных ложных срабатываниях. Можно протестировать перед развертыванием любого нового кода с помощью такого инструмента, как Virustotal.com