Jag kör ett Chrome-tillägg. Dess manifest begär identity-behörigheten, en värdbehörighet avgränsad till min egen Supabase-backend, och, viktigare än någon av dem, ett innehållsskript som körs på varje http://- och https://-sida du besöker, vilket är vad som faktiskt utlöser Chromes bredaste varning om att “läsa och ändra all din data på webbplatserna du besöker”, inte backend-värdbehörigheten. Jag har skrivit den fullständiga genomgången av vad allt det där är till för någon annanstans på den här sajten. Jag namnger det igen här, direkt, för ett inlägg vars hela argument är “bedöm tillägg efter deras manifest, inte deras säljargument” förtjänar bara rätten att göra det argumentet om det överlever att pekas på sin egen författare först.
Med det sagt: här är hur man faktiskt läser ett manifest, och vad det visar när man tillämpar metoden på åtta tillägg folk installerar varje dag, plus en självkritisk titt på var mitt hamnar.
Hur du läser vilket tilläggs manifest som helst själv
Chrome Web Stores installationsprompt är en sammanfattning. Manifestet är källan. Några saker värda att veta innan du jämför de två:
- Permissions, host permissions och content scripts är tre separata deklarationer som var och en oberoende kan utlösa samma breda varning. Ett tillägg kan se smalt ut i sin
permissions-array och ändå köra på varje sida du besöker på grund av ettcontent_scripts-block med bredamatches, eller enhost_permissions-post på<all_urls>. Läs alla tre, inte bara den installationsprompten råkar sammanfatta först. - En deklarerad behörighet är ett tak, inte en garanti för användning. Vissa tillägg deklarerar bred åtkomst i manifestet men levererar ett smalare standardbeteende, och utövar bara det fulla omfånget när du uttryckligen väljer in en funktion som behöver det. Det är en verklig distinktion värd att kontrollera, inte bara anta bort, och det skär åt andra hållet också: ett manifest som ser smalt ut på papper kan fortfarande göra något med den åtkomst det faktiskt har som du skulle vilja veta om.
optional_permissionsochoptional_host_permissionsär ett meningsfullt annorlunda påstående än samma åtkomst begärd vid installation. En behörighet Chrome bara frågar om i samma stund du klickar på en specifik funktion är en mindre, mer ansvarsutkrävbar begäran än samma behörighet buntad in i varje installation, även om de två slutar med att bevilja identisk API-åtkomst när den väl utlöses.- Manifest V3 stänger strukturellt av en hel kategori risk: tillägg kan inte längre hämta och köra godtycklig JavaScript från en fjärrserver vid körning. Det här är inte längre bara en mjuk rekommendation heller: Chrome slutade köra Manifest V2-tillägg 2025, och Google avlistar de återstående helt från Web Store den 31 augusti 2026. Ett tillägg som aldrig migrerade bort från V2 är inte ett “värt en andra titt”-fall längre, det är ett som antingen redan inte körs eller är på väg att försvinna.
- Om det är öppen källkod, läs det faktiska manifest.json i repot, inte en sammanfattning av det, inklusive det här inläggets. Om det är sluten källkod är Chrome Web Store-listningens egen behörighetsredovisning den mest pålitliga offentliga signalen tillgänglig för dig, tunnare än källkod, men fortfarande mer exakt än funktionsbeskrivningen ovanför den.
- En integritetspolicy som namnger exakt vad som lämnar enheten, och under vilket villkor, är värd mer än en som säger “vi kan samla in information för att förbättra våra tjänster”. Vaga policyer är standardtext oavsett hur bra tillägget faktiskt är.
- Inget av det här är en engångskontroll. Ett tilläggs ägarskap kan byta händer efter att du redan installerat det, och en ny ägare kan leverera en uppdatering som bär ny funktionalitet under samma namn och samma installationsbas. Jag går in på hur det ser ut längre ner.
Vad det ser ut som tillämpat på åtta riktiga tillägg
Jag hämtade det faktiska manifestet för vart och ett av dessa, från projektets eget GitHub-repo där tillägget är öppen källkod, eller från Chrome Web Stores egen behörighetsredovisning där det inte är det.
| Tillägg | Behörigheter/värdåtkomst | Bred åtkomst? | Motiverad? |
|---|---|---|---|
| uBlock Origin Lite | activeTab, alarms, declarativeNetRequest, offscreen, scripting, storage, unlimitedStorage, userScripts; host_permissions: <all_urls> | Deklarerad bred, standard smal | Ja, och mestadels oanvänd som standard. <all_urls> är taket för dess valfria lägen “Optimal” och “Complete”; standardläget “Basic” blockerar rent genom declarativeNetRequests statiska regeluppsättningar och läser aldrig sidinnehåll om du inte själv höjer läget, per sida |
| Bitwarden | activeTab, alarms, clipboardRead, clipboardWrite, contextMenus, idle, offscreen, scripting, sidePanel, storage, tabs, unlimitedStorage, webNavigation, webRequest, webRequestAuthProvider, notifications; host_permissions: https://*/*, http://*/* | Ja | Ja. Autofyllning kan inte fungera utan att läsa formulärfälten på sidan du är på, och det kan vara vilken sida som helst |
| ClearURLs | <all_urls>, webRequest, webRequestBlocking, tabs, downloads, contextMenus, webNavigation, storage, unlimitedStorage (fortfarande Manifest V2) | Ja, på papper | Det här är ett varnande exempel, inte ett “folk installerar det här varje dag”-exempel. URL-omskrivning skulle motivera åtkomsten om den fortfarande kördes: det här är ett Manifest V2-tillägg, dess underhållare stängde uttryckligen begäran att migrera till V3 som “inte planerad”, Chrome slutade redan köra det, och Google avlistar återstående MV2-tillägg från Web Store den 31 augusti 2026, tio dagar efter att det här inlägget publicerades |
| Privacy Badger (EFF) | alarms, declarativeNetRequest, privacy, scripting, storage, tabs, webNavigation, webRequest; host_permissions: <all_urls> | Ja | Ja. Att upptäcka tredjepartsspårare genom att bevaka vilka domäner som dyker upp över orelaterade sidor är mekanismen, inte en bieffekt av den. (Värt att veta som läsare: EFF:s egen GitHub-källfil är en obyggd MV2-mall, inte vad som faktiskt publiceras. Raden ovan är de riktiga levererade Manifest V3-behörigheterna, hämtade från den live Chrome Web Store-binären, inte repot.) |
| Dark Reader | alarms, fontSettings, scripting, storage; host_permissions: *://*/* | Ja | Ja. Att skriva om en sidas CSS för att invertera eller dimma den har ingen version som fungerar på bara vissa sidor |
| GoFullPage | activeTab, scripting, storage, unlimitedStorage; optional_host_permissions: <all_urls>, file://*/* | Deklarerad bred, opt-in | Matchar jobbet. Beviljandet vid installation är smalt, activeTab rör bara fliken du aktivt utlöser en infångning på. Bredare åtkomst finns i manifestet men sitter bakom optional_host_permissions, vilket betyder att Chrome bara beviljar den om ett specifikt infångningsscenario (som en sida som innehåller iframes) faktiskt begär det, inte vid installation |
| Vimium | tabs, bookmarks, history, storage, sessions, notifications, scripting, favicon, webNavigation, search; host_permissions: <all_urls> | Ja | Ja. Tangentbordsstyrd navigering av varje sida måste köras överallt, och bokmärkes-/historikåtkomsten backar upp dess egna tangentbordskommandon för att hoppa till ett bokmärke eller en tidigare sida, inte en separat funktion tillagd i efterhand |
| OneTab | tabs, activeTab, scripting, storage, unlimitedStorage, contextMenus, favicon (sluten källkod; baserat på det live Chrome Web Store-manifestet, inte en primär GitHub-källa) | Ingen bred värdåtkomst, men inte ingenting | Matchar jobbet, med en behörighet värd att faktiskt läsa: tabs ger URL:en och titeln för varje flik du har öppen, inte bara den du agerar på, vilket är exakt den typen av sak den här metoden finns för att lyfta fram istället för att anta bort från bara en funktionsbeskrivning |
| Second Bookmark Bar (mitt) | activeTab, bookmarks, storage, favicon, identity, alarms; valfri tabGroups (begärd vid körning enbart, inte vid installation); värdbehörighet avgränsad till en Supabase-domän; innehållsskript på http://*/* och https://*/* vid document_start | Ja | Mestadels, men innehållsskriptets omfång är verkligt. Det är vad som ritar fältet och läser ett draget elements detaljer, och det är genuint bredare än bokmärkes-/lagrings-/activeTab-behörigheterna ovanför det, vilket är den ärliga anledningen till att det här tillägget inte rankas högst i den här tabellen |
Ett hypotetiskt gratis tillägg med <all_urls>, en buntad annons- eller analys-SDK, och en kopierad integritetspolicy | <all_urls> plus utgående anrop till en tredjeparts-SDK-domän | Ja | Nej, med flit. Det här är formen att hålla utkik efter, inte en specifik produkt: bred åtkomst utan någon funktion som uppenbart behöver den, monetiserad genom ett nätverksanrop beskrivningen aldrig nämner, backad av en policy som läser som standardtext snarare än en redovisning |
Några saker värda att lyfta ur den tabellen istället för att lämna dem begravda i den. OneTab och GoFullPage har minst värdåtkomst av allt här, ingen av dem ber om en enda sida den kan nå fritt, och det är ingen olyckshändelse: ett flikslistverktyg och ett skärmdumpsverktyg behöver genuint inte se sidinnehåll bortom vad du agerar på, så de ber inte om det. Men “minst åtkomst” är inte samma sak som “ingen behörighet värd att läsa”. OneTab deklarerar fortfarande tabs, vilket ger den URL:en och titeln för varje flik du har öppen samtidigt, inte bara den du klickar på, och det är en riktig, specifik sak att veta om ett verktyg som annars ser ut ungefär så smalt som den här listan blir. (Om flikhamstring är det faktiska problemet du löser har jag också skrivit om hur OneTab jämförs med Second Bookmark Bar om du väljer mellan de två metoderna.) Bitwarden, Privacy Badger, Dark Reader och Vimium är alla breda vid installation och alla motiverade, för det var och en gör strukturellt kräver att se varje sida: autofyllning, korssideskt spårardetektering, CSS-omskrivning och universell tangentbordsinfångning har ingen version som fungerar på en delmängd av webben. ClearURLs skulle höra hemma i samma grupp på ren manifestgrund, URL-omskrivning behöver se varje URL, men det är värt att veta att den grunden mestadels är teoretisk nu: det migrerade aldrig bort från Manifest V2, och Chrome slutade köra MV2-tillägg 2025.
uBlock Origin Lite är det mest intressanta fallet, och det jag hade fel om vid första läsningen. Dess manifest deklarerar genuint <all_urls>, punkt slut, ingen asterisk. Men den deklarationen är ett tak för valfria lägen de flesta användare aldrig slår på; läget det levereras aktivt som standard, “Basic”, blockerar rent genom declarativeNetRequests förkompilerade regeluppsättningar och läser aldrig faktiskt en sidas innehåll om du inte uttryckligen höjer filtreringsnivån på en given sida. Läxan är inte “uBlock Origin Lite har noll behörigheter”, vilket skulle ha varit fel. Det är att ett manifest berättar det maximala ett tillägg skulle kunna göra, och du måste fortfarande kontrollera vad det faktiskt gör som standard innan du vet om det maximumet spelar roll dag för dag.
Och sedan är det mitt. Second Bookmark Bar toppar inte den här tabellen, och det borde det inte. Innehållsskriptet som körs på varje sida du besöker är riktig bred åtkomst, punkt slut, och ingen mängd “det läser bara element när du drar dem” ändrar vad manifestet deklarerar. Det är samma standard jag tillämpar på alla andra i den här tabellen, så den måste gälla min egen rad också, annars är resten av det här inlägget bara marknadsföring utklädd till en behörighetsgranskning. Om du vill ha den fullständiga fall-för-fall-genomgången av vad det innehållsskriptet gör och inte gör med åtkomsten det har, är det det fullständiga säkerhetsinlägget, och om du specifikt utvärderar det här på uppdrag av ett företag snarare än dig själv finns det en säkerhetsgranskarversion av samma redovisning skriven för det användningsfallet.
Behörigheter är inte en engångskontroll
I februari 2026 bytte ett Chrome-tillägg kallat QuickLens, ett “Google Lens”-liknande sökskärmsverktyg med ungefär 7 000 installationer, ägare. Det hade varit listat för försäljning på en tredjeparts tilläggsmarknadsplats strax efter att det först publicerades, och vid den 1 februari hade det en ny ägare som opererade under ett annat namn, med en integritetspolicy utbytt mot en hostad på vad forskare beskrev som en knappt fungerande domän. Den 17 februari levererades en ny version som lade till kod för att upptäcka installerade kryptovaluta-plånböcker, inklusive MetaMask, Phantom, Coinbase Wallet, och flera andra, och försökte skörda inloggningsuppgifterna som behövdes för att tömma dem. Flera säkerhetsforskare och medier täckte det som en dokumenterad leveranskedjeincident när den väl upptäcktes, inte ett rykte.
Ingenting i den historien krävde en manifeständring de flesta användare skulle ha märkt vid tillfället. Tilläggets installationsbas, dess namn, och dess listning var desamma. Vad som ändrades var vem som stod bakom det och vad den nya ägaren valde att leverera. Det är den ärliga gränsen för allt ovan: att läsa ett manifest berättar vad ett tillägg kan göra just nu, från de som för närvarande kontrollerar det. Det berättar inte vem som kommer kontrollera det om ett år, eller vad de kommer besluta att lägga till. Att kontrollera behörigheter en gång vid installationstillfället är en rimlig vana. Att behandla den kontrollen som permanent är det inte.
Vad du ska göra om ditt jobb-Chrome blockerar ett tillägg
Inget av den här granskningen spelar roll om din arbetsgivares Chrome-policy blockerar tillägget helt innan du någonsin ser en installationsprompt, vilket är en separat, mycket vanligare situation än ett genuint riskabelt manifest. Om du har stött på den där grå “blockerad av din organisation”-dialogrutan har jag skrivit om vad den blockeringen faktiskt är och hur begär-installation-flödet fungerar, inklusive vad din IT-admin faktiskt ser när du ber dem godkänna något. Och om du är den på andra sidan av den begäran, som bestämmer om du ska godkänna ett tillägg för ett team snarare än bara för dig själv, är behörighet-för-behörighet-granskningen skriven för den granskaren sidan byggd specifikt för det beslutet.