Что показывают манифесты 10 расширений для Chrome: права, доступ и скрытые отличия

Каждое расширение Chrome поставляется с файлом manifest.json, в котором зафиксирована значительная часть его возможностей на уровне браузера: запрашиваемые API, шаблоны для хостов, статические content scripts, необязательные разрешения и допустимые внешние подключения. Это публичный файл внутри пакета, который вы устанавливаете. Но он не доказывает, какие именно заявленные возможности использует код во время работы, что уходит с компьютера и какой доступ к аккаунту происходит через отдельный веб-логин.

Я изучил десять расширений для скрейпинга и автоматизации браузера, отобранных для этого аудита, включая Thunderbit — наше собственное расширение. Разброс очень большой. У одного не указано постоянное право доступа к сайтам. У другого перечислено тринадцать разрешений, включая clipboardRead. Thunderbit — единственное расширение в этой выборке, которое заявляет debugger, то есть широкий режим подключения через CDP, с иным профилем риска, чем доступ к страницам, OAuth или пользовательские скрипты.

Это не обвинение. Широкое разрешение нередко бывает единственным честным способом реализовать нужную функцию, а узкое может означать, что продукт просто делает меньше. Суть в том, что различие огромное, оно опубликовано, и в сравнительные таблицы обычно не попадает.

Как это было сделано

Каждое расширение было скачано в виде .crx через официальный endpoint обновлений Google — тот же URL, который использует сам Chrome, — затем распаковано и разобрано. Ни одно расширение не устанавливалось, и код ни одного расширения не исполнялся. Это просто чтение JSON-файла.

Загрузки выполнялись с интервалом примерно одна заявка раз в две секунды. Для каждого .crx, его SHA-256 и извлечённого manifest.json сохранены артефакты. Thunderbit проходил через тот же скрипт, что и остальные девять расширений, без каких-либо обходных путей, поэтому его строка получена точно так же, как и остальные.

Анализ опирается на два класса доказательств и не смешивает их:

• Заявленное статическое поведение: шаблоны хостов и записи content_scripts, включая matches, run_at и all_frames.
• Возможности, доступные коду во время работы: API, перечисленные в permissions или optional_permissions. Эти записи показывают, что код может запросить или вызвать, но не доказывают, что он это делает.

Никакого ранжирования по типу «самый мощный» не присваивается. debugger, userScripts, широкий доступ к хостам, OAuth-области, доступ к буферу обмена и внешние сообщения открывают разные типы данных и требуют разных предварительных условий. Сравнивать их можно только при наличии модели угроз, а этот аудит, основанный только на manifest-файлах, такой модели не даёт.

Ниже приведённые размеры — это распакованные объёмы в MiB (2²⁰ байт), просуммированные по ZIP-элементам.

Актуально на 2026-07-29. Расширения обновляются; перед цитированием проверьте ещё раз.

Что заявляют десять manifest-файлов

Официальная справка: Chrome's permission declaration guide.

Ещё два продукта были в списке кандидатов, но не попали в таблицу — и причины этого заслуживают отдельного упоминания.

Разброс — это выбор архитектуры, а не следствие размера

Agenty не заявляет host permissions и вообще не поставляет content scripts. Его четыре разрешения — activeTab, scripting, identity и identity.email. activeTab — это узкий вариант: он даёт доступ к текущей вкладке только после клика по расширению и только до перехода на другую страницу. Ничего не запускается на ваших страницах, пока вы сами не активируете расширение. При этом размер — 2.2 MiB.

Axiom.ai заявляет http://*/* и https://*/*, внедряет content scripts, совпадающие с <all_urls>, и распаковывается до 37.1 MiB в 232 файлах — это в семнадцать раз больше, чем у Agenty, при постоянном доступе ко всем страницам, которые вы посещаете.

Hexomatic похож на Agenty: два разрешения (storage, tabs), без host permissions, а content scripts ограничены двумя собственными доменами.

Clay for Chrome — ещё один отдельный случай: он заявляет *://*/* как host permission, но вставляет content scripts только на собственном домене. Потенциальные возможности широкие, а автоматическое поведение узкое. Одна только таблица разрешений смешивает эти вещи.

Пять из десяти могут добираться до файлов на вашем диске

file:/// — это не сайт. Это ваша локальная файловая система, отображаемая во вкладке браузера: PDF, который вы открыли, HTML-экспорт, скачанный счёт.

Официальная справка: Chrome match-pattern documentation.

Три расширения говорят об этом напрямую. Ещё два достигают этого без прямого упоминания: <all_urls> включает схему file:.

http://*/* и https://*/* не покрывают file://; <all_urls> и *://*/* тоже различаются по этому параметру. Пять вариантов здесь — это те, чьи декларации доходят до этой схемы тем или иным путём, а не результат выбора конкретного шаблона wildcard.

Chrome закрывает это отдельным переключателем «Allow access to file URLs» для каждого расширения, и он выключен по умолчанию, поэтому декларация — это запрос, а не автоматическое предоставление права. Пять из десяти — честный счёт, и два из этих пяти вообще нигде не пишут file:// в manifest: Axiom.ai и наше расширение.

В этот подсчёт входит web_accessible_resources, а не только content scripts и host permissions. Table Capture прямо указывает file://*/* именно там; если бы этот блок не учитывать, его ошибочно отнесли бы к расширениям, которые достигают файлов, не называя схему.

Разрешения, которые не видны, пока их не запросят

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

userScripts отсутствует, пока его не запросят, и невидим для любого, кто просто считает разрешения.

Кроме того, для него есть ещё один барьер, которого нет у остальных разрешений в этом аудите, и если это не учитывать, его роль будет переоценена. Само по себе объявление userScripts недостаточно, чтобы использовать его: Chrome требует сначала явного действия пользователя. До Chrome 138 этим барьером был Developer Mode, включаемый глобально на chrome://extensions. Начиная с Chrome 138, это отдельный для расширения переключатель Allow User Scripts на странице подробностей расширения, выключенный по умолчанию. Значит, для обычной установки возможность задекларирована, но неактивна. Точное утверждение условно: Table Capture может сделать API userScripts доступным после того, как пользователь включит соответствующий шлюз Chrome. В этом аудите не измерялось, как часто пользователи заходят на эту страницу и включают переключатель.

Ни одно из них не скрыто; оба есть в manifest. Таблица, игнорирующая optional block, недооценивает два продукта.

Время внедрения, а не только охват

Важно не только куда внедряется content script, но и как именно. document_start — это самый ранний хук, который предоставляет Chrome; all_frames охватывает сторонние встраивания.

Все элементы выборки, которые статически внедряются во все фреймы, в порядке заявленного времени:

Table Capture и Listly используют самый ранний хук при широких шаблонах совпадения. Axiom.ai и Clay for Chrome используют ту же раннюю стадию, но только на собственных доменах — та же агрессивность, но узкая область применения.

Для статических деклараций <all_urls> плюс all_frames — это потолок по широте совпадения, и здесь и Table Capture, и Thunderbit находятся именно там. Но заявленное время у них разное: Table Capture использует document_start, а статический content script Thunderbit — document_end. Runtime API — это отдельный класс возможностей, и из этой таблицы его не вывести.

Счётчик разрешений — плохая сводная метрика. Table Capture заявляет четыре разрешения — меньше, чем большинство в этой подборке, — и всё же внедряется в all_frames на document_start для <all_urls>, плюс получает userScripts по запросу.

Кто вообще может писать расширению сообщения

externally_connectable управляет тем, какие веб-страницы или другие расширения могут отправлять сообщения прямо в background script расширения. Значение по умолчанию здесь неочевидно.

Если ключ опущен, это и есть разрешающий вариант. По умолчанию Chrome, когда externally_connectable отсутствует, позволяет подключаться любому расширению, но не позволяет подключаться веб-страницам. Если вы указываете этот ключ, то тем самым ограничиваете доступ.

Если смотреть на таблицу с этой точки зрения, всё переворачивается:

Правило Chrome имеет два уровня. Из официальной справки:

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

Axiom.ai задаёт ключ, но заполняет только matches. Значит, ids у него не задан, а это означает, что ни одно расширение не может писать ему сообщения — канал для расширений закрыт, а не оставлен открытым. При этом он открыл семь web origins, и только один из них принадлежит Axiom: два — это сторонние домены, которые нельзя привязать к самому продукту (*://*.tgwc.space/*, *://*.bitmachine.co.uk/*), а остальные — localhost, 0.0.0.0, хост Google APIs и одна крупная соцплатформа, которой он не управляет.

Hexomatic открывает канал для расширений на восемь указанных IDs. При наличии ключа базовое состояние — ноль расширений; если назвать восемь, канал открывается для восьми. Его шесть matches расширяют второй канал из нуля, и два из них — это http://localhost:8000/* и http://localhost:3000/* по обычному HTTP — то есть всё, что отвечает на этих портах на машине пользователя, попадает в allowlist.

Семь из десяти полностью опускают ключ, включая наше расширение, и именно они остаются в разрешающем состоянии по умолчанию для сообщений между расширениями. Два расширения закрывают этот канал: Magical — явно через ids: [], а Axiom.ai — задавая ключ и вовсе не упоминая ids. Magical — единственное, которое закрывает оба канала.

Именно поэтому нужно читать manifest, а не просто считать разрешения. Одно и то же расширение может быть широким по одному параметру и самым строгим в наборе по другому.

Ось, которую никто не считает: OAuth scopes

В manifest может быть блок oauth2, а scopes внутри него — это доступ к вашим аккаунтам в других компаниях. Это совсем другой уровень охвата, и никакой счётчик разрешений его не отражает.

Официальная справка: Google OAuth 2.0 scope list.

https://www.googleapis.com/auth/drive — это широкий вариант. У Google есть более узкий scope drive.file, который даёт доступ только к файлам, созданным самим приложением или явно выбранным пользователем; auth/drive позволяет видеть, редактировать, создавать и удалять файлы во всём Google Drive пользователя. auth/spreadsheets имеет такой же характер для всех таблиц, к которым аккаунт получает доступ. И Axiom.ai, и Table Capture сочетают scope для Google-аккаунта с доступом к страницам через <all_urls>.

Два ограничения, что именно доказывает эта таблица. Scope — это запрошенное, а не выданное право: Google покажет экран согласия, пользователь может отказать, и расширение может вообще не вызывать API. Кроме того, manifest видит только OAuth, реализованный через identity в Chrome; если расширение вместо этого отправляет вас на веб-страницу входа, здесь вообще ничего не будет заявлено. Семь нулей означают «в этом файле не запрашивалось», а не «нет доступа к вашему Google-аккаунту» — включая наше расширение, именно поэтому эта ось здесь приводится как отдельный факт, а не как утверждение об узости.

Наше собственное расширение на той же шкале

Thunderbit 4.6.4 прошёл через тот же парсер manifest, что и остальные девять. Пакет распаковывается до 15.9 MiB и содержит 78 файлов.

Заявленное статическое поведение: <all_urls> присутствует и в host permissions, и в совпадениях content script. Статический script работает во всех фреймах на этапе document_end. Поскольку <all_urls> включает file:, manifest может добираться до локальных файлов после того, как пользователь включит файловый доступ в Chrome. Thunderbit также опускает externally_connectable, так что по умолчанию Chrome разрешает сообщения от любого расширения, но не от веб-страницы.

Потолок возможностей во время работы: массив permissions содержит девять строк: activeTab, commands, debugger, offscreen, scripting, sidePanel, storage, tabGroups и tabs. Chrome распознаёт восемь из них как разрешения; commands — это ключ верхнего уровня в manifest и не имеет эффекта как элемент этого массива. Thunderbit — единственное расширение в выборке, которое заявляет debugger, способный подключать CDP к вкладке. Manifest также делает scripting доступным для регистрации во время работы. Эти API создают возможности, выходящие за рамки статической строки document_end, но прочтение manifest не может доказать, вызывает ли Thunderbit конкретный метод CDP или регистрирует ли скрипт в более ранний момент.

Такое различие не даёт делать несколько заманчивых, но неверных сравнений. Отсутствие более узкого разрешения cookies не ограничивает то, к чему может получить доступ код с debugger. Отсутствие clipboardRead не доказывает, что доступ к буферу обмена невозможен. И наоборот, наличие debugger не означает, что эти пути действительно используются. Ответ на любой из этих вопросов требует анализа исходников или runtime tracing, а ни того, ни другого здесь не проводилось.

По этому инструменту Thunderbit широк по статическому доступу к сайтам, уникален в выборке благодаря debugger и находится в состоянии Chrome по умолчанию для сообщений между расширениями. Единого рейтинга «самый сильный» нет, потому что аудит не задаёт общую модель угроз для CDP, OAuth, userScripts, буфера обмена и доступа к хостам.

Самый сдержанный дизайн, о котором никто не пишет в маркетинге

TexAu — всего 0.3 MiB, это вдвое меньше любого другого в списке, и он указывает четырнадцать конкретных сайтов, а не использует wildcard: соцсети, платформу для разработчиков, издательские платформы, чат-продукт, поставщика бизнес-данных и собственный домен. Его content scripts совпадают ровно с этими четырнадцатью.

По этому manifest можно точно понять, где расширение активно. Это ещё и честное описание продукта — список целей говорит, для чего он нужен, куда яснее, чем маркетинг.

Компромисс реален: список с именованными доменами не может работать на сайте, которого в нём нет, и каждый новый target требует релиза. Но «четырнадцать указанных доменов» и «любой URL в интернете» — это очень разные вещи, и только одна из них читается однозначно.

Два продукта, которые оказались не тем, чем казался список

Расширение Captain Data не распространяется публично. Официальный endpoint обновлений Google возвращает HTTP 204 с пустым телом для его extension ID — так отвечает нечто, что магазин не раздаёт анонимно. А вот его страница в магазине отдавала контент анонимно — HTTP 200, 509,829 байт. Однако в захваченном ответе не удалось найти ни строки версии, ни даты последнего обновления, ни количества установок; в собственных заметках скрипта сказано, что null здесь — слабое доказательство, и признаков обязательной авторизации не наблюдалось. ID настоящий и first-party, так что наиболее вероятно либо распространение по ссылке без публичного листинга, либо скрытый листинг, но отличить одно от другого я не смог и не буду гадать.

Dataflow Kit вообще не имеет Chrome-расширения. На сайте описаны hosted web app с выбором объектов point-and-click и REST API. Тем не менее его всё равно включали в шорт-лист расширений Chrome — так подобные списки обычно и собираются.

Устаревание и охват, раз уж это бесплатно проверить

Метаданные магазина добавляют контекст для выбора продукта сверх одних только разрешений. Те же поля были собраны для всех расширений 2026-07-30.

Три продукта не обновлялись больше года, а Hexomatic — почти два. Для расширений это важнее, чем для библиотек: Chrome выходит в стабильной версии примерно раз в четыре недели, и сама платформа расширений постоянно меняется под ней. userScripts изменил свой пользовательский барьер в Chrome 138; расширение, выпущенное в 2024 году, создавалось под другой набор правил, чем тот, который браузер теперь применяет.

Два момента, которыми эта таблица не является. Количество установок Google группирует по диапазонам — 1,000 / 3,000 / 7,000 / 10,000 / 100,000 / 200,000 — так что они пригодны только для сравнения порядка величин, и не более; при этом некоторые продукты в своём маркетинге заявляют более высокие числа. Свежая дата — это факт о выпуске, а не оценка качества поддержки или риска разрешений.

Полезный побочный результат: версия в магазине совпадает с версией manifest у всех десяти проанализированных пакетов. CRX-файлы, которые разбирал этот аудит, — это именно те, что магазин отдает сегодня, а не устаревшие копии.

Свежесть влияет на то, сколько последующей проверки заслуживает выбор, но не меняет семантику manifest. Расширение с перечисленными доменами, обновлённое год назад, всё ещё может открывать меньше поверхности страницы, чем расширение с wildcard, выпущенное вчера. А более новый пакет может быть лучшим операционным выбором, если он быстро подстраивается под изменения Chrome. Для шорт-листа используйте дату в магазине, чтобы понять, что нужно перепроверить, а manifest — чтобы понять, что требует более глубокого анализа возможностей. Не превращайте два столбца в один балл.

Что manifest не говорит

Заявленное разрешение — это потолок, а не поведение. <all_urls> означает, что расширение может читать каждую страницу. Это не означает, что оно это делает, или что что-то вообще уходит с вашей машины. Чтобы понять, что происходит на самом деле, нужно смотреть сетевой трафик во время работы — это уже другая задача, и здесь она не выполнялась; всё сказанное выше не следует считать доказательством злоупотребления.

Связанный разбор: Chrome extension testability experiment.

Ещё три границы:

• Chrome многое из этого ограничивает. Доступ к файлам выключен по умолчанию; activeTab намеренно узок; необязательные разрешения требуют runtime prompt; при установке пользователь видит список разрешений.
• Широкие разрешения часто действительно необходимы. Инструмент, чья задача — «извлечь таблицу с любой открытой страницы», не может работать на списке разрешённых доменов. Узкая область иногда означает дисциплину, а иногда — просто более ограниченный продукт.
• Одна версия, один день. Все цифры относятся к пакету, доступному 2026-07-29.

Существенные уточнения в анализе

Опубликованные подсчёты используют три правила, которые легко перепутать, если быстро писать парсер manifest. Во-первых, <all_urls> включает схему file:, но Chrome держит реальный доступ к файлам за пользовательским переключателем. Во-вторых, web_accessible_resources.matches нужно проверять вместе с content scripts и host permissions; именно там Table Capture прямо называет file://*/*. В-третьих, externally_connectable работает по-разному в зависимости от того, отсутствует ли весь ключ целиком или он есть, но одно из подполей пустое. Таблицы выше применяют эти правила последовательно.

В подсчёте разрешений Thunderbit также различаются сырые строки и распознанные Chrome permissions. В массиве девять элементов, но commands относится к верхнему уровню, поэтому эффективный счёт здесь — восемь распознанных permissions плюс одна нераспознанная строка. Наконец, статические декларации content_scripts не доказывают, что код вызывает scripting.registerContentScripts или метод CDP. Эти возможности относятся только к runtime capability, а не к наблюдаемому поведению. Сырые manifest-файлы, SHA-256 CRX и вывод парсера — это аудит-трейл для этих нормализаций, так что читателю не нужно просто верить тексту на слово.

Для реального решения об установке нужно отдельно сравнивать как минимум четыре параметра: какие страницы входят в область по умолчанию, какое явное действие пользователя открывает больший доступ, какие браузерные или account API становятся доступны и кто снаружи может писать расширению сообщения. Модель Agenty с activeTab, gated userScripts в Table Capture, scope к Drive в Axiom.ai и debugger в Thunderbit — это не точки на одной шкале. Это разные ответы на разные вопросы безопасности.

Вот это сравнение, применённое к четырём намеренно разным дизайнам:

Эта таблица всё ещё не даёт победителя. Узкий постоянный доступ Agenty к страницам ничего не говорит о том, что делает его backend с отправленными данными. OAuth-области Axiom.ai нельзя сопоставить с расширением, которое просто читает текущую страницу. Декларация userScripts у Table Capture остаётся инертной, пока пользователь не включит отдельный барьер. debugger у Thunderbit открывает широкую поверхность управления браузером, но manifest не показывает, какие именно домены CDP или методы вызывает код. Каждая строка подсказывает, что проверять дальше: сетевой трафик во время работы, исходный код, поток согласия или трассы browser API.

То же разделение важно, когда вы читаете установочный prompt Chrome. Один только счётчик разрешений не показывает время срабатывания, охват фреймов, OAuth scope, web_accessible_resources или отсутствие ключа externally_connectable. С другой стороны, широкая декларация не является доказательством сбора или эксфильтрации. Полезный результат аудита manifest — это приоритизированный план runtime-проверки: определить поверхность данных, отметить пользовательский барьер, а затем проверить, используется ли заявленный путь на самом деле.

Как читать своё собственное

Связанный разбор: browser automation guide.

1. chrome://extensions → Details показывает выданный доступ к сайтам и позволяет переключить его в режим on click для всего, что не требует постоянного доступа. Это сужает именно половину, связанную с доступом к сайтам. Это не затрагивает входящие сообщения (externally_connectable по-прежнему действует для service worker) и не меняет browser-level permissions.
   Thunderbit's debugger declaration matters here. В документации Chromium по безопасности расширений говорится, что debugger API «в некоторых случаях может также обходить другие обычные ограничения, такие как host permissions или file access», поэтому установка доступа к сайтам в режим "on click" не ограничивает то, куда он способен дотянуться. И этот контроль не влияет на tabs, webNavigation, clipboardRead, downloads или что-либо в optional_permissions.
2. Для самого файла пакет лежит в каталоге Chrome Extensions/<id>/<version>/. Проверьте шесть полей: permissions, optional_permissions, host_permissions, content_scripts (внутри них matches, run_at и all_frames), externally_connectable — помня, что отсутствующий ключ разрешителен для других расширений — и web_accessible_resources, чьи matches могут называть схемы, которых нет у content scripts. В последнем поле Thunderbit есть две записи <all_urls>, раскрывающие index.html и два bundled script для любого origin, с use_dynamic_url: false, что позволяет странице проверить, разрешаются ли эти стабильные URL расширения.
3. Сверьте дату последнего обновления в листинге с текущей версией Chrome.

Раскрытие и ресурсы: эта статья опубликована Thunderbit, чьё расширение включено в ту же таблицу и проходит тот же парсер. Наш open-source scraper pillar покрывает инструменты без расширений.

Попробовать Thunderbit для извлечения веб-данных

Короткая версия

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

Agenty не заявляет доступа к сайтам и не использует content scripts, работая только на той вкладке, которую вы открыли и кликнули, при размере 2.2 MiB. Axiom.ai заявляет доступ к любому HTTP- и HTTPS-URL при размере 37.1 MiB. Magical заявляет тринадцать разрешений, включая clipboardRead — и одновременно это единственное расширение здесь, которое полностью закрывает входящие сообщения. Table Capture заявляет всего четыре разрешения, но внедряется на document_start во все фреймы на <all_urls> — то есть достигает того же потолка совпадения, что и наше, только раньше — плюс получает userScripts по запросу. TexAu — самый маленький, и он называет больше всего целей: четырнадцать шаблонов по тринадцати разным свойствам. Он не единственный, кто их называет: Clip to Clay указывает два (clay.com и один сторонний сайт), а Hexomatic и Clay for Chrome указывают собственные домены. TexAu — единственный, чей список целей в основном состоит из чужих сайтов. Пять из десяти могут добираться до файлов на вашем диске, и два из них — Axiom.ai и наше расширение — делают это, даже не упоминая file://.

Thunderbit, наше расширение, находится на широком конце шкалы: <all_urls> и для доступа к хостам, и для статического внедрения, плюс debugger, которого нет ни у одного другого расширения в этой выборке. Оно остаётся в режиме Chrome по умолчанию, разрешающем сообщения от любого расширения, и получает доступ к file:// после включения пользовательского файлового барьера Chrome.

Декларация — это потолок, а не поведение, и всё это не доказывает злоупотребление. Но это опубликовано, это можно бесплатно проверить, и разрыв между двумя концами шкалы больше, чем всё, что обычно пишут на страницах продуктов.

Попробовать Thunderbit для извлечения веб-данных Get Started Free

FAQ

Означает ли широкое разрешение, что расширение делает что-то плохое, и почему одного подсчёта разрешений недостаточно? Нет, и потому что счётчик упускает две вещи. <all_urls> означает, что расширение может читать любую открытую вами страницу; это ничего не говорит о том, что оно делает и уходит ли что-то с вашего компьютера. А инструмент, который должен извлекать данные с любой страницы, действительно не может работать по списку именованных доменов. Здесь важен разброс, а не нарушение правил — для доказательства реального поведения нужен анализ трафика во время работы, а этот аудит его не выполнял. Что касается счёта: настройки внедрения не являются разрешениями, поэтому Table Capture заявляет только четыре, хотя внедряется на document_start, во все all_frames, совпадая с <all_urls>. И optional_permissions вообще не показываются в установочном prompt — Table Capture может запросить userScripts во время работы, что позволяет запускать произвольные пользовательские скрипты в контексте страницы, а Magical может запросить webRequest.

Что из этой подборки просит меньше всего? Agenty: четыре разрешения, без host permissions, без content scripts. Он опирается на activeTab, который даёт доступ только к текущей вкладке, только после клика по расширению и только до перехода на другую страницу. Следом идёт Hexomatic — два разрешения и content scripts, ограниченные его собственными доменами.

Как расширение может добраться до моих локальных файлов, не указывая file://? Потому что <all_urls> включает схему file:. Listly, Magical и Table Capture явно указывают шаблоны file:// — Magical в content scripts, а Table Capture в web_accessible_resources. Axiom.ai и Thunderbit достигают этого через wildcard, нигде не упоминая схему. http://*/* и https://*/* не покрывают file://. Chrome держит доступ к файлам выключенным по умолчанию через отдельный переключатель для каждого расширения, так что декларация — это запрос, а не предоставление права.

Что такое externally_connectable, и почему его отсутствие — это разрешающий вариант? Он определяет, какие web origins или extension IDs могут отправлять сообщения в background script расширения. По умолчанию, когда ключ отсутствует, подключаться может любое расширение, но не может подключиться ни одна веб-страница. Семь из этих десяти не указывают его, включая Thunderbit. Если ключ присутствует, Hexomatic открывает канал для расширений на восемь указанных IDs; Axiom.ai открывает семь web origins, оставляя канал для расширений закрытым; Magical задаёт пустые списки для обоих каналов и закрывает оба.

Что именно заявляет собственный manifest Thunderbit? <all_urls> для доступа к хостам и статического внедрения content script, во всех all_frames на document_end; 15.9 MiB и 78 файлов; а также девять строк в массиве permissions. Восемь из них распознаются как permissions: activeTab, debugger, offscreen, scripting, sidePanel, storage, tabGroups и tabs. commands — это ключ верхнего уровня manifest и не имеет эффекта внутри этого массива. Ни одно другое расширение в этой выборке не заявляет debugger. Thunderbit также добирается до file:// через <all_urls> после включения файлового барьера Chrome и опускает externally_connectable. Поведение во время работы не исполнялось, поэтому аудит не утверждает, какие именно методы CDP или scripting реально вызывает расширение.