Мессенджеры, приватность и интернет — изнутри

Интернет

Как одно расширение для Chrome прошло шесть кругов объяснений, прежде чем попасть в магазин

В конце мая разработчик начал эксперимент: запустить шахматный движок Stockfish прямо в браузере, рядом с доской, чтобы не держать анализ в отдельной вкладке. Так появилось расширение ChessNavio, которое читает позицию на Lichess, Chess.com и ещё паре сайтов и показывает подсказку. Первая версия вышла 25 июля.

До магазина расширение распространялось архивом через GitHub — инструкция из шести шагов отпугивала больше половины пользователей ещё до начала установки, хотя из начавших скачивание до конца доходили 85 процентов. Подача в Chrome Web Store затянулась до осени из-за проблем с оплатой аккаунта разработчика, но основная работа ждала впереди. Форма публикации сама разобрала манифест расширения и потребовала объяснить каждое из семи разрешений в поле до тысячи символов.

Главное правило висело перед глазами: «Удалите все разрешения, не связанные с единственным назначением расширения. Если версия запрашивает ненужные разрешения, она будет отклонена». С этим предупреждением автор и сел переписывать обоснования.

Первым под переделку попало разрешение storage. В исходном варианте было написано, что в chrome.storage хранится история партий, хотя на деле история лежала в IndexedDB и никакого специального разрешения не требовала. Если бы проверяющий пошёл искать историю в chrome.storage, он бы её не нашёл — вывод напрашивался бы простой: либо автор не знает своего кода, либо прячет настоящее назначение.

В исправленной версии чётко перечислили, что именно хранится: настройки подсказок, сила движка, язык интерфейса и список подключённых сайтов. Разрешение scripting тоже пришлось усилить. Первая формулировка звучала расплывчато: расширение встраивает скрипты на страницы шахматных сайтов.

Так могло написать о себе любое вредоносное расширение. Настоящая защита нашлась в архитектуре кода: в манифесте нет статического content_scripts, всё регистрируется на ходу через registerContentScripts и только для тех сайтов, которые пользователь подключил сам. Проверяющему достаточно заглянуть в манифест, чтобы увидеть пустой массив.

Самый неприятный момент случился с разделом доступа к хостам. Автор перечислил все поддерживаемые площадки, но забыл указать api.chess.com — через него расширение восстанавливает запись партии из публичного архива игрока. Если бы проверяющий открыл сетевые запросы и увидел адрес, не упомянутый в обосновании, сразу возник бы вопрос, что ещё скрыто.

В итоге описание каждого хоста пришлось расписать отдельно, включая домен для входа и проверки подписки. Отдельного внимания заслужили широкие шаблоны http://*/* и https://*/*. В обычных host_permissions они заставили бы Chrome показать при установке пугающее предупреждение о чтении всех данных на всех сайтах, поэтому шаблоны лежат в optional_host_permissions.

Браузер спрашивает о них, только когда человек сам нажимает кнопку расширения на новом шахматном сайте, которого нет в базовом списке. Остальные четыре разрешения переписывать не пришлось. В обосновании offscreen было сказано, что движки работают в отдельном скрытом документе через WebAssembly, чтобы не тормозить страницу — в коде это видно по причине 'WORKERS'.

Alarms содержали описание двух постоянных фоновых задач, webNavigation нужен для отслеживания навигации внутри партии, Каждое объяснение содержало то, что проверяющий может найти в коде за минуту. Форма потребовала и другие детали. Единое назначение нужно было уместить в одно предложение: анализировать шахматную позицию на текущей странице и показывать предлагаемый ход рядом с доской.

С этим предложением потом сверяли каждое разрешение. Картинки требовались строго под заданные размеры: 1280 на 800 для скриншотов, 440 на 280 и 1400 на 560 для промо, иконка 128 на 128. Аккаунт издателя автор завёл отдельный, не личный, а публикацию после одобрения выбрал автоматической, а не ручной.

Главный вывод, который разработчик сделал для себя после подачи, оказался простым. В объяснении должно быть что-то, что проверяющий может сверить с кодом за минуту, даже не запуская расширение. Общие слова вроде «расширение встраивает скрипты» видны в каждой второй заявке и доверия не вызывают.

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

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

кибербезопасность приватность открытый веб

Оригинал

Обсуждение

Комментариев пока нет.

Похожие новости