Accès aux sites nul ou tous les URL : l’éventail des autorisations sur dix extensions de scraping

Chaque extension Chrome embarque un manifest.json qui définit une grande partie de son niveau d’autorisation au sein du navigateur : API demandées, modèles d’hôtes, scripts de contenu statiques, permissions facultatives et connexions externes autorisées. C’est un fichier public, inclus dans le paquet que vous installes. En revanche, il ne prouve pas quelles capacités déclarées sont réellement utilisées par le code, quelles données quittent la machine, ni quels accès à des comptes passent par une connexion web séparée.

J’ai examiné les dix extensions de scraping et d’automatisation de navigateur retenues pour cet audit, y compris celle de Thunderbit, qui est la nôtre. L’écart est important. L’une ne déclare aucun accès permanent à des sites. Une autre annonce treize permissions, dont clipboardRead. Thunderbit est la seule extension de cet ensemble à déclarer debugger, une capacité d’attachement CDP large, avec un profil de risque différent de l’accès aux pages, de l’OAuth ou des scripts fournis par l’utilisateur.

Rien de tout cela n’est une accusation. Une permission large est souvent la seule manière honnête de construire une fonctionnalité donnée, et une permission étroite peut simplement signifier que le produit fait moins de choses. L’essentiel, c’est que l’écart est énorme, qu’il est public, et qu’il n’apparaît jamais dans un tableau comparatif.

Méthodologie

Chaque extension a été téléchargée au format .crx depuis le point de mise à jour de Google — la même URL que Chrome utilise lui-même — puis décompressée et analysée. Aucune extension n’a été installée et aucun code d’extension n’a été exécuté. Il s’agit d’une lecture de fichier JSON.

Les téléchargements ont été espacés à raison d’environ une requête toutes les deux secondes. Chaque .crx, son SHA-256 et le manifest.json extrait sont conservés comme éléments de preuve. Thunderbit est passé par le même script que les neuf autres, sans circuit spécial ; sa ligne est donc dérivée exactement de la même manière.

L’analyse s’appuie sur deux catégories de preuves, maintenues séparées :

• Comportement statique déclaré : modèles d’hôtes et entrées content_scripts, y compris matches, run_at et all_frames.
• Capacité disponible pour le code à l’exécution : API nommées dans permissions ou optional_permissions. Ces déclarations montrent ce que le code pourrait demander ou invoquer, pas ce qu’il fait effectivement.

Aucun score ordinal de type « le plus puissant » n’est attribué. debugger, userScripts, l’accès large aux hôtes, les scopes OAuth, l’accès au presse-papiers et la messagerie externe exposent des données différentes et exigent des conditions préalables différentes. Les comparer exige un modèle de menace que cet audit limité au manifest ne fournit pas.

Les tailles ci-dessous correspondent aux totaux décompressés en MiB (2²⁰ octets), additionnés à partir des entrées ZIP.

État au 2026-07-29. Les extensions évoluent ; vérifiez à nouveau avant de citer.

Ce que déclarent dix manifests

Référence officielle : Guide Chrome sur la déclaration des permissions.

Deux autres figuraient sur la liste de candidats et n’apparaissent pas dans le tableau, pour des raisons qui méritent d’être traitées à part.

L’écart relève du choix de conception, pas d’un effet de taille

Agenty ne déclare aucune permission d’hôte et n’embarque aucun script de contenu. Ses quatre permissions sont activeTab, scripting, identity et identity.email. activeTab est la permission la plus restrictive : elle donne accès à l’onglet courant uniquement après avoir cliqué sur l’extension, et seulement jusqu’à ce que vous changiez de page. Rien ne s’exécute sur vos pages tant que vous ne l’activez pas. Pour 2.2 MiB.

Axiom.ai déclare http://*/* et https://*/*, injecte des scripts de contenu correspondant à <all_urls> et occupe 37.1 MiB répartis en 232 fichiers — soit dix-sept fois la taille d’Agenty, avec un accès permanent à chaque page que vous visitez.

Hexomatic se situe dans la même veine qu’Agenty : deux permissions (storage, tabs), aucune permission d’hôte, et des scripts de contenu limités à ses deux propres domaines.

Clay for Chrome présente une troisième configuration à distinguer : il déclare *://*/* comme permission d’hôte, mais n’injecte des scripts de contenu que sur son propre domaine. La capacité permanente est large ; le comportement automatique est étroit. Un tableau de permissions seul mélange les deux.

Cinq des dix peuvent atteindre les fichiers présents sur votre disque

file:/// n’est pas un site web. C’est votre système de fichiers local affiché dans un onglet de navigateur — un PDF ouvert, une exportation HTML, une facture téléchargée.

Référence officielle : Documentation Chrome sur les modèles de correspondance.

Trois extensions le déclarent explicitement. Deux y accèdent sans le nommer : <all_urls> inclut le schéma file:.

http://*/* et https://*/* ne couvrent pas file:// ; <all_urls> et *://*/* diffèrent aussi sur ce point. Les cinq ici sont ceux dont les déclarations atteignent ce schéma par l’une ou l’autre route — pas parce qu’ils ont choisi telle forme de joker plutôt qu’une autre.

Chrome protège tout cela derrière un interrupteur « Autoriser l’accès aux URL de fichiers » propre à chaque extension, désactivé par défaut. La déclaration est donc une demande, pas une autorisation. Cinq sur dix est le comptage honnête, et deux de ces cinq n’écrivent jamais file:// nulle part dans leur manifest : Axiom.ai et le nôtre.

Ce décompte inclut web_accessible_resources, pas seulement les scripts de contenu et les permissions d’hôte. Table Capture y mentionne file://*/* ; omettre ce bloc l’aurait placé à tort parmi les extensions dont les manifests atteignent les fichiers sans nommer le schéma.

Des permissions que vous ne voyez qu’au moment où elles sont demandées

Les optional_permissions sont déclarées à l’avance mais demandées à l’exécution ; elles n’apparaissent donc pas dans la fenêtre de permission à l’installation. Deux extensions les utilisent, et l’une d’elles est importante.

userScripts n’apparaît qu’après demande, et reste invisible pour quiconque se contente de compter les permissions.

Elle a aussi une porte d’entrée que les autres permissions examinées ici n’ont pas, et l’omettre la surestimerait. Déclarer userScripts ne suffit pas à l’utiliser : Chrome exige d’abord une action explicite de l’utilisateur. Avant Chrome 138, cela passait par le Developer Mode, activé globalement dans chrome://extensions. À partir de Chrome 138, c’est un interrupteur Allow User Scripts propre à l’extension, sur sa page de détails, désactivé par défaut. Donc, pour une installation ordinaire, la capacité est déclarée mais inerte. L’affirmation exacte est conditionnelle : Table Capture peut rendre l’API userScripts disponible après activation de la porte d’entrée Chrome par l’utilisateur. Cet audit n’a pas mesuré à quelle fréquence les utilisateurs ouvrent cette page de réglages ni activent l’option.

Rien n’est caché ; les deux éléments figurent dans le manifest. Un tableau qui ignore le bloc facultatif sous-estime deux produits.

Le moment d’injection, pas seulement le périmètre

La façon dont un script de contenu est injecté compte, et change la lecture. document_start est le premier point d’accroche proposé par Chrome ; all_frames atteint aussi les intégrations tierces.

Tout ce qui, dans cet ensemble, injecte statiquement dans toutes les frames, classé par timing déclaré :

Table Capture et Listly utilisent le point d’accroche le plus précoce avec des modèles de correspondance larges. Axiom.ai et Clay for Chrome utilisent le même timing mais seulement sur leurs propres domaines — même agressivité, cible étroite.

Pour les déclarations statiques, <all_urls> avec all_frames représente le plafond de largeur de correspondance, et Table Capture comme Thunderbit s’y retrouvent. Leur timing déclaré diffère : Table Capture utilise document_start ; le script de contenu statique de Thunderbit est à document_end. Les API d’exécution constituent une autre catégorie de capacité et ne peuvent pas être déduites de ce tableau.

Le nombre de permissions est un mauvais indicateur synthétique. Table Capture ne déclare que quatre permissions — moins que la plupart ici — tout en injectant à document_start dans toutes les frames sur <all_urls>, avec en plus userScripts sur demande.

Qui peut envoyer des messages à l’extension

externally_connectable contrôle quels sites web ou quelles autres extensions peuvent envoyer des messages directement au script d’arrière-plan d’une extension. Son comportement par défaut est contre-intuitif.

L’absence de la clé est la configuration la plus permissive. Par défaut, lorsque externally_connectable est absent, n’importe quelle extension peut se connecter, mais aucun site web ne le peut. La déclarer sert à restreindre.

En lisant la règle ainsi, le tableau s’inverse :

La règle de Chrome comporte deux niveaux. D’après la référence du manifest :

Le défaut permissif s’applique à l’absence de la clé entière. Une fois la clé présente, les deux sous-champs commencent fermés, et le fait de leur donner des valeurs élargit chaque canal.

Axiom.ai déclare la clé avec seulement matches. Son ids est donc absent, ce qui signifie que aucune extension ne peut lui envoyer de messages — le canal extension est fermé, pas laissé ouvert. Ce qu’il a ouvert, en revanche, ce sont sept origines web, dont une seule appartient à Axiom : deux sont des tiers non attribuables (*://*.tgwc.space/*, *://*.bitmachine.co.uk/*) et le reste correspond à localhost, 0.0.0.0, un hôte Google APIs et une grande plateforme sociale qu’il n’exploite pas.

Hexomatic ouvre son canal extension à huit IDs nommés. La clé étant présente, la base est zéro extension ; le fait d’en nommer huit ouvre le canal à huit. Ses six matches élargissent l’autre canal à partir de zéro, et deux d’entre eux sont http://localhost:8000/* et http://localhost:3000/* en HTTP simple — tout service répondant sur ces ports sur la machine de l’utilisateur entre dans la liste d’autorisation.

Sept des dix omettent complètement la clé, y compris la nôtre, et ce sont donc elles qui restent dans la configuration permissive pour la messagerie d’extension à extension. Deux extensions ferment ce canal : Magical explicitement avec ids: [], et Axiom.ai en déclarant la clé sans jamais mentionner ids. Magical est la seule à fermer les deux.

Cette dernière ligne explique pourquoi il faut lire les manifests plutôt que simplement compter les permissions. Une même extension peut être large sur un axe et la plus stricte du lot sur un autre.

L’axe que personne ne compte : les scopes OAuth

Un manifest peut contenir un bloc oauth2, et les scopes qu’il renferme donnent accès à vos comptes chez d’autres entreprises — une forme de portée différente de tout ce qui précède, et qu’aucun comptage de permissions ne reflète.

Référence officielle : Liste des scopes Google OAuth 2.0.

https://www.googleapis.com/auth/drive est le scope large. Google propose un scope plus étroit, drive.file, qui n’autorise l’accès qu’aux fichiers créés par l’application elle-même ou explicitement choisis par l’utilisateur ; auth/drive permet de voir, modifier, créer et supprimer dans l’ensemble du Drive de l’utilisateur. auth/spreadsheets suit la même logique pour toutes les feuilles de calcul accessibles au compte. Axiom.ai et Table Capture associent toutes deux un scope Google à un accès page <all_urls>.

Deux limites à ce que prouve ce tableau. Un scope est demandé, pas accordé — Google affiche un écran de consentement et l’utilisateur peut refuser, et l’extension peut ne jamais appeler l’API. Et le manifest ne voit que l’OAuth passé par le flux identity de Chrome ; une extension qui vous redirige vers une page de connexion web ne déclarerait rien ici. Les sept zéros signifient « non demandé dans ce fichier », pas « aucun accès à votre compte Google » — y compris pour la nôtre, ce qui explique pourquoi cet axe est rapporté plutôt que présenté comme une preuve de sobriété.

Notre propre extension, sur la même échelle

Thunderbit 4.6.4 est passé par le même analyseur de manifest que les neuf autres. Le paquet pèse 15.9 MiB une fois décompressé, répartis sur 78 fichiers.

Comportement statique déclaré : <all_urls> apparaît dans les permissions d’hôte et dans les correspondances des scripts de contenu. Le script statique s’exécute sur toutes les frames à document_end. Comme <all_urls> inclut file:, le manifest peut atteindre les fichiers locaux une fois que l’utilisateur a activé l’interrupteur d’accès aux fichiers de Chrome. Thunderbit omet aussi externally_connectable, donc le comportement par défaut de Chrome autorise les messages de n’importe quelle extension mais d’aucun site web.

Plafond de capacité à l’exécution : le tableau permissions contient neuf chaînes : activeTab, commands, debugger, offscreen, scripting, sidePanel, storage, tabGroups et tabs. Chrome en reconnaît huit comme permissions ; commands est une clé de manifest de premier niveau et n’a aucun effet en tant qu’entrée dans ce tableau. Thunderbit est la seule extension de l’ensemble à déclarer debugger, qui peut attacher CDP à un onglet. Le manifest rend aussi scripting disponible pour l’enregistrement à l’exécution. Ces API créent des capacités au-delà de la ligne statique document_end, mais une lecture du manifest ne permet pas d’établir que Thunderbit invoque une méthode CDP particulière ou enregistre un script plus tôt à un moment donné.

Cette distinction bloque plusieurs comparaisons tentantes mais invalides. L’absence d’une permission cookies plus étroite ne borne pas ce qu’un code disposant de debugger pourrait accéder. L’absence de clipboardRead ne prouve pas qu’un accès au presse-papiers est impossible. À l’inverse, la présence de debugger ne prouve pas que ces voies sont utilisées. Répondre à l’une de ces questions demanderait une inspection du code source ou un traçage à l’exécution, aucun des deux n’ayant été effectué.

Sur cet instrument, Thunderbit est large pour l’accès statique aux sites, unique dans cet ensemble à déclarer debugger, et placé sur la configuration par défaut de Chrome pour la messagerie extension-à-extension. Il n’existe pas de classement unique du « plus fort », parce que l’audit ne fournit pas de modèle de menace commun entre CDP, OAuth, userScripts, le presse-papiers et l’accès aux hôtes.

La conception sobre que personne ne met en avant

TexAu ne pèse que 0.3 MiB — le plus léger ici d’un facteur deux — et il nomme quatorze sites précis au lieu d’utiliser un joker : réseaux sociaux, plateforme pour développeurs, plateformes de publication, produit de messagerie, fournisseur de données B2B et son propre domaine. Ses scripts de contenu correspondent exactement à ces quatorze cibles.

On peut lire ce manifest et savoir précisément où l’extension est active. C’est aussi une forme de déclaration produit : la liste de cibles dit plus clairement ce que l’outil est censé faire que le marketing lui-même.

Le compromis est réel : une liste nommée ne peut pas scraper un site qui n’y figure pas, et chaque nouvelle cible exige une version. Mais « quatorze domaines nommés » et « chaque URL existante » sont deux propositions très différentes, et une seule des deux est lisible.

Deux produits qui n’étaient pas ce que la liste disait

L’extension de Captain Data n’est pas distribuée publiquement. Le point de mise à jour de Google renvoie HTTP 204 avec un corps vide pour son identifiant d’extension — la réponse typique d’un élément que le store ne sert pas de manière anonyme. Sa page de fiche, en revanche, a été servie anonymement — HTTP 200, 509 829 octets. Ce que la capture n’a pas pu y trouver, c’est une chaîne de version, une date de dernière mise à jour ou un nombre d’installations ; les notes du script précisent qu’un null à cet endroit n’est qu’un indice faible, et aucune barrière de connexion n’a été observée. L’identifiant est réel et de première partie, donc une distribution par lien ou non listée est l’hypothèse la plus probable, mais je n’ai pas pu distinguer cela d’une suppression du catalogue et je n’émettrai pas de supposition.

Dataflow Kit n’a pas d’extension Chrome du tout. Son site décrit une application web hébergée, avec sélection au clic et API REST. Elle avait pourtant été inscrite sur une shortlist d’extensions Chrome — ce qui est souvent ainsi que ces listes sont constituées.

Fraîcheur et portée, puisqu’il est gratuit de les vérifier

Les métadonnées du store ajoutent un contexte de sélection produit au-delà des permissions. Les mêmes champs ont été relevés pour chaque extension le 2026-07-30.

Trois produits n’ont pas publié depuis plus d’un an, et Hexomatic depuis près de deux. Pour les extensions, cela compte davantage que pour des bibliothèques : Chrome publie une version stable environ toutes les quatre semaines, et la plate-forme d’extensions change sans cesse sous leurs pieds. userScripts a déplacé sa porte d’entrée dans Chrome 138 ; une extension publiée pour la dernière fois en 2024 a été construite selon un ensemble de règles différent de celles que le navigateur applique aujourd’hui.

Deux précisions sur ce tableau. Les comptages d’installations sont regroupés par Google — 1 000 / 3 000 / 7 000 / 10 000 / 100 000 / 200 000 — ils comparent donc des ordres de grandeur, et rien de plus précis ; plusieurs produits annoncent des chiffres plus élevés dans leur propre marketing. Une date récente est un fait de publication, pas un verdict sur la qualité de maintenance ni sur le risque lié aux permissions.

Un effet secondaire utile : la version du store correspond à la version du manifest dans chacun des dix paquets analysés. Les fichiers CRX que cet audit a décompressés sont bien ceux que le store distribue aujourd’hui, et non des copies obsolètes.

La fraîcheur change l’ampleur des vérifications complémentaires qu’une sélection mérite ; elle ne change pas la sémantique du manifest. Une extension à domaine nommé mise à jour il y a un an peut encore exposer moins de surface de page qu’une extension au joker publiée hier. Le paquet plus récent peut malgré tout être le meilleur choix opérationnel s’il suit rapidement les évolutions de Chrome. Pour une shortlist, utilisez la date du store pour décider quoi retester, puis le manifest pour déterminer ce qui mérite une revue de capacités plus approfondie. Ne transformez pas ces deux colonnes en un score unique.

Ce qu’un manifest ne dit pas

Une permission déclarée est un plafond, pas un comportement. <all_urls> signifie qu’une extension peut lire chaque page. Cela ne veut pas dire qu’elle le fait, ni qu’une quelconque donnée quitte votre machine. Établir ce qui se passe réellement exige d’observer le trafic réseau à l’exécution — un travail différent, non réalisé ici, et rien de ce qui précède ne doit être interprété comme la preuve d’un abus.

Lecture associée : expérience de testabilité des extensions Chrome.

Trois limites supplémentaires :

• Chrome encadre fortement ces capacités. L’accès aux fichiers est désactivé par défaut ; activeTab est volontairement étroit ; les permissions facultatives nécessitent une invite à l’exécution ; les utilisateurs voient la liste des permissions à l’installation.
• Les permissions larges sont souvent nécessaires. Un outil dont la fonction est « extraire un tableau de n’importe quelle page ouverte » ne peut pas fonctionner depuis une liste blanche de domaines nommés. Un périmètre étroit est parfois une discipline, parfois simplement le signe d’un produit plus limité.
• Une version, un jour. Tous les chiffres proviennent du paquet servi le 2026-07-29.

Corrections matérielles apportées à l’analyse

Les comptages publiés utilisent trois règles faciles à rater lorsqu’on écrit un parseur de manifest rapide. Premièrement, <all_urls> inclut le schéma file:, mais Chrome maintient l’accès effectif aux fichiers derrière un interrupteur contrôlé par l’utilisateur. Deuxièmement, web_accessible_resources.matches doit être examiné en même temps que les scripts de contenu et les permissions d’hôte ; c’est là que Table Capture nomme explicitement file://*/*. Troisièmement, externally_connectable a des valeurs par défaut différentes selon que la clé entière est absente ou présente avec un sous-champ vide. Les tableaux ci-dessus appliquent ces règles de façon cohérente.

Le total de permissions de Thunderbit distingue aussi les chaînes brutes des permissions Chrome reconnues. Son tableau contient neuf entrées, mais commands appartient au niveau supérieur ; le comptage effectif utilisé ici est donc de huit permissions reconnues plus une chaîne non reconnue. Enfin, les déclarations statiques content_scripts ne prouvent pas que le code appelle scripting.registerContentScripts ou une méthode CDP. Ces possibilités n’apparaissent qu’au titre des capacités d’exécution, jamais comme comportements observés. Les manifests bruts, les hash CRX et la sortie du parseur constituent la trace d’audit de ces normalisations, afin que les lecteurs n’aient pas à croire le texte sur parole.

Pour une vraie décision d’installation, comparez au moins quatre dimensions séparément : quelles pages sont dans le périmètre par défaut, quelle action explicite de l’utilisateur débloque davantage, quelles API du navigateur ou du compte deviennent disponibles, et quels acteurs externes peuvent envoyer des messages à l’extension. Le modèle activeTab d’Agenty, les userScripts soumis à porte d’entrée de Table Capture, le scope Drive d’Axiom.ai et la déclaration debugger de Thunderbit ne sont pas des points sur une même échelle linéaire. Ce sont des réponses différentes à des questions de menace différentes.

Voici cette comparaison appliquée à quatre conceptions volontairement différentes :

Ce tableau ne désigne toujours aucun gagnant. L’accès de page permanent et étroit d’Agenty ne dit rien de ce que son backend fait des données soumises. Les scopes de compte d’Axiom.ai ne sont pas comparables à la lecture de la page courante par une extension. La déclaration userScripts de Table Capture est inerte tant que l’utilisateur n’active pas sa porte d’entrée séparée. La permission debugger de Thunderbit expose une large surface de contrôle du navigateur, mais le manifest ne révèle pas quels domaines CDP ni quelles méthodes son code appelle. Chaque ligne vous indique quoi inspecter ensuite : trafic réseau à l’exécution, code source, flux de consentement ou traces d’API navigateur.

La même séparation compte lorsqu’on lit l’invite d’installation de Chrome. Un simple total de permissions ne peut pas montrer le timing, la portée dans les frames, le scope OAuth, web_accessible_resources, ni une clé externally_connectable omise. À l’inverse, une déclaration large ne prouve ni collecte ni exfiltration. Le résultat utile d’un audit de manifest est un plan de test runtime priorisé : identifiez la surface de données, notez la porte d’entrée utilisateur, puis observez si le chemin déclaré est effectivement emprunté.

Comment lire le vôtre

Lecture associée : guide de l’automatisation navigateur.

1. chrome://extensions → Détails affiche les accès aux sites accordés, et permet de les passer à au clic pour tout ce qui n’a pas besoin d’un accès permanent. Cela réduit la moitié « accès aux sites » de ce qui précède. Cela ne touche ni la messagerie entrante (externally_connectable atteint le service worker quoi qu’il arrive), ni les permissions au niveau du navigateur. La déclaration debugger de Thunderbit est importante ici. La documentation sécurité des extensions de Chromium indique que l’API debugger « peut, dans certains cas, contourner d’autres restrictions typiques, comme les permissions d’hôte ou l’accès aux fichiers », donc le fait de régler l’accès aux sites sur « au clic » ne borne pas ce qu’elle peut atteindre. Ce contrôle ne s’applique pas non plus à tabs, webNavigation, clipboardRead, downloads ni à ce qui se trouve dans optional_permissions.
2. Pour le fichier brut, le paquet se trouve dans le répertoire Chrome Extensions/<id>/<version>/. Lisez six champs : permissions, optional_permissions, host_permissions, content_scripts (les matches, run_at et all_frames qu’ils contiennent), externally_connectable — en gardant à l’esprit qu’une clé absente est permissive pour les appelants d’extension — et web_accessible_resources, dont les matches peuvent nommer des schémas que les scripts de contenu ne nomment jamais. Le dernier champ de Thunderbit contient deux entrées <all_urls> exposant index.html et deux scripts intégrés à toutes les origines, avec use_dynamic_url: false, ce qui permet à une page de vérifier si ces URL d’extension stables résolvent.
3. Vérifiez la date de dernière mise à jour de la fiche par rapport à la version actuelle de Chrome.

Divulgation et ressources : cet article est publié par Thunderbit, dont l’extension figure dans le même tableau et le même parseur. Notre pilière open source sur les scrapers couvre les outils non fondés sur des extensions.

Essayez Thunderbit pour l’extraction de données web

Version courte

Dix extensions de scraping et d’automatisation, la nôtre incluse, ont été lues à partir de leurs propres manifests.

Agenty ne déclare ni accès aux sites ni scripts de contenu, et ne fonctionne que sur l’onglet que vous regardez au moment du clic, pour 2.2 MiB. Axiom.ai déclare chaque URL HTTP et HTTPS sur 37.1 MiB. Magical déclare treize permissions, dont clipboardRead — et c’est aussi la seule extension ici à fermer complètement la messagerie entrante. Table Capture ne déclare que quatre permissions, et injecte à document_start dans toutes les frames sur <all_urls> — soit le même plafond de correspondance que le nôtre atteint, mais plus tôt — avec userScripts sur demande. TexAu est la plus petite, et celle qui nomme le plus de cibles — quatorze modèles répartis sur treize propriétés distinctes. Ce n’est pas la seule à les nommer : Clip to Clay en déclare deux (clay.com et un site tiers), et Hexomatic comme Clay for Chrome nomment leurs propres domaines. TexAu est la seule dont la liste nommée est en majorité constituée de sites d’autrui. Cinq des dix peuvent atteindre les fichiers sur votre disque, dont deux — Axiom.ai et la nôtre — sans jamais écrire file://.

Thunderbit, la nôtre, se situe du côté large : <all_urls> à la fois pour l’accès aux hôtes et pour l’injection statique, plus debugger, qu’aucune autre extension de cet ensemble ne déclare. Elle se place sur la configuration par défaut de Chrome qui autorise les messages de n’importe quelle extension, et elle atteint file:// une fois la porte d’accès aux fichiers de Chrome activée.

Une déclaration est un plafond, pas un comportement, et rien ici ne prouve un abus. Mais c’est publié, gratuit à vérifier, et l’écart entre les deux extrêmes est bien plus grand que tout ce qu’on voit sur les pages produit.

Essayez Thunderbit pour l’extraction de données web Get Started Free

FAQ

Une permission large veut-elle dire que l’extension fait quelque chose de mauvais — et pourquoi le simple comptage de permissions ne suffit-il pas ? Non, et parce qu’un simple comptage rate deux choses. <all_urls> signifie qu’une extension peut lire chaque page que vous visitez ; cela ne dit rien sur ce qu’elle fait ni sur le fait que quelque chose quitte ou non votre machine. Par ailleurs, un outil conçu pour extraire des données de n’importe quelle page ne peut pas fonctionner avec une simple liste de domaines nommés. Le résultat, c’est l’écart observé, pas une faute ; établir le comportement réel exige une analyse du trafic à l’exécution, que cet audit n’a pas réalisée. Quant au comptage : les réglages d’injection ne sont pas des permissions, donc Table Capture en déclare quatre tout en injectant à document_start, dans all_frames, en correspondant à <all_urls>. Et les optional_permissions n’apparaissent même pas dans la fenêtre d’installation — Table Capture peut demander userScripts à l’exécution, ce qui permet d’exécuter des scripts arbitraires fournis par l’utilisateur dans le contexte des pages, et Magical peut demander webRequest.

Laquelle demande le moins ? Agenty : quatre permissions, aucune permission d’hôte, aucun script de contenu. Il repose sur activeTab, qui donne accès à l’onglet courant seulement après avoir cliqué sur l’extension, et seulement jusqu’à navigation vers une autre page. Hexomatic vient ensuite, avec deux permissions et des scripts de contenu limités à ses propres domaines.

Comment une extension peut-elle atteindre mes fichiers locaux sans déclarer file:// ? Parce que <all_urls> inclut le schéma file:. Listly, Magical et Table Capture nomment explicitement des motifs file:// — Magical dans ses scripts de contenu et Table Capture dans web_accessible_resources. Axiom.ai et Thunderbit y accèdent via le joker sans le mentionner nulle part. http://*/* et https://*/* ne couvrent pas file://. Chrome maintient l’accès aux fichiers désactivé par défaut via un interrupteur propre à chaque extension, donc la déclaration est une demande, pas une autorisation.

Qu’est-ce que externally_connectable, et pourquoi son omission est-elle l’option permissive ? Il nomme les origines web ou les IDs d’extensions autorisés à envoyer des messages au script d’arrière-plan d’une extension. Par défaut, quand la clé est absente, n’importe quelle extension peut se connecter et aucune page web ne le peut. Sept de ces dix l’omettent, Thunderbit compris. Avec la clé présente, Hexomatic ouvre le canal extension à huit IDs nommés ; Axiom.ai ouvre sept origines web en laissant le canal extension fermé ; Magical déclare des listes vides pour les deux, fermant les deux canaux.

Que déclare le manifest de Thunderbit ? <all_urls> pour l’accès aux hôtes et l’injection statique de scripts de contenu, dans all_frames à document_end ; 15.9 MiB sur 78 fichiers ; et neuf chaînes dans le tableau de permissions. Huit sont des permissions reconnues : activeTab, debugger, offscreen, scripting, sidePanel, storage, tabGroups et tabs. commands est une clé de manifest de premier niveau et n’a aucun effet dans ce tableau. Aucune autre extension de cet ensemble ne déclare debugger. Thunderbit atteint aussi file:// via <all_urls> une fois la porte d’accès aux fichiers de Chrome activée, et omet externally_connectable. Le comportement à l’exécution n’ayant pas été exécuté, l’audit ne prétend pas savoir quelles méthodes CDP ou de scripting l’extension appelle réellement.