Chrome Web Store отклоняет расширения, когда запрошенные права шире заявленной функции или их использование не объяснено. Шаблонные permissions из старого проекта, доступ ко всем сайтам и сбор данных «на будущее» повышают риск отказа. Нужно построить карту: пользовательская функция — API Chrome — минимальное разрешение — понятное раскрытие.

Удалите неиспользуемые permissions и host_permissions, замените постоянный доступ на activeTab или optional permissions там, где это возможно. Обновите описание, privacy policy и экран запроса так, чтобы проверяющий мог воспроизвести функцию.

Что проверить в первую очередь

Начните с воспроизводимого сценария: зафиксируйте время сбоя, идентификатор объекта, версию приложения или конфигурации и последнее известное рабочее состояние. Не меняйте несколько параметров одновременно. Один контролируемый шаг должен подтверждать или исключать одну гипотезу, иначе временное исчезновение симптома легко принять за исправление. Перед работой с данными и настройками подготовьте резервную копию и понятный способ отката.

  • Сравните manifest с реальными вызовами chrome.* и сетевыми доменами.
  • Проверьте причину отказа и policy section в письме Web Store.
  • Определите, какие права нужны всегда, а какие только после действия пользователя.
  • Просмотрите сторонние библиотеки на лишний сбор данных и remote code.

Почему возникает проблема

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

  • В manifest осталось tabs или <all_urls>, хотя функция работает на активной вкладке.
  • Host permissions покрывают домены, к которым код никогда не обращается.
  • Функция права не описана на странице магазина или недоступна проверяющему.
  • Privacy policy не перечисляет собираемые и передаваемые данные.
  • Сборка содержит remote hosted code или динамическое выполнение неподтвержденного скрипта.

Пошаговая диагностика

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

  • Найдите все chrome API и сопоставьте с документацией permissions.
  • Проверьте service worker, content scripts и injected scripts отдельно.
  • Запишите чистый сценарий установки и момент запроса optional permission.
  • Просмотрите network log расширения и список внешних endpoints.
  • Соберите release package заново и проверьте, что в нем нет dev-файлов и секретов.

Как применять принцип минимальных привилегий

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

  • activeTab дает временный доступ после явного действия пользователя.
  • optional_permissions запрашиваются перед конкретной дополнительной функцией.
  • Content scripts ограничиваются точными matches вместо всех URL.
  • Backend получает только данные, без которых функция не может работать.
  • Локальное хранение предпочтительнее передачи, если синхронизация не нужна.

Как исправить проблему

Разбейте исправление на небольшие обратимые изменения. Сначала устраните подтвержденную причину, затем повторите исходный сценарий и проверьте соседние функции. Массовое обновление данных запускайте на ограниченной выборке с отчетом и только после сверки расширяйте на весь объем. Не отключайте авторизацию, валидацию, шифрование или проверку сертификатов ради быстрого исчезновения ошибки.

  • Удалите разрешения без подтвержденных вызовов кода.
  • Сузьте host patterns до реальных HTTPS-доменов и путей, где возможно.
  • Перенесите редкие права в optional flow с понятным объяснением.
  • Обновите privacy disclosure и описание сценария проверки.
  • Уберите remote code, eval-подобное выполнение и лишние аналитические SDK.

Безопасный порядок внедрения

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

Как проверить результат

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

  • Чистая установка показывает только ожидаемый минимальный список прав.
  • Основной сценарий работает без <all_urls>, если глобальный доступ не нужен.
  • Отказ пользователем в optional permission не ломает остальные функции.
  • Release zip совпадает с проверенным исходным кодом и не содержит токенов.

Типичные ошибки при исправлении

  • Добавлять широкие права на случай будущей функции.
  • Объяснять permission только в privacy policy, но не в интерфейсе и карточке.
  • Отправлять тот же пакет без изменения после policy rejection.
  • Скрывать сбор данных под общим словом analytics.

Как предотвратить повторение

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

  • Добавьте review manifest permissions в процесс релиза.
  • Проверяйте зависимости и network destinations перед сборкой.
  • Ведите таблицу функций, данных, прав и срока хранения.
  • Тестируйте установку с чистым профилем Chrome и отказом от optional permissions.

Что подготовить для технического разбора

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

Частые вопросы

Всегда ли <all_urls> запрещен?

Нет, но он требует реальной основной функции, четкого объяснения и минимизации. Если достаточно activeTab или ограниченных matches, широкое право трудно обосновать.

Нужно ли заново публиковать privacy policy?

Если меняются данные, права или способы использования, policy и раскрытия должны быть обновлены до повторной отправки.

Когда нужна помощь специалиста

Если Chrome Web Store отклоняет расширение из-за разрешений, я могу провести аудит manifest и кода, сократить доступы, перестроить optional flow и подготовить пакет и объяснения для повторной проверки.