Max Home IndustryЕсть мерзкие жестокие люди, которые говорят, что мой код получается предварительно запутанным. Они, конечно, ошибаются, но я не уверен, что мне бы хотелось отправить его в Google для утверждения в качестве расширения Chrome.
Когда вы назначаете себя привратником, я полагаю, что вы обязаны охранять ворота. Google только что объявил, что ужесточает правила для расширений Chrome. Вероятно, это хорошо, учитывая количество случаев вредоносного ПО или просто эксплойтов, распространяемых через расширения, но это все еще «интересное» положение для Google:
Двойная миссия команды расширений — помочь пользователям адаптировать функциональность Chrome к их индивидуальным потребностям и интересам, а также дать разработчикам возможность создавать богатые и полезные расширения. Но, прежде всего, крайне важно, чтобы пользователи могли быть уверены, что устанавливаемые ими расширения безопасны, сохраняют конфиденциальность и производительны. Пользователи всегда должны иметь полную прозрачность в отношении возможностей своих расширений и доступа к данным.
В те времена, когда единственными обнесенными стенами садами были настоящие сады с кирпичными стенами и растениями, пользователи должны были сами заботиться о себе. В основном они платили большие деньги за приложения, которые крупные надежные компании тратили много времени на разработку и обеспечение их качества и безопасности. Сегодня мы, как правило, скачиваем практически все, даже не зная, кто это написал и что это может скрывать. Вместо того, чтобы быть проблемой конечного пользователя, теперь ее взяли на себя производители браузеров и, в частности, руководители магазинов приложений. Теперь Google должен защищать пользователя, проверяя код приложений, которые он разрешает в Интернет-магазине Chrome.
Вы можете возразить, что в последнее время он не слишком хорошо справлялся со своей работой и, следовательно, с новыми мерами. Теперь пользователь может ограничить доступ расширения к данным на веб-странице, запросив разрешение или включив его в белый список.
Хорошо, это кажется разумным изменением, и на самом деле вам остается только спросить, почему потребовалось так много времени, чтобы понять.
Остальные изменения касаются процесса проверки кода, и это немного более проблематично. Это почти похоже на решение проблемы остановки или чего-то теоретически невозможного, но на самом деле это не так. Просто взглянув на код, решите, содержит ли он вредоносное ПО или что-то скрытое. Если бы это было возможно. Так что шаги довольно маленькие и, вероятно, неэффективные. Сначала приложения должны запрашивать только те разрешения, которые им действительно нужны, и если им нужно «мощное разрешение», они будут «подлежать дополнительной проверке соответствия». Да, кажется разумным предположить, что мощные разрешения приводят к опасному поведению.
Еще одно довольно очевидное улучшение — настаивать на двухэтапной проверке учетных записей Chrome Web Store. Раньше было слишком легко захватить учетную запись и изменить опубликованный код.
Также кажется очевидным, что если вы собираетесь получить вредоносное ПО через проверку кода, вам, вероятно, нужно его скрыть. Итак, следующий большой шаг — запретить запутанный код. Вы все еще можете минимизировать свой код, в частности, все разрешено:
Удаление пробелов, новых строк, комментариев к коду и разделителей блоков
Сокращение имен переменных и функций
Сворачивание количества файлов JavaScript
Честно говоря, зная JavaScript, я думаю, что мог бы сделать вещи довольно нечитаемыми и непостижимыми, используя только эти методы и небольшое количество отдельных уловок, которые было бы трудно увидеть при таком уровне минификации.
Но подождите, разве Google не просит вас разместить свой код в форме, упрощающей кражу! В конце концов, обфускация — это единственное, что есть у интерпретируемого кода защиты — фактически, сделать это имеет весь код.
… поскольку код JavaScript всегда выполняется локально на компьютере пользователя, обфускации недостаточно для защиты частного кода от действительно мотивированного реверс-инженера. Методы обфускации также сопряжены со значительными потерями в производительности, такими как более медленное выполнение и увеличение объема файлов и памяти.
Вот и все — обфускация не так хороша для защиты вашего кода, но, конечно, если она такая слабая, зачем ее запрещать? Почему бы просто не сделать так, чтобы ваши процедуры валидации справились с этим?
Тогда есть небольшая проблема: что такое запутанный код? Ясно, что существует спектр, и на дальнем конце код, искаженный далеко за пределами разумной практики, запутан, но как насчет умного или изобретательного кода, который использует JavaScript способами, о которых вы, возможно, не думали раньше. Что, если какой-нибудь умный программист изобретет что-то вроде раскрывающего паттерна конструктора, который позже стал основным способом создания промисов. Забанят ли это расширение, потому что это не очевидно?
КОД КАЧЕСТВО 2
Больше мультяшных забав на xkcd, веб-комиксе о романтике, сарказме, математике и языке
Как я шутил в начале этого отчета, некоторые люди утверждают, что мой код запутан естественным образом. Надеюсь, они шутят, но я вижу, что это новое правило может вызвать некоторые интересные проблемы с соблюдением правил.
Ян Эллиот — автор JavaScript Async, в котором, помимо прочего, он описывает раскрывающий паттерн конструктора.