Varje Chrome-tillägg levereras med en manifest.json som på ett avgörande sätt sätter ramarna för vad tillägget kan göra i webbläsaren: begärda API:er, host patterns, statiska content scripts, valfria behörigheter och tillåtna externa anslutningar. Filen ligger öppet i paketet du installerar. Men den visar däremot inte vilka av de deklarerade möjligheterna som faktiskt används i körning, vad som lämnar din dator eller vilken kontotillgång som sker via en separat inloggning på webben.
Jag granskade de tio scraping- och webbläsarautomations-tillägg som valdes ut för den här genomgången, inklusive Thunderbit:s, eftersom det är vårt. Skillnaderna är stora. Ett deklarerar ingen permanent webbåtkomst alls. Ett annat deklarerar tretton behörigheter, inklusive clipboardRead. Thunderbit är det enda tillägget i den här gruppen som deklarerar debugger, en bred CDP-förmåga med en annan riskprofil än sidåtkomst, OAuth eller användarskript.
Inget av detta är en anklagelse. En bred behörighet är ofta det enda ärliga sättet att bygga en viss funktion, och en snäv behörighet kan helt enkelt betyda att produkten gör mindre. Poängen är att skillnaderna är enorma, att de är publicerade och att de aldrig syns i en jämförelsetabell.
Så här gjordes granskningen
Varje tillägg laddades ner som en .crx från Googles egna uppdateringsändpunkt — samma URL som Chrome själv använder — och packades sedan upp och analyserades. Inget tillägg installerades och ingen tilläggskod kördes. Detta är en läsning av en JSON-fil.
Nedladdningarna gicks igenom i ungefär en begäran varannan sekund. Varje .crx, dess SHA-256 och den extraherade manifest.json sparades som underlag. Thunderbit gick igenom exakt samma skript som de nio andra, inte via någon sidokanal, så dess rad är härledd på samma sätt som de andras.
Analysen använder två beviskategorier och håller dem isär:
- Deklarerat statiskt beteende: host patterns och poster i
content_scripts, inklusivematches,run_atochall_frames. - Kapacitet som finns tillgänglig för körkod: API:er som namnges i
permissionselleroptional_permissions. Dessa deklarationer visar vad kod kan begära eller anropa, inte att den faktiskt gör det.
Ingen ordinal "mest kraftfull"-poäng ges. debugger, userScripts, bred host access, OAuth-scope, clipboard-åtkomst och extern meddelandekommunikation innebär olika typer av data och kräver olika förutsättningar. För att jämföra dem behövs en hotmodell som denna manifestbaserade granskning inte tillhandahåller.
Storlekarna nedan avser uppackade totaler i MiB (2²⁰ byte), summerade från ZIP-posterna.
Gäller per 2026-07-29. Tillägg uppdateras; kontrollera på nytt innan du citerar.
Vad tio manifest deklarerar

Officiell referens: Chrome's permission declaration guide.
| Tillägg | Version | Uppackat | Filer | Behörigheter | Webbtillgång | Kan nå file:// |
|---|---|---|---|---|---|---|
| Axiom.ai | 5.1.0 | 37.1 MiB | 232 | 8 | http://*/* + https://*/* | ✅ |
| Table Capture | 11.0.41 | 21.1 MiB | 115 | 4 (+3 valfria) | <all_urls> | ✅ |
| Magical | 3.119.1 | 16.8 MiB | 395 | 13 (+2 valfria) | <all_urls> | ✅ |
| Thunderbit (vårt) | 4.6.4 | 15.9 MiB | 78 | 8 igenkända (+1 oigenkänd array-sträng: commands) | <all_urls> | ✅ |
| Clay for Chrome | 1.0.0 | 6.3 MiB | 51 | 6 | *://*/* (injicerar endast på egen domän) | — |
| Listly | 0.9.6 | 3.5 MiB | 84 | 7 | http://*/*, https://*/*, file:///*.html | ✅ |
| Hexomatic | 1.8.4 | 2.7 MiB | 37 | 2 | endast egna domäner | — |
| Agenty | 2.9.7 | 2.2 MiB | 49 | 4 | ingen deklarerad | — |
| Clip to Clay | 1.8.0 | 0.7 MiB | 16 | 4 | 2 namngivna domäner | — |
| TexAu v2 | 1.6.6 | 0.3 MiB | 12 | 6 | 14 namngivna domäner | — |
Två till fanns på kandidatlistan men är inte med i tabellen, av skäl som är värda att redovisa var för sig.
Skillnaderna är ett designval, inte en effekt av storlek
Agenty deklarerar inga host permissions och levererar inga content scripts alls. Dess fyra behörigheter är activeTab, scripting, identity och identity.email. activeTab är den snäva varianten: den ger åtkomst till den aktuella fliken först efter att du klickat på tillägget, och bara tills du navigerar vidare. Inget körs på dina sidor om du inte själv aktiverar det. För 2.2 MiB.
Axiom.ai deklarerar http://*/* och https://*/*, injicerar content scripts som matchar <all_urls> och packas till 37.1 MiB över 232 filer — sjutton gånger Agenty:s storlek, med permanent åtkomst till varje sida du besöker.
Hexomatic ligger nära Agenty: två behörigheter (storage, tabs), inga host permissions och content scripts begränsade till dess två egna domäner.
Clay for Chrome är en tredje form som bör skiljas ut: det deklarerar *://*/* som host permission men injicerar content scripts bara på sin egen domän. Den permanenta kapaciteten är bred; det automatiska beteendet är smalt. En behörighetstabell blandar lätt ihop de två.
Fem av de tio kan nå filer på din disk
file:/// är inte en webbplats. Det är ditt lokala filsystem återgivet i en webbläsarflik — en PDF du öppnade, en HTML-export, en nedladdad faktura.
Officiell referens: Chrome match-pattern documentation.
Tre tillägg säger detta rakt ut. Två når dit utan att nämna det: <all_urls> inkluderar file:-schemat.
| Tillägg | Hur det når file:// | Nämner file:// i manifestet? | Var |
|---|---|---|---|
| Magical | matchar file:///* — varje lokal fil som Chrome kan rendera, inte bara HTML — i fyra av sina sex content-script-poster | ✅ | content scripts och web_accessible_resources |
| Listly | matchar file:///*.html | ✅ | content scripts |
| Table Capture | <all_urls> i content scripts, och det namnger även schemat | ✅ | web_accessible_resources |
| Axiom.ai | enbart genom wildcardet <all_urls> | — | ingenstans |
| Thunderbit (vårt) | enbart genom wildcardet <all_urls> | — | ingenstans |
http://*/* och https://*/* täcker inte file://; <all_urls> och *://*/* skiljer sig även här. De fem ovan är de vars deklarationer når schemat via den ena eller andra vägen — inte som en följd av vilket wildcard-format de valde.
Chrome skyddar allt detta bakom en per-tilläggsinställning "Allow access to file URLs" som är avstängd som standard, så deklarationen är en begäran snarare än ett beviljande. Fem av tio är den korrekta räkningen, och två av dessa fem skriver aldrig file:// någonstans i manifestet: Axiom.ai och vårt.
Den här siffran inkluderar web_accessible_resources, inte bara content scripts och host permissions. Table Capture namnger file://*/* där; att utelämna den delen skulle felaktigt placera det bland tillägg vars manifest når filer utan att nämna schemat.
Behörigheter du inte ser förrän de begärs

optional_permissions deklareras i förväg men begärs i körning, så de syns inte i installationsprompten. Två tillägg använder dem, och ett av dem är särskilt viktigt.
| Tillägg | optional_permissions | Det som spelar roll |
|---|---|---|
| Table Capture | userScripts, downloads, identity | userScripts kan köra användarsupplade skript i sidkontext efter att Chromes användargate har aktiverats |
| Magical | downloads, webRequest | webRequest observerar nätverkstrafik |
userScripts är frånvarande tills det begärs, och osynligt för den som bara läser en behörighetsräkning.
Det har också en grind som de andra behörigheterna i den här granskningen inte har, och att utelämna den skulle ha överdrivit dess betydelse. Att deklarera userScripts räcker inte för att använda det: Chrome kräver först en uttrycklig användaråtgärd. Före Chrome 138 var detta Developer Mode, som slogs på globalt på chrome://extensions. Från Chrome 138 är det en per-tilläggsinställning Allow User Scripts på tilläggets egen detaljsida, avstängd som standard. För en vanlig installation är funktionen alltså deklarerad men inert. Den exakta formuleringen är villkorad: Table Capture kan göra userScripts-API:t tillgängligt efter att användaren aktiverat Chromes grind. Den här granskningen mätte inte hur ofta användare besöker den inställningssidan eller aktiverar reglaget.
Ingen av dem är dold; båda finns i manifestet. En tabell som ignorerar den valfria sektionen underskattar två produkter.
Infognings-tid, inte bara räckvidd
Hur ett content script injiceras får ingen uppmärksamhet, men ändrar bilden. document_start är den tidigaste hook Chrome erbjuder; all_frames når tredjepartsinbäddningar.
Allt i gruppen som statiskt injicerar i alla frames, ordnat efter deklarerad timing:
| Tillägg | run_at | all_frames | Content-scriptens matchmönster |
|---|---|---|---|
| Table Capture | document_start | ✅ | <all_urls> |
| Listly | document_start | ✅ | file:///*.html plus alla http och https |
| Axiom.ai | document_start | ✅ | endast egna domäner |
| Clay for Chrome | document_start | ✅ | endast egna domäner |
| Thunderbit (vårt) | document_end | ✅ | <all_urls> |
| Magical | document_idle | ✅ | file:///* plus bred http och https |
| TexAu | document_idle (osatt) | ✅ | fjorton namngivna mönster |
Table Capture och Listly kör den tidigaste hooken över breda matchmönster. Axiom.ai och Clay for Chrome använder samma timing men bara på sina egna domäner — samma aggressivitet, smalt mål.
För statiska deklarationer är <all_urls> plus all_frames taket för matchbredd, och både Table Capture och Thunderbit ligger där. Deras deklarerade timing skiljer sig: Table Capture använder document_start; Thunderbit:s statiska content script använder document_end. Runtime-API:er är en separat kapacitetsklass och kan inte utläsas ur den här tabellen.
En enkel behörighetsräkning är en dålig sammanfattning. Table Capture deklarerar fyra behörigheter — färre än de flesta här — och injicerar vid document_start i alla frames på <all_urls>, plus userScripts på begäran.
Vem som får skicka meddelanden till tillägget
externally_connectable styr vilka webbsidor eller andra tillägg som får skicka meddelanden direkt till ett tilläggs bakgrundsskript. Standardbeteendet är inte intuitivt.
Att utelämna nyckeln är det tillåtande läget. Chromes standard när externally_connectable saknas är att alla tillägg kan ansluta, medan ingen webbsida får göra det. Att deklarera nyckeln är hur du begränsar.
Läst så blir tabellen omvänd:
| Tillägg | Deklaration av externally_connectable | Vem kan skicka meddelanden |
|---|---|---|
| Agenty | utelämnad | Tillåtande standard — alla tillägg kan ansluta, inga webbsidor kan |
| Clay for Chrome | utelämnad | Tillåtande standard — alla tillägg kan ansluta, inga webbsidor kan |
| Clip to Clay | utelämnad | Tillåtande standard — alla tillägg kan ansluta, inga webbsidor kan |
| Listly | utelämnad | Tillåtande standard — alla tillägg kan ansluta, inga webbsidor kan |
| Table Capture | utelämnad | Tillåtande standard — alla tillägg kan ansluta, inga webbsidor kan |
| TexAu | utelämnad | Tillåtande standard — alla tillägg kan ansluta, inga webbsidor kan |
| Thunderbit (vårt) | utelämnad | Tillåtande standard — alla tillägg kan ansluta, inga webbsidor kan |
| Hexomatic | åtta tilläggs-ID:n och sex webboriginer | Öppnar båda kanalerna från en stängd baslinje |
| Axiom.ai | sju webboriginer, inga ids | Tilläggskanalen stängd, sju webbsidor öppnas |
| Magical | {"ids": [], "matches": []} | Det enda tillägget här som stänger båda kanalerna uttryckligen |
Chromes regel har två nivåer. Enligt manifestreferensen:
| Situation | Vem får ansluta |
|---|---|
| hela nyckeln är frånvarande | "all extensions can connect, but no web pages can connect" |
nyckeln finns, ids är osatt eller [] | "no extensions or apps can connect" |
nyckeln finns, matches är osatt eller [] | "no web pages can connect" |
Det tillåtande standardläget gäller frånvaron av hela nyckeln. När nyckeln väl finns är båda underfälten stängda från början, och när värden namnges öppnas respektive kanal.
Axiom.ai deklarerar nyckeln med bara matches. Dess ids är därför osatt, vilket betyder att inga tillägg kan skicka meddelanden till det — tilläggskanalen är stängd, inte lämnas öppen. Det som öppnades är sju webboriginer, varav endast en är en Axiom-domän: två är tredjeparter utan tydlig attribution (*://*.tgwc.space/*, *://*.bitmachine.co.uk/*) och resten är localhost, 0.0.0.0, en Google APIs-värd och en stor social plattform som det inte driver.
Hexomatic öppnar sin tilläggskanal för åtta namngivna ID:n. När nyckeln finns är baslinjen noll tillägg; att namnge åtta öppnar åtta. Dess sex matches öppnar den andra kanalen från inget, och två av dessa är http://localhost:8000/* och http://localhost:3000/* över vanlig HTTP — allt som svarar på dessa portar på användarens maskin ligger inom allowlistan.
Sju av tio utelämnar nyckeln helt, inklusive vårt, och de sju ligger alltså på det tillåtande standardläget för tillägg-till-tillägg-kommunikation. Två tillägg stänger den kanalen: Magical uttryckligen med ids: [], och Axiom.ai genom att deklarera nyckeln men aldrig nämna ids. Magical är det enda som stänger båda.
Den sista raden är skälet till att läsa manifest i stället för att bara räkna behörigheter. Samma tillägg kan vara brett längs en axel och striktast i gruppen längs en annan.
Axeln ingen räknar: OAuth-scopes
Ett manifest kan innehålla ett oauth2-block, och scopes därinne är åtkomst till dina konton hos andra företag — en annan typ av räckvidd än allt ovan, och något som ingen behörighetsräkning fångar.
Officiell referens: Google OAuth 2.0 scope list.
| Tillägg | Begärda oauth2-scopes |
|---|---|
| Axiom.ai | openid, email, profile, auth/drive, auth/spreadsheets |
| Table Capture | auth/spreadsheets, auth/userinfo.email |
| Agenty | openid, email, profile |
| De övriga sju, inklusive vårt | inga deklarerade |
https://www.googleapis.com/auth/drive är den breda varianten. Google erbjuder ett snävare drive.file-scope som bara ger åtkomst till filer appen själv skapat eller som användaren uttryckligen valt; auth/drive innebär läsa, redigera, skapa och radera över hela användarens Drive. auth/spreadsheets har samma form för varje kalkylark kontot kan nå. Både Axiom.ai och Table Capture kombinerar ett Google-kontoscoper med <all_urls>-åtkomst till sidor.
Två begränsningar i vad denna tabell bevisar. Ett scope är begärt, inte beviljat — Google visar en samtyckesskärm och användaren kan neka, och tillägget kanske aldrig anropar API:et. Och manifestet ser bara OAuth som sker via Chromes identity-flöde; ett tillägg som i stället skickar dig till en webbinloggningssida deklarerar inget här. De sju nollorna betyder "inte begärt i den här filen", inte "ingen åtkomst till ditt Google-konto" — inklusive vårt, vilket är skälet till att den här axeln redovisas i stället för att påstås vara smal.
Vårt eget tillägg, på samma skala
Thunderbit 4.6.4 gick igenom samma manifestparser som de andra nio. Paketet är 15.9 MiB uppackat över 78 filer.
Deklarerat statiskt beteende: <all_urls> förekommer både i host permissions och i content-scriptens matchningar. Det statiska skriptet körs i all_frames vid document_end. Eftersom <all_urls> inkluderar file: kan manifestet nå lokala filer efter att användaren aktiverat Chromes filåtkomstreglage. Thunderbit utelämnar också externally_connectable, så Chromes standard tillåter meddelanden från alla tillägg men inga webbsidor.
Kapacitetstak i körning: permissions-arrayen innehåller nio strängar: activeTab, commands, debugger, offscreen, scripting, sidePanel, storage, tabGroups och tabs. Chrome känner igen åtta av dem som behörigheter; commands är en toppnivånyckel i manifestet och har ingen effekt som post i den här arrayen. Thunderbit är det enda tillägget i gruppen som deklarerar debugger, vilket kan ansluta CDP till en flik. Manifestet gör också scripting tillgängligt för registrering i körning. Dessa API:er skapar möjligheter utöver den statiska raden document_end, men en manifestläsning kan inte visa att Thunderbit anropar en viss CDP-metod eller registrerar ett skript vid en viss tidigare tidpunkt.
Den skillnaden stoppar flera lockande men felaktiga jämförelser. Avsaknaden av en snävare cookies-behörighet begränsar inte vad kod med debugger kan komma åt. Avsaknaden av clipboardRead är inte bevis för att clipboard-åtkomst är omöjlig. Omvänt är förekomsten av debugger inte bevis för att dessa vägar används. För att besvara någon av de frågorna krävs källkodsläsning eller runtime-spårning, och inget av det gjordes här.
I det här instrumentet är Thunderbit brett på statisk sidåtkomst, unikt i gruppen genom att deklarera debugger, och på Chromes standard för tillägg-till-tillägg-meddelanden. Det finns ingen enda "starkast"-rankning eftersom granskningen inte tillhandahåller en gemensam hotmodell för CDP, OAuth, userScripts, clipboard och host access.
Den återhållsamma designen ingen marknadsför
TexAu är 0.3 MiB — minst här med god marginal — och namnger fjorton specifika webbplatser i stället för att använda ett wildcard: sociala nätverk, en utvecklarplattform, publiceringsplattformar, en chattprodukt, en leverantör av företagsdata och sin egen domän. Dess content scripts matchar exakt samma fjorton.
Du kan läsa manifestet och veta exakt var tillägget är aktivt. Det är också en produktdeklaration — mål-listan säger tydligare vad verktyget är för än vad marknadsföringen gör.
Avvägningen är verklig: en namngiven lista kan inte skrapa en sajt som inte finns med, och varje nytt mål kräver en release. Men "fjorton namngivna domäner" och "varje URL som finns" är väldigt olika saker, och bara en av dem är lätt att förstå.
Två produkter som inte var vad listan påstod
Captain Data:s tillägg distribueras inte offentligt. Googles uppdateringsändpunkt returnerar HTTP 204 med tomt svar för dess tilläggs-ID — svaret för något som butiken inte serverar anonymt. Dess listingsida däremot serverades anonymt — HTTP 200, 509 829 byte. Det som insamlingen inte kunde hitta där var versionssträng, senaste uppdateringsdatum eller installationsantal; skriptets egna anteckningar säger att ett null-värde där är svagt bevis, och ingen inloggningsvägg observerades. ID:t är äkta och förstapartsrelaterat, så den mest sannolika tolkningen är länkbaserad eller olistad distribution, men jag kunde inte skilja det från att det tagits bort ur butiken och tänker inte gissa.
Dataflow Kit har inget Chrome-tillägg alls. Deras webbplats beskriver en hostad webbapp med punkt-och-klick-val och ett REST API. Det hade ändå hamnat på en shortlist för Chrome-tillägg — vilket är sådana här listor ofta byggs.
Föråldring och räckvidd, eftersom båda är gratis att kontrollera
Butiksmetadata ger produkturvalskontext utöver behörigheter. Samma fält samlades in för varje tillägg den 2026-07-30.
| Tillägg | Butiksversion | Senast uppdaterad | Installationsintervall |
|---|---|---|---|
| Thunderbit (vårt) | 4.6.4 | 28 juli 2026 | 200 000 |
| Listly | 0.9.6 | 25 juli 2026 | 100 000 |
| Axiom.ai | 5.1.0 | 20 juli 2026 | 100 000 |
| Table Capture | 11.0.41 | 26 juni 2026 | 200 000 |
| Magical | 3.119.1 | 4 april 2026 | 200 000 |
| Agenty | 2.9.7 | 8 februari 2026 | 10 000 |
| TexAu | 1.6.6 | 20 augusti 2025 | 7 000 |
| Clay for Chrome | 1.0.0 | 9 april 2025 | 10 000 |
| Clip to Clay | 1.8.0 | 8 april 2025 | 1 000 |
| Hexomatic | 1.8.4 | 6 september 2024 | 3 000 |
| Captain Data | — | — | inte offentligt serverad |
Tre produkter har inte släppts på över ett år, och Hexomatic på nästan två. För tillägg är det viktigare än för bibliotek: Chrome släpper en stabil version ungefär var fjärde vecka och själva tilläggsplattformen förändras hela tiden under ytan. userScripts flyttade sin användargate i Chrome 138; ett tillägg som senast släpptes 2024 byggdes mot en annan uppsättning regler än den webbläsare som nu tillämpar dem.
Två saker den här tabellen inte är. Installationsantal är bucketade av Google — 1 000 / 3 000 / 7 000 / 10 000 / 100 000 / 200 000 — så de jämför ordningstal och inget finare, och flera produkter marknadsför större siffror på egen hand. Ett färskt datum är ett faktum om leverans, inte ett omdöme om underhållskvalitet eller behörighetsrisk.
En nyttig bieffekt: butiksversionen matchar manifestversionen i varje enskilt av de tio analyserade paketen. De CRX-filer som den här granskningen läste är de som butiken serverar idag, inte gamla kopior.
Färskhet ändrar hur mycket uppföljningsarbete ett urval förtjänar; den ändrar inte manifestsemantiken. Ett tillägg med namngivna domäner som senast uppdaterades för ett år sedan kan fortfarande exponera mindre sida än ett wildcard-tillägg som släpptes igår. Det nyare paketet kan ändå vara det bättre operativa valet om det följer Chrome-förändringar snabbare. För en shortlist: använd butiksdatumet för att avgöra vad som ska testas om, och använd manifestet för att avgöra vad som kräver en djupare kapacitetsgranskning. Gör inte om de två kolumnerna till en enda poäng.
Vad ett manifest inte berättar
En deklarerad behörighet är ett tak, inte ett beteende. <all_urls> betyder att ett tillägg får läsa varje sida. Det betyder inte att det gör det, eller att något lämnar din maskin. För att fastställa vad som faktiskt händer krävs övervakning av nätverkstrafik i körning — ett annat arbete, inte gjort här, och inget ovan ska läsas som bevis för missbruk.
Relaterad genomgång: Chrome extension testability experiment.
Tre ytterligare gränser:
- Chrome sätter mycket av detta bakom grindar. Filåtkomst är avstängd som standard;
activeTabär medvetet snäv; valfria behörigheter kräver en prompt i körning; användaren ser en behörighetslista vid installation. - Breda behörigheter är ofta nödvändiga. Ett verktyg vars jobb är "extrahera en tabell från vilken sida du än är på" kan inte fungera från en allowlist med namngivna domäner. Snäv räckvidd är ibland disciplin och ibland bara en mindre produkt.
- En version, en dag. Alla siffror kommer från paketet som serverades den 2026-07-29.
Materiella korrigeringar i analysen
De publicerade siffrorna använder tre regler som är lätta att göra fel på när man skriver en snabb manifestparser. För det första inkluderar <all_urls> file:-schemat, men Chrome håller faktisk filåtkomst bakom en användarkontrollerad toggle. För det andra måste web_accessible_resources.matches granskas tillsammans med content scripts och host permissions; det är där Table Capture uttryckligen namnger file://*/*. För det tredje har externally_connectable olika standardvärden beroende på om hela nyckeln saknas eller om nyckeln finns med ett tomt underfält. Tabellerna ovan tillämpar dessa regler konsekvent.
Thunderbit:s behörighetstal skiljer också mellan råa strängar och erkända Chrome-behörigheter. Dess array har nio poster, men commands hör hemma på toppnivå, så den effektiva räkning som används här är åtta erkända behörigheter plus en oigenkänd sträng. Slutligen är statiska content_scripts-deklarationer inte bevis för att kod anropar scripting.registerContentScripts eller en CDP-metod. De möjligheterna förekommer bara under runtime-kapacitet, aldrig som observerat beteende. De råa manifesten, CRX-hasherna och parserutdata är revisionsspåret för dessa normaliseringar, så läsaren behöver inte lita blint på prosan.
För ett faktiskt installationsbeslut bör minst fyra dimensioner jämföras separat: vilka sidor som omfattas som standard, vilken uttrycklig användaråtgärd som låser upp mer räckvidd, vilka webbläsar- eller konto-API:er som blir tillgängliga, och vilka externa anropare som kan skicka meddelanden till tillägget. Agenty:s activeTab-modell, Table Capture:s gateade userScripts, Axiom.ai:s Drive-scope och Thunderbit:s debugger-deklaration är inte punkter på en enda linjär skala. De är olika svar på olika hotfrågor.
Här är jämförelsen tillämpad på fyra medvetet olika designer:
| Tillägg | Sidomfång som syns i manifestet | Ytterligare grind | Icke-sidokapacitet i denna granskning | Inställning för externa anropare |
|---|---|---|---|---|
| Agenty | ingen host permission eller statiskt content script | användaren aktiverar activeTab på den aktuella fliken | Chromes identity-behörigheter | nyckeln utelämnad: alla tillägg kan ansluta, inga webbsidor kan |
| Table Capture | statiska scripts på <all_urls> i alla frames vid document_start | filåtkomst är avstängd som standard; userScripts behöver Chromes separata användargate | valfria userScripts, downloads och identity | nyckeln utelämnad: alla tillägg kan ansluta, inga webbsidor kan |
| Axiom.ai | HTTP- och HTTPS-wildcardåtkomst; statiska scripts vid document_start på egna domäner | OAuth-samtycke för begärda Google-scopes | Drive- och Sheets-OAuth-scopes deklarerade | tilläggsanropare stängda; sju webboriginer öppna |
| Thunderbit | <all_urls> host access och statiska scripts i alla frames vid document_end | filåtkomst är avstängd som standard; att fästa debugger har Chrome-styrt användarsynligt beteende | debugger, scripting, tabs och relaterade webbläsar-API:er deklarerade | nyckeln utelämnad: alla tillägg kan ansluta, inga webbsidor kan |
Den här tabellen ger fortfarande ingen vinnare. Agenty:s snäva permanenta sidåtkomst säger inget om vad dess backend gör med inskickad data. Axiom.ai:s kontoscopes är inte jämförbara med ett tillägg som läser den aktuella sidan. Table Capture:s userScripts-deklaration är inert tills användaren aktiverar dess separata grind. Thunderbit:s debugger-behörighet exponerar en bred kontrollyta för webbläsaren, men manifestet avslöjar inte vilka CDP-domäner eller metoder koden anropar. Varje rad säger vad du bör granska härnäst: runtime-nätverkstrafik, källkod, samtyckesflöde eller webbläsar-API-spår.

Samma uppdelning är viktig när du läser Chromes installationsprompt. En enkel behörighetsräkning kan inte visa timing, frame-räckvidd, OAuth-scope, web_accessible_resources eller en utelämnad externally_connectable-nyckel. Omvänt är en bred deklaration inte bevis för insamling eller exfiltration. Det användbara resultatet av en manifestgranskning är en prioriterad plan för runtime-testning: identifiera dataytan, notera användargaten och observera sedan om den deklarerade vägen faktiskt används.
Så läser du ditt eget
Relaterad genomgång: browser automation guide.
chrome://extensions→ Detaljer visar beviljad webbåtkomst och låter dig ställa in den till on click för allt som inte behöver permanent åtkomst. Det snävar in den del som gäller sidåtkomst i det som beskrivs ovan. Det påverkar inte inkommande meddelanden
(externally_connectablenår service workern oavsett), eller behörigheter på webbläsarnivå.
Thunderbit:s deklaration avdebuggerär relevant här. Chromiums egen säkerhetsdokumentation för tillägg säger att debugger-API:t
"may in some cases also sidestep other typical restrictions, such as host permissions or file
access", så att sätta sidåtkomst till "on click" begränsar inte vad det kan nå. Inte heller påverkar kontrollentabs,webNavigation,clipboardRead,downloadseller något i
optional_permissions.- För själva paketet ligger filen under Chromes katalog
Extensions/<id>/<version>/. Läs sex fält:permissions,optional_permissions,host_permissions,content_scripts(särskiltmatches,run_atochall_frames),externally_connectable— och kom ihåg att en utebliven nyckel är tillåtande för tilläggsanropare — samtweb_accessible_resources, varsmatcheskan namnge scheman som content scripts aldrig gör. Thunderbit:s sista fält har två<all_urls>-poster som exponerarindex.htmloch två bundlade skript för varje origin, meduse_dynamic_url: false, vilket gör att en sida kan testa om dessa stabila tilläggs-URL:er går att slå upp. - Kontrollera butikens senaste uppdateringsdatum mot den aktuella Chrome-versionen.
Upplysning och resurser: den här artikeln publiceras av Thunderbit, vars tillägg ingår i samma tabell och parser. Vår open-source scraper pillar täcker verktyg som inte är tillägg.
Prova Thunderbit för extrahering av webdata
Kortversionen
Tio scraping- och automationstillägg, inklusive vårt, lästes från sina egna manifest.
Agenty deklarerar ingen webbåtkomst och inga content scripts, och arbetar bara på den flik du tittar på när du klickar, i 2.2 MiB. Axiom.ai deklarerar varje HTTP- och HTTPS-URL över 37.1 MiB. Magical deklarerar tretton behörigheter inklusive clipboardRead — och är också det enda tillägget här som helt stänger inkommande meddelanden. Table Capture deklarerar bara fyra behörigheter, och injicerar vid document_start i alla frames på <all_urls> — samma matchtak som vårt når, men tidigare — plus userScripts på begäran. TexAu är minst, och namnger flest mål — fjorton mönster över tretton distinkta egenskaper. Det är inte den enda som namnger mål: Clip to Clay deklarerar två (clay.com och en tredje part), och Hexomatic samt Clay for Chrome namnger sina egna domäner. TexAu är den enda vars namngivna lista mestadels består av andra aktörers webbplatser. Fem av de tio kan nå filer på din disk, och två av dem — Axiom.ai och vårt — utan att någonsin skriva file://.
Thunderbit, vårt, ligger i den breda änden: <all_urls> för både host access och statisk injicering, plus debugger, som inget annat tillägg i den här gruppen deklarerar. Det ligger på Chromes standard som tillåter meddelanden från alla tillägg, och det når file:// efter att Chromes användargate för filåtkomst har aktiverats.
En deklaration är ett tak, inte ett beteende, och inget av detta visar missbruk. Men det är publicerat, gratis att kontrollera, och spridningen mellan de två ändarna är större än något på produktsidorna.
Prova Thunderbit för extrahering av webdata Get Started Free
Vanliga frågor
Betyder en bred behörighet att tillägget gör något fel — och varför räcker det inte att bara räkna behörigheter?
Nej, och för att räkningen missar två saker. <all_urls> betyder att ett tillägg får läsa varje sida du besöker; det säger inget om vad det faktiskt gör eller om något lämnar din maskin, och ett verktyg som ska extrahera data från vilken sida som helst kan verkligen inte fungera från en lista med namngivna domäner. Resultatet här är spridningen, inte missbruk — för att fastställa faktiskt beteende krävs analys av runtime-trafik, vilket denna granskning inte gjorde. Och om räkningen: injiceringsinställningar är inte behörigheter, så Table Capture deklarerar fyra samtidigt som det injicerar vid document_start, i all_frames, med matchning på <all_urls>. Och optional_permissions syns inte alls i installationsprompten — Table Capture kan begära userScripts i körning, vilket tillåter körning av godtyckliga användarskript i sidkontext, och Magical kan begära webRequest.
Vilket av dessa begär minst?
Agenty: fyra behörigheter, inga host permissions, inga content scripts. Det bygger på activeTab, som ger åtkomst till den aktuella fliken först efter att du klickat på tillägget och bara tills du navigerar bort. Hexomatic är nästa, med två behörigheter och content scripts begränsade till sina egna domäner.
Hur kan ett tillägg nå mina lokala filer utan att deklarera file://?
För att <all_urls> inkluderar file:-schemat. Listly, Magical och Table Capture namnger file://-mönster uttryckligen — Magical i sina content scripts och Table Capture i web_accessible_resources. Axiom.ai och Thunderbit når det via wildcardet utan att nämna det någonstans. http://*/* och https://*/* täcker inte file://. Chrome håller filåtkomst av som standard bakom en per-tilläggsinställning, så deklarationen är en begäran snarare än ett beviljande.
Vad är externally_connectable, och varför är utelämnandet det tillåtande alternativet?
Det namnger de webboriginer eller tilläggs-ID:n som får skicka meddelanden till ett tilläggs bakgrundsskript. Chromes standard när nyckeln saknas är att alla tillägg får ansluta, men inga webbsidor får göra det. Sju av dessa tio utelämnar den, inklusive Thunderbit. När nyckeln finns öppnar Hexomatic tilläggskanalen för åtta namngivna ID:n; Axiom.ai öppnar sju webboriginer medan tilläggskanalen förblir stängd; Magical deklarerar tomma listor för båda och stänger därmed båda kanalerna.
Vad deklarerar Thunderbit:s eget manifest?
<all_urls> för host access och statisk content-script-injicering, i all_frames vid document_end; 15.9 MiB över 78 filer; och nio strängar i behörighetsarrayen. Åtta av dem är erkända behörigheter: activeTab, debugger, offscreen, scripting, sidePanel, storage, tabGroups och tabs. commands är en toppnivånyckel i manifestet och har ingen effekt i den arrayen. Inget annat tillägg i den här gruppen deklarerar debugger. Thunderbit når också file:// via <all_urls> efter att Chromes filåtkomstgate har aktiverats, och det utelämnar externally_connectable. Runtime-beteende kördes inte, så granskningen påstår inte vilka CDP- eller scripting-metoder tillägget faktiskt anropar.


