Co naprawdę zdradzają manifesty rozszerzeń Chrome o ich uprawnieniach

Każde rozszerzenie Chrome ma plik manifest.json, który ujawnia sporą część jego możliwości na poziomie przeglądarki: żądane API, wzorce hostów, statyczne skrypty treści, uprawnienia opcjonalne i dozwolone połączenia zewnętrzne. To publiczny plik w paczce, którą instalujesz. Nie pokazuje jednak, z których zadeklarowanych możliwości kod faktycznie korzysta w czasie działania, co opuszcza urządzenie ani jakie operacje na kontach odbywają się przez osobne logowanie w przeglądarce.

Przeanalizowałem dziesięć rozszerzeń do scrapingu i automatyzacji przeglądarki wybranych do tego audytu, w tym Thunderbit — nasze własne. Rozpiętość jest duża. Jedno nie deklaruje stałego dostępu do żadnej witryny. Inne wymienia trzynaście uprawnień, w tym clipboardRead. Thunderbit jest jedynym rozszerzeniem w tym zestawie, które deklaruje debugger — szeroką możliwość podpinania się do CDP, o innym profilu ryzyka niż dostęp do stron, OAuth czy skrypty dostarczane przez użytkownika.

To nie jest zarzut. Szerokie uprawnienie często jest jedynym uczciwym sposobem na zbudowanie danej funkcji, a wąskie może po prostu oznaczać mniej rozbudowany produkt. Chodzi o to, że różnica jest ogromna, jest publicznie widoczna i nigdy nie trafia do tabeli porównawczej.

Jak to zrobiono

Każde rozszerzenie pobrano jako .crx z własnego endpointu aktualizacji Google — dokładnie z tego samego adresu, którego używa Chrome — a następnie rozpakowano i sparsowano. Żadne rozszerzenie nie zostało zainstalowane i żaden kod rozszerzenia nie został uruchomiony. To odczyt pliku JSON.

Pobieranie odbywało się w tempie mniej więcej jednego żądania na dwie sekundy. Każdy plik .crx, jego SHA-256 i wyodrębniony manifest.json są zachowane jako artefakty. Thunderbit przeszedł przez ten sam skrypt co pozostała dziewiątka, bez żadnej bocznej ścieżki, więc jego wiersz został wyprowadzony dokładnie tak samo jak ich.

Analiza opiera się na dwóch klasach dowodów i trzyma je osobno:

• Deklarowane zachowanie statyczne: wzorce hostów i wpisy content_scripts, w tym matches, run_at i all_frames.
• Możliwości dostępne dla kodu w czasie działania: API wymienione w permissions lub optional_permissions. Te deklaracje pokazują, o co kod może poprosić lub co może wywołać — nie że faktycznie to robi.

Nie przypisano żadnego rankingu typu „najmocniejsze”. debugger, userScripts, szeroki dostęp do hostów, zakresy OAuth, dostęp do schowka i komunikacja zewnętrzna ujawniają różne dane i wymagają różnych warunków wstępnych. Porównanie ich wymagałoby modelu zagrożeń, którego ten audyt oparty wyłącznie na manifestach nie dostarcza.

Wartości poniżej to łączne rozmiary po rozpakowaniu w MiB (2²⁰ bajtów), zsumowane z wpisów ZIP.

Stan na 2026-07-29. Rozszerzenia się aktualizują; sprawdź ponownie przed cytowaniem.

Co deklaruje dziesięć manifestów

Oficjalne odniesienie: Chrome's permission declaration guide.

Dwie kolejne pozycje były na liście kandydatów i nie trafiły do tabeli z powodów, które warto opisać osobno.

Rozpiętość to decyzja projektowa, nie efekt rozmiaru

Agenty nie deklaruje żadnych uprawnień hosta i nie ma w ogóle skryptów treści. Jego cztery uprawnienia to activeTab, scripting, identity i identity.email. activeTab to to węższe: daje dostęp do bieżącej karty dopiero po kliknięciu rozszerzenia i tylko do momentu opuszczenia strony. Nic nie uruchamia się na Twoich stronach, jeśli sam tego nie wywołasz. W 2.2 MiB.

Axiom.ai deklaruje http://*/* i https://*/*, wstrzykuje skrypty treści pasujące do <all_urls> i po rozpakowaniu zajmuje 37.1 MiB w 232 plikach — siedemnaście razy więcej niż Agenty, ze stałym dostępem do każdej strony, którą odwiedzasz.

Hexomatic stoi obok Agenty: dwa uprawnienia (storage, tabs), bez uprawnień hosta, a skrypty treści ograniczone do własnych dwóch domen.

Clay for Chrome to trzeci, wyraźnie odmienny wariant: deklaruje *://*/* jako uprawnienie hosta, ale skrypty treści wstrzykuje wyłącznie na swojej domenie. Stała możliwość jest szeroka; automatyczne zachowanie — wąskie. Sama tabela uprawnień miesza te dwie rzeczy.

Pięć z dziesięciu może sięgać do plików na Twoim dysku

file:/// nie jest stroną internetową. To lokalny system plików pokazany w karcie przeglądarki — otwarty PDF, eksport HTML, pobrany rachunek.

Oficjalne odniesienie: Chrome match-pattern documentation.

Trzy rozszerzenia mówią o tym wprost. Dwa robią to bez wymieniania tego wprost: <all_urls> obejmuje schemat file:.

http://*/* i https://*/* nie obejmują file://; <all_urls> i *://*/* różnią się też w tym zakresie. Piątka tutaj to te rozszerzenia, których deklaracje sięgają do tego schematu jedną z tych dróg — nie jest to skutek wyłącznie wybranego wariantu wildcarda.

Chrome zabezpiecza to wszystko dodatkowym przełącznikiem „Allow access to file URLs” dla każdego rozszerzenia z osobna, domyślnie wyłączonym, więc deklaracja jest prośbą, a nie przyznaniem. Pięć z dziesięciu to uczciwa liczba, a dwa z tych pięciu w ogóle nie wpisują file:// nigdzie w manifeście: Axiom.ai i nasze.

Ten licznik uwzględnia także web_accessible_resources, nie tylko content scripts i uprawnienia hosta. Table Capture wymienia tam file://*/*; pominięcie tego bloku błędnie wrzuciłoby je do grupy rozszerzeń, których manifesty sięgają do plików bez nazywania schematu.

Uprawnienia, których nie widać, dopóki nie zostaną zażądane

optional_permissions są deklarowane z góry, ale żądane dopiero w czasie działania, więc nie pojawiają się w instalacyjnym komunikacie. Dwa rozszerzenia ich używają, a jedno z nich ma znaczenie.

userScripts nie jest aktywne, dopóki nie zostanie zażądane, i jest niewidoczne dla każdego, kto patrzy tylko na liczbę uprawnień.

Ma też bramkę, której nie mają pozostałe uprawnienia z tego audytu, a pominięcie tego zawyżałoby jego znaczenie. Samo zadeklarowanie userScripts nie wystarcza, by z niego korzystać: Chrome wymaga najpierw wyraźnej akcji użytkownika. Przed Chrome 138 był to Developer Mode, włączany globalnie pod chrome://extensions. Od Chrome 138 jest to przełącznik Allow User Scripts dla konkretnego rozszerzenia na jego stronie szczegółów, domyślnie wyłączony. W zwykłej instalacji możliwości są więc zadeklarowane, ale nieaktywne. Precyzyjne stwierdzenie jest warunkowe: Table Capture może udostępnić API userScripts po włączeniu przez użytkownika bramki Chrome. Ten audyt nie mierzył, jak często użytkownicy odwiedzają tę stronę ustawień lub włączają przełącznik.

Ani jedno, ani drugie nie jest ukryte; oba elementy są w manifeście. Tabela, która ignoruje blok opcjonalny, zaniża możliwości dwóch produktów.

Moment wstrzyknięcia, nie tylko zakres

Samo pytanie jak wstrzykiwany jest content script, też ma znaczenie. document_start to najwcześniejszy hak oferowany przez Chrome; all_frames obejmuje osadzenia zewnętrzne.

Wszystko w tym zestawie, co statycznie wstrzykuje się do wszystkich ramek, uporządkowane według deklarowanego czasu:

Table Capture i Listly używają najwcześniejszego haka przy szerokich wzorcach dopasowania. Axiom.ai i Clay for Chrome stosują ten sam timing, ale tylko na własnych domenach — ta sama agresywność, węższy cel.

Dla deklaracji statycznych <all_urls> plus all_frames to sufit szerokości dopasowania i właśnie tam siedzą Table Capture oraz Thunderbit. Różni je timing: Table Capture używa document_start, a statyczny content script Thunderbit działa przy document_end. Runtime API to osobna klasa możliwości i nie da się jej wywnioskować z tej tabeli.

Sama liczba uprawnień to kiepska statystyka podsumowująca. Table Capture deklaruje cztery uprawnienia — mniej niż większość tutaj — i wstrzykuje się przy document_start do wszystkich ramek na <all_urls>, a do tego userScripts po żądaniu.

Kto może pisać do rozszerzenia

externally_connectable określa, które strony internetowe lub inne rozszerzenia mogą wysyłać wiadomości bezpośrednio do skryptu tła rozszerzenia. Domyślne zachowanie jest nieintuicyjne.

Pominięcie tego klucza jest ustawieniem bardziej permissive. Domyślnie Chrome, gdy externally_connectable jest nieobecny, pozwala, by każde rozszerzenie mogło się połączyć, ale żadna strona internetowa już nie. Deklarowanie tego klucza służy więc do ograniczania.

W tym ujęciu tabela odwraca perspektywę:

Reguła Chrome ma dwa poziomy. Z dokumentacji manifestu:

Domyślne ustawienie permissive wynika z braku całego klucza. Gdy klucz już istnieje, oba pod-pola startują z pozycją zamkniętą, a podawanie wartości poszerza każdy kanał.

Axiom.ai deklaruje klucz tylko z matches. Jego ids są więc nieustawione, co oznacza, że żadne rozszerzenie nie może się z nim komunikować — kanał dla rozszerzeń jest zamknięty, nie pozostawiony otwarty. Otworzone zostało natomiast siedem originów WWW, z których tylko jeden należy do Axiom: dwa są nieprzypisywalnymi podmiotami trzecimi (*://*.tgwc.space/*, *://*.bitmachine.co.uk/*), a reszta to localhost, 0.0.0.0, host Google APIs i jedna duża platforma społecznościowa, którą Axiom nie obsługuje.

Hexomatic otwiera kanał dla rozszerzeń do ośmiu nazwanych identyfikatorów. Gdy klucz jest obecny, bazą jest zero rozszerzeń; wpisanie ośmiu rozszerza to do ośmiu. Jego sześć matches rozszerza drugi kanał z niczego, a dwa z nich to http://localhost:8000/* i http://localhost:3000/* po zwykłym HTTP — wszystko, co odpowiada na tych portach na komputerze użytkownika, znajduje się na allowliście.

Siedem z dziesięciu pomija ten klucz całkowicie, w tym nasze, i to one siedzą na domyślnym permissive dla komunikacji rozszerzenie-do-rozszerzenia. Dwa rozszerzenia zamykają ten kanał: Magical explicite przez ids: [], a Axiom.ai przez zadeklarowanie klucza bez wspominania ids. Magical jest jedynym, który zamyka oba.

To ostatnie zdanie jest właśnie powodem, dla którego trzeba czytać manifesty, a nie liczyć uprawnienia. To samo rozszerzenie może być szerokie na jednej osi i najbardziej restrykcyjne w całym zestawie na innej.

Oś, której nikt nie liczy: zakresy OAuth

Manifest może zawierać blok oauth2, a znajdujące się w nim zakresy to dostęp do Twoich kont u innych firm — inny rodzaj zasięgu niż wszystko powyżej i taki, którego żadna liczba uprawnień nie oddaje.

Oficjalne odniesienie: Google OAuth 2.0 scope list.

https://www.googleapis.com/auth/drive to ten szeroki wariant. Google oferuje węższy zakres drive.file, dający dostęp tylko do plików, które aplikacja sama utworzyła albo użytkownik wyraźnie wskaże; auth/drive oznacza możliwość przeglądania, edycji, tworzenia i usuwania w całym Dysku użytkownika. auth/spreadsheets ma taką samą konstrukcję dla każdego arkusza, do którego konto ma dostęp. Zarówno Axiom.ai, jak i Table Capture łączą zakres konta Google z dostępem do stron <all_urls>.

Dwa ograniczenia tego, co ta tabela dowodzi. Zakres jest żądany, a nie przyznany — Google pokazuje ekran zgody i użytkownik może odmówić, a rozszerzenie może nigdy nie wywołać API. Poza tym manifest widzi tylko OAuth realizowany przez przepływ identity w Chrome; rozszerzenie, które odsyła do strony logowania WWW, nie zadeklaruje tu nic. Siedem zer oznacza „nie zażądano w tym pliku”, a nie „brak dostępu do Twojego konta Google” — w tym także nasze, dlatego ta oś jest raportowana, a nie przedstawiana jako wąska.

Nasze własne rozszerzenie na tej samej skali

Thunderbit 4.6.4 przeszedł przez ten sam parser manifestów co pozostała dziewiątka. Pakiet ma 15.9 MiB po rozpakowaniu w 78 plikach.

Deklarowane zachowanie statyczne: <all_urls> pojawia się w uprawnieniach hosta i w dopasowaniach content scriptów. Statyczny skrypt działa w all_frames przy document_end. Ponieważ <all_urls> obejmuje file:, manifest może sięgać do lokalnych plików po włączeniu przez użytkownika przełącznika dostępu do plików w Chrome. Thunderbit pomija też externally_connectable, więc domyślne zachowanie Chrome pozwala na wiadomości od każdego rozszerzenia, ale nie od żadnej strony WWW.

Sufit możliwości w czasie działania: tablica permissions zawiera dziewięć ciągów: activeTab, commands, debugger, offscreen, scripting, sidePanel, storage, tabGroups i tabs. Chrome rozpoznaje osiem z nich jako uprawnienia; commands to klucz najwyższego poziomu manifestu i nie ma skutku jako wpis w tej tablicy. Thunderbit jest jedynym rozszerzeniem w zestawie, które deklaruje debugger, mogące podpiąć CDP do karty. Manifest udostępnia też scripting do rejestracji w czasie działania. Te API tworzą możliwości wykraczające poza statyczny wiersz document_end, ale odczyt manifestu nie pozwala stwierdzić, czy Thunderbit wywołuje konkretną metodę CDP albo rejestruje skrypt wcześniej w określonym momencie.

To rozróżnienie blokuje kilka kuszących, ale niepoprawnych porównań. Brak węższego cookies nie ogranicza tego, do czego może mieć dostęp kod z debugger. Brak clipboardRead nie jest dowodem, że dostęp do schowka jest niemożliwy. Z drugiej strony sama obecność debugger nie dowodzi, że te ścieżki są używane. Odpowiedź na którekolwiek z tych pytań wymaga analizy źródła lub śledzenia działania, a żadnego z nich tu nie wykonano.

W tym instrumencie Thunderbit jest szeroki pod względem statycznego dostępu do witryn, unikatowy w tym zestawie przez deklarację debugger i pozostaje na domyślnym poziomie Chrome dla komunikacji między rozszerzeniami. Nie da się tu ustalić jednego „najmocniejszego” rankingu, bo audyt nie dostarcza wspólnego modelu zagrożeń dla CDP, OAuth, userScripts, schowka i dostępu do hostów.

Powściągliwy projekt, którego nikt nie reklamuje

TexAu ma 0.3 MiB — najmniej z całej grupy, i to dwukrotnie — oraz wskazuje czternaście konkretnych witryn zamiast używać wildcarda: sieci społecznościowe, platformę dla developerów, platformy publikacyjne, produkt czatowy, dostawcę danych biznesowych i własną domenę. Jego content scripts pasują dokładnie do tych samych czternastu.

Po tym manifeście można od razu zobaczyć, gdzie rozszerzenie działa. To także ujawnienie produktu — lista celów mówi, do czego narzędzie służy, prościej niż marketing.

Cena jest realna: lista nazwanych domen nie zeskrobie strony, której na niej nie ma, a każdy nowy cel wymaga wydania. Ale „czternaście nazwanych domen” i „każdy istniejący URL” to dwie bardzo różne propozycje, a tylko jedna z nich jest czytelna.

Dwa produkty, które nie były tym, za co je podano

Rozszerzenie Captain Data nie jest publicznie dystrybuowane. Endpoint aktualizacji Google zwraca dla jego identyfikatora rozszerzenia HTTP 204 z pustym body — odpowiedź dla czegoś, czego sklep nie serwuje anonimowo. Strona listingu była natomiast serwowana anonimowo — HTTP 200, 509,829 bajtów. W tym przechwyceniu nie znaleziono wersji, daty ostatniej aktualizacji ani liczby instalacji; notatki skryptu mówią, że null w tym miejscu to słaby dowód, a żadnego ekranu logowania nie zaobserwowano. ID jest prawdziwe i first-party, więc najbardziej prawdopodobnym odczytem jest dystrybucja tylko przez link albo brak publicznego listing’u, ale nie dało się tego odróżnić od wycofania i nie będę zgadywać.

Dataflow Kit nie ma w ogóle rozszerzenia Chrome. Jego strona opisuje hostowaną aplikację webową z wyborem „point and click” oraz REST API. Mimo to została umieszczona na krótkiej liście rozszerzeń Chrome — tak właśnie zwykle powstają takie zestawienia.

Aktualność i zasięg, skoro oba są łatwe do sprawdzenia

Metadane sklepu dodają kontekst wyboru produktu wykraczający poza same uprawnienia. Te same pola zostały zebrane dla każdego rozszerzenia 2026-07-30.

Trzy produkty nie były wydane od ponad roku, a Hexomatic niemal od dwóch. W przypadku rozszerzeń ma to większe znaczenie niż w przypadku bibliotek: Chrome wydaje stabilną wersję mniej więcej co cztery tygodnie, a sama platforma rozszerzeń stale zmienia się pod spodem. userScripts zmienił swoją bramkę użytkownika w Chrome 138; rozszerzenie wydane ostatnio w 2024 roku było budowane według innych reguł niż te, które przeglądarka egzekwuje dziś.

Dwie rzeczy, którymi ta tabela nie jest. Liczby instalacji są grupowane przez Google — 1,000 / 3,000 / 7,000 / 10,000 / 100,000 / 200,000 — więc porównują rzędy wielkości i nic więcej, a kilka produktów reklamuje większe liczby we własnym marketingu. Świeża data to fakt o wydaniu, nie werdykt o jakości utrzymania ani ryzyku uprawnień.

Jeden użyteczny efekt uboczny: w każdym z dziesięciu analizowanych pakietów wersja ze sklepu zgadza się z wersją w manifeście. Pliki CRX, które ten audyt parsował, to te, które sklep udostępnia dziś, a nie stare kopie.

Świeżość wpływa na to, ile pracy kontrolnej zasługuje dany wybór; nie zmienia semantyki manifestu. Rozszerzenie o nazwanych domenach, aktualizowane rok temu, może nadal eksponować mniej powierzchni strony niż rozszerzenie wildcardowe wydane wczoraj. Nowszy pakiet może być jednak lepszym wyborem operacyjnym, jeśli szybko nadąża za zmianami Chrome. Dla shortlisty użyj daty w sklepie, by zdecydować, co przetestować ponownie, a manifestu — by zdecydować, co wymaga głębszego przeglądu możliwości. Nie zamieniaj tych dwóch kolumn w jedną ocenę.

Czego manifest nie mówi

Zadeklarowane uprawnienie to sufit, nie zachowanie. <all_urls> oznacza, że rozszerzenie może czytać każdą stronę. Nie oznacza, że to robi albo że cokolwiek opuszcza Twoje urządzenie. Ustalenie, co naprawdę się dzieje, wymaga obserwacji ruchu sieciowego w czasie działania — to inna praca, tutaj niewykonana, i nic powyżej nie powinno być czytane jako dowód nadużycia.

Powiązana analiza: Chrome extension testability experiment.

Jeszcze trzy granice:

• Chrome dużo z tego blokuje. Dostęp do plików jest domyślnie wyłączony; activeTab jest celowo wąskie; uprawnienia opcjonalne wymagają promptu w czasie działania; użytkownik widzi listę uprawnień podczas instalacji.
• Szerokie uprawnienia często są konieczne. Narzędzie, którego zadaniem jest „wyciągnąć tabelę z dowolnej strony, na której jesteś”, nie może działać z listy dozwolonych domen. Wąski zakres bywa czasem dyscypliną, a czasem po prostu mniejszym produktem.
• Jedna wersja, jeden dzień. Każda wartość pochodzi z pakietu udostępnionego 2026-07-29.

Istotne korekty w analizie

Opublikowane zliczenia używają trzech reguł, które łatwo błędnie zaimplementować przy szybkim parserze manifestów. Po pierwsze, <all_urls> obejmuje schemat file:, ale Chrome trzyma faktyczny dostęp do plików za przełącznikiem kontrolowanym przez użytkownika. Po drugie, web_accessible_resources.matches trzeba analizować razem z content scripts i uprawnieniami hosta; to tam Table Capture explicite wymienia file://*/*. Po trzecie, externally_connectable ma różne wartości domyślne w zależności od tego, czy cały klucz jest nieobecny, czy istnieje z pustym pod-polem. Tabele powyżej stosują te reguły konsekwentnie.

Suma uprawnień Thunderbit rozróżnia też surowe ciągi od rozpoznawanych uprawnień Chrome. Jego tablica ma dziewięć wpisów, ale commands należy na poziom główny, więc efektywna liczba użyta tutaj to osiem rozpoznanych uprawnień plus jeden nierozpoznany ciąg. Wreszcie statyczne deklaracje content_scripts nie są dowodem, że kod wywołuje scripting.registerContentScripts albo metodę CDP. Te możliwości pojawiają się wyłącznie przy runtime capability, nigdy jako zaobserwowane zachowanie. Surowe manifesty, hashe CRX i wynik parsera są śladem audytowym tych normalizacji, więc czytelnik nie musi ufać samemu opisowi.

Przy rzeczywistej decyzji instalacyjnej porównuj co najmniej cztery wymiary osobno: które strony są domyślnie w zakresie, jaka konkretna akcja użytkownika odblokowuje większy zasięg, które API przeglądarki lub konta stają się dostępne i którzy zewnętrzni wywołujący mogą pisać do rozszerzenia. Model activeTab w Agenty, bramka userScripts w Table Capture, zakres Drive w Axiom.ai i deklaracja debugger w Thunderbit nie są punktami na jednej liniowej skali. To różne odpowiedzi na różne pytania o zagrożenia.

Oto to porównanie zastosowane do czterech celowo różnych projektów:

Ta tabela nadal nie wyłania zwycięzcy. Wąski stały zakres stron w Agenty nic nie mówi o tym, co jego backend robi z przesłanymi danymi. Zakresy konta w Axiom.ai nie są porównywalne z rozszerzeniem czytającym bieżącą stronę. Deklaracja userScripts w Table Capture jest nieaktywna, dopóki użytkownik nie włączy osobnej bramki. debugger w Thunderbit ujawnia szeroką powierzchnię kontroli przeglądarki, ale manifest nie mówi, z których domen czy metod CDP korzysta kod. Każdy wiersz mówi, co sprawdzić dalej: ruch sieciowy w czasie działania, kod źródłowy, przepływ zgody albo ślady API przeglądarki.

To samo rozdzielenie ma znaczenie przy czytaniu instalacyjnego promptu Chrome. Surowa liczba uprawnień nie pokaże czasu, zasięgu ramek, zakresu OAuth, web_accessible_resources ani pominiętego klucza externally_connectable. Z drugiej strony szeroka deklaracja nie jest dowodem zbierania ani eksfiltracji. Użyteczny wynik audytu manifestu to priorytetyzowany plan testów runtime: zidentyfikuj powierzchnię danych, zanotuj bramkę użytkownika, a potem obserwuj, czy zadeklarowana ścieżka jest faktycznie wykorzystywana.

Jak czytać własny

Powiązana analiza: browser automation guide.

1. chrome://extensions → Details pokazuje przyznany dostęp do witryn i pozwala przełączyć go na on click dla wszystkiego, co nie wymaga stałego dostępu. To zawęża część dotyczącą dostępu do stron z powyższego obrazu. Nie dotyka komunikacji przychodzącej (externally_connectable i tak sięga do service worker’a), ani uprawnień na poziomie przeglądarki. Thunderbit debugger ma tu znaczenie. Dokumentacja bezpieczeństwa rozszerzeń Chrome mówi, że API debugger „w niektórych przypadkach może też ominąć inne typowe ograniczenia, takie jak uprawnienia hosta lub dostęp do plików”, więc ustawienie dostępu do witryn na „on click” nie ogranicza tego, do czego może sięgnąć. To ustawienie nie wpływa też na tabs, webNavigation, clipboardRead, downloads ani nic z optional_permissions.
2. W przypadku surowego pliku pakiet znajduje się w katalogu Chrome Extensions/<id>/<version>/. Trzeba odczytać sześć pól: permissions, optional_permissions, host_permissions, content_scripts (w tym matches, run_at i all_frames), externally_connectable — pamiętając, że nieobecny klucz jest permissive dla wywołujących rozszerzeń — oraz web_accessible_resources, którego matches mogą wymieniać schematy, których content scripts nigdy nie podają. Ostatnie pole Thunderbit ma dwa wpisy <all_urls>, ujawniające index.html i dwa dołączone skrypty każdemu originowi, z use_dynamic_url: false, co pozwala stronie sprawdzić, czy te stałe adresy rozszerzenia są osiągalne.
3. Sprawdź datę ostatniej aktualizacji listingu względem bieżącej wersji Chrome.

Ujawnienie i zasoby: ten artykuł publikuje Thunderbit, którego rozszerzenie jest ujęte w tej samej tabeli i przez ten sam parser. Nasz open-source scraper pillar obejmuje narzędzia niebędące rozszerzeniami.

Wypróbuj Thunderbit do ekstrakcji danych z sieci

Wersja krótka

Dziesięć rozszerzeń do scrapingu i automatyzacji, w tym nasze, zostało przeanalizowanych na podstawie ich własnych manifestów.

Agenty nie deklaruje dostępu do witryny ani content scripts, działa tylko na karcie, na którą patrzysz po kliknięciu, w 2.2 MiB. Axiom.ai deklaruje każdy adres URL HTTP i HTTPS w 37.1 MiB. Magical deklaruje trzynaście uprawnień, w tym clipboardRead — i jednocześnie jest jedynym rozszerzeniem tutaj, które całkowicie zamyka komunikację przychodzącą. Table Capture deklaruje tylko cztery uprawnienia i wstrzykuje się przy document_start do wszystkich ramek na <all_urls> — czyli do tego samego pułapu dopasowania, do którego dociera nasze, tylko wcześniej — plus userScripts po żądaniu. TexAu jest najmniejsze i wskazuje najwięcej celów — czternaście wzorców na trzynastu różnych właściwościach. Nie jest jedynym, który je nazywa: Clip to Clay deklaruje dwa (clay.com i jedną zewnętrzną witrynę), a Hexomatic i Clay for Chrome podają własne domeny. TexAu jako jedyne ma na liście głównie cudze witryny. Pięć z dziesięciu może sięgać do plików na Twoim dysku, a dwa z nich — Axiom.ai i nasze — nawet bez wpisywania file://.

Thunderbit, nasze, znajduje się po szerokiej stronie: <all_urls> zarówno dla dostępu do hostów, jak i statycznego wstrzykiwania, plus debugger, którego żadne inne rozszerzenie w tym zestawie nie deklaruje. Jest na domyślnym poziomie Chrome, który pozwala na wiadomości od każdego rozszerzenia, i sięga do file:// po włączeniu przez Chrome bramki dostępu do plików.

Deklaracja to sufit, nie zachowanie, i nic z tego nie dowodzi nadużycia. Ale jest to publiczne, darmowe do sprawdzenia i rozpiętość między oboma końcami jest większa niż cokolwiek na stronach produktowych.

Wypróbuj Thunderbit do ekstrakcji danych z sieci Get Started Free

FAQ

Czy szerokie uprawnienie oznacza, że rozszerzenie robi coś złego — i dlaczego samo liczenie uprawnień nie wystarcza? Nie, a samo liczenie pomija dwie rzeczy. <all_urls> oznacza, że rozszerzenie może czytać każdą odwiedzaną stronę; nie mówi nic o tym, co robi ani czy cokolwiek opuszcza Twoje urządzenie, a narzędzie zbudowane do wyciągania danych z dowolnej strony naprawdę nie może działać na liście nazwanych domen. Wniosek dotyczy rozpiętości, nie nadużycia — ustalenie faktycznego zachowania wymaga analizy ruchu w czasie działania, a tego audyt nie robił. Jeśli chodzi o liczenie: ustawienia wstrzykiwania nie są uprawnieniami, więc Table Capture deklaruje cztery, mimo że wstrzykuje się przy document_start, do all_frames, pasując do <all_urls>. A optional_permissions w ogóle nie pojawiają się w oknie instalacji — Table Capture może zażądać userScripts w czasie działania, co pozwala uruchamiać dowolne skrypty użytkownika w kontekstach stron, a Magical może zażądać webRequest.

Które z nich prosi o najmniej? Agenty: cztery uprawnienia, brak uprawnień hosta, brak content scripts. Opiera się na activeTab, które daje dostęp do bieżącej karty tylko po kliknięciu rozszerzenia i tylko do momentu przejścia dalej. Następny jest Hexomatic — dwa uprawnienia i content scripts ograniczone do własnych domen.

Jak rozszerzenie może sięgać do moich lokalnych plików bez deklarowania file://? Bo <all_urls> obejmuje schemat file:. Listly, Magical i Table Capture jawnie wymieniają wzorce file:// — Magical w content scripts, a Table Capture w web_accessible_resources. Axiom.ai i Thunderbit sięgają tam przez wildcard, nie wspominając o tym nigdzie. http://*/* i https://*/* nie obejmują file://. Chrome trzyma dostęp do plików wyłączony domyślnie za przełącznikiem dla każdego rozszerzenia, więc deklaracja jest prośbą, a nie przyznaniem.

Czym jest externally_connectable i dlaczego pominięcie go jest bardziej permissive? Określa originy WWW lub identyfikatory rozszerzeń, które mogą wysyłać wiadomości do skryptu tła rozszerzenia. Domyślne zachowanie Chrome, gdy klucz jest nieobecny, to że każde rozszerzenie może się połączyć, a żadna strona WWW nie może. Siedem z tych dziesięciu pomija go, w tym Thunderbit. Gdy klucz jest obecny, Hexomatic otwiera kanał dla rozszerzeń do ośmiu nazwanych ID; Axiom.ai otwiera siedem originów WWW, zostawiając kanał rozszerzeń zamknięty; Magical deklaruje puste listy dla obu, zamykając oba kanały.

Co deklaruje manifest Thunderbit? <all_urls> dla dostępu do hostów i statycznego wstrzykiwania content scripts, w all_frames przy document_end; 15.9 MiB w 78 plikach; oraz dziewięć ciągów w tablicy uprawnień. Osiem z nich to rozpoznane uprawnienia: activeTab, debugger, offscreen, scripting, sidePanel, storage, tabGroups i tabs. commands jest kluczem najwyższego poziomu manifestu i nie ma skutku jako wpis w tej tablicy. Żadne inne rozszerzenie w tym zestawie nie deklaruje debugger. Thunderbit sięga też do file:// przez <all_urls> po włączeniu bramki dostępu do plików w Chrome i pomija externally_connectable. Zachowanie w czasie działania nie było uruchamiane, więc audyt nie twierdzi, które metody CDP lub scriptingu rzeczywiście wywołuje rozszerzenie.