Kein Site-Zugriff oder jede URL: Die Verteilung der Berechtigungen über zehn Scraper-Erweiterungen

Jede Chrome-Erweiterung bringt eine manifest.json mit. Darin steht ein großer Teil dessen, was die Erweiterung auf Browser-Ebene darf: angeforderte APIs, Host-Patterns, statische Content Scripts, optionale Berechtigungen und erlaubte externe Verbindungen. Diese Datei liegt öffentlich im installierten Paket. Sie beweist nicht, welche der deklarierten Fähigkeiten der Laufzeitcode tatsächlich nutzt, was das Gerät verlässt oder welcher Kontozugriff über einen separaten Web-Login läuft.

Ich habe die zehn für dieses Audit ausgewählten Scraping- und Browser-Automation-Erweiterungen gelesen – darunter auch Thunderbit, also unsere eigene. Das Spektrum ist groß. Eine deklariert keinen dauerhaften Seitenzugriff. Eine andere nennt dreizehn Berechtigungen, darunter clipboardRead. Thunderbit ist die einzige Erweiterung in diesem Satz, die debugger deklariert – also eine breite CDP-Anbindungsfähigkeit mit einem anderen Risikoprofil als Seitenzugriff, OAuth oder vom Nutzer bereitgestellte Skripte.

Das ist keine Anschuldigung. Eine breite Berechtigung ist oft die ehrlichste Art, eine bestimmte Funktion umzusetzen, und eine schmale kann schlicht bedeuten, dass das Produkt weniger kann. Der Punkt ist: Der Unterschied ist enorm, er ist öffentlich dokumentiert, und in Vergleichstabellen taucht er trotzdem nie auf.

Vorgehensweise

Jede Erweiterung wurde als .crx direkt über Googles eigenen Update-Endpunkt heruntergeladen – also über dieselbe URL, die Chrome selbst nutzt – anschließend entpackt und ausgewertet. Es wurde keine Erweiterung installiert und kein Erweiterungscode ausgeführt. Es handelt sich um das Auslesen einer JSON-Datei.

Die Downloads wurden mit etwa einer Anfrage alle zwei Sekunden getaktet. Jede .crx, ihr SHA-256 und das extrahierte manifest.json liegen als Artefakte vor. Thunderbit lief über dasselbe Skript wie die anderen neun – nicht über einen Sonderweg – und wurde daher exakt gleich ausgewertet.

Die Analyse verwendet zwei Beweisarten und hält sie strikt getrennt:

• Deklariertes statisches Verhalten: Host-Patterns und content_scripts-Einträge, einschließlich matches, run_at und all_frames.
• Für Laufzeitcode verfügbare Fähigkeiten: APIs, die in permissions oder optional_permissions genannt werden. Diese Deklarationen zeigen, was Code anfordern oder aufrufen könnte – nicht, dass er es auch tut.

Es wird kein Rang als „mächtigste“ Erweiterung vergeben. debugger, userScripts, breiter Hostzugriff, OAuth-Scopes, Zwischenablagezugriff und externe Nachrichtenkanäle sind unterschiedliche Dinge mit unterschiedlichen Voraussetzungen. Ein Vergleich bräuchte ein Bedrohungsmodell, das dieses reine Manifest-Audit nicht liefert.

Die Größen unten sind entpackte Gesamtwerte in MiB (2²⁰ Bytes), summiert aus den ZIP-Einträgen.

Stand: 2026-07-29. Erweiterungen werden aktualisiert; vor einer Zitierung erneut prüfen.

Was zehn Manifeste deklarieren

Offizielle Referenz: Chrome's permission declaration guide.

Zwei weitere standen auf der Kandidatenliste und sind aus Gründen, die man separat berichten sollte, nicht in der Tabelle enthalten.

Die Spannweite ist eine Designentscheidung, kein Größeneffekt

Agenty deklariert keine Host-Berechtigungen und liefert überhaupt keine Content Scripts mit. Seine vier Berechtigungen sind activeTab, scripting, identity und identity.email. activeTab ist die enge Variante: Sie gewährt Zugriff auf den aktuellen Tab erst nach einem Klick auf die Erweiterung und nur, bis man die Seite verlässt. Nichts läuft auf Ihren Seiten, solange Sie es nicht auslösen. In 2,2 MiB.

Axiom.ai deklariert http://*/* und https://*/*, injiziert Content Scripts passend zu <all_urls> und entpackt auf 37,1 MiB über 232 Dateien – also das Siebzehnfache von Agenty, mit dauerhaftem Zugriff auf jede Seite, die Sie besuchen.

Hexomatic liegt bei Agenty: zwei Berechtigungen (storage, tabs), keine Host-Berechtigungen, Content Scripts nur auf die eigenen zwei Domains beschränkt.

Clay for Chrome ist eine dritte Form, die man getrennt betrachten sollte: Es deklariert *://*/* als Host-Berechtigung, injiziert Content Scripts aber nur auf der eigenen Domain. Die dauerhafte Fähigkeit ist breit, das automatische Verhalten ist schmal. Eine bloße Berechtigungstabelle wirft beides in einen Topf.

Fünf der zehn können auf Dateien auf Ihrer Festplatte zugreifen

file:/// ist keine Website. Es ist Ihr lokales Dateisystem, dargestellt in einem Browser-Tab – ein geöffnetes PDF, ein HTML-Export, eine heruntergeladene Rechnung.

Offizielle Referenz: Chrome match-pattern documentation.

Drei Erweiterungen sagen das ausdrücklich. Zwei erreichen es, ohne es zu benennen: <all_urls> umfasst das file:-Schema.

http://*/* und https://*/* decken file:// nicht ab; <all_urls> und *://*/* unterscheiden sich auch hier. Die fünf hier sind die Erweiterungen, deren Deklarationen das Schema auf die eine oder andere Weise erreichen – nicht wegen der Wildcard-Form, sondern trotz ihr.

Chrome schaltet das alles hinter einem pro-Erweiterung-Schalter „Zugriff auf Dateiu-URLs erlauben“, der standardmäßig aus ist. Die Deklaration ist also ein Antrag, keine Erlaubnis. Fünf von zehn ist die ehrliche Zahl, und zwei dieser fünf schreiben file:// nirgends in ihr Manifest: Axiom.ai und wir.

Diese Zählung berücksichtigt auch web_accessible_resources, nicht nur Content Scripts und Host-Berechtigungen. Table Capture nennt dort file://*/*; würde man diesen Block auslassen, würde es fälschlich bei den Erweiterungen landen, deren Manifeste Dateien erreichen, ohne das Schema zu benennen.

Berechtigungen, die man erst sieht, wenn sie angefordert werden

optional_permissions werden im Voraus deklariert, aber erst zur Laufzeit angefordert. Deshalb erscheinen sie nicht im Installations-Prompt. Zwei Erweiterungen verwenden sie, und eine davon ist relevant.

userScripts taucht erst nach Anforderung auf und ist für jeden unsichtbar, der nur eine bloße Berechtigungszahl liest.

Es hat außerdem eine Schranke, die die übrigen Berechtigungen dieses Audits nicht haben – und die man nicht unterschlagen darf. userScripts zu deklarieren reicht nicht, um es zu nutzen: Chrome verlangt zuerst eine ausdrückliche Nutzeraktion. Vor Chrome 138 war das der Developer Mode, global über chrome://extensions aktiviert. Ab Chrome 138 ist es ein pro-Erweiterung-Schalter Allow User Scripts auf der Detailseite der jeweiligen Erweiterung, standardmäßig aus. Für eine normale Installation ist die Fähigkeit also deklariert, aber inert. Die genaue Aussage ist bedingt: Table Capture kann die userScripts-API verfügbar machen, nachdem der Nutzer Chromes Schranke aktiviert hat. Dieses Audit hat nicht gemessen, wie oft Nutzer diese Einstellungsseite aufrufen oder den Schalter aktivieren.

Nichts davon ist versteckt; beides steht im Manifest. Eine Tabelle, die den optionalen Block ignoriert, unterschätzt zwei Produkte.

Nicht nur der Umfang zählt, sondern auch der Zeitpunkt der Injektion

Wie ein Content Script injiziert wird, wird oft übersehen und verändert das Bild. document_start ist der früheste Hook, den Chrome anbietet; all_frames erreicht auch eingebettete Inhalte von Drittanbietern.

Alles im Satz, das statisch in alle Frames injiziert, sortiert nach der deklarierten Zeit:

Table Capture und Listly nutzen den frühesten Hook über breite Match-Patterns. Axiom.ai und Clay for Chrome verwenden dieselbe Zeit auf ihren eigenen Domains – gleiche Aggressivität, aber engeres Ziel.

Bei statischen Deklarationen ist <all_urls> plus all_frames die obere Grenze der Match-Breite, und sowohl Table Capture als auch Thunderbit liegen dort. Der Unterschied im Timing ist relevant: Table Capture nutzt document_start; Thunderbits statisches Content Script nutzt document_end. Laufzeit-APIs sind eine separate Fähigkeitsklasse und lassen sich aus dieser Tabelle nicht ableiten.

Eine bloße Berechtigungszahl ist eine schlechte Zusammenfassungskennzahl. Table Capture deklariert vier Berechtigungen – weniger als die meisten hier – und injiziert auf <all_urls> in alle Frames bei document_start, plus userScripts auf Anfrage.

Wer der Erweiterung Nachrichten senden darf

externally_connectable steuert, welche Webseiten oder anderen Erweiterungen direkt an das Background Script einer Erweiterung Nachrichten senden dürfen. Der Standard ist kontraintuitiv.

Das Weglassen des Schlüssels ist die großzügige Einstellung. Wenn externally_connectable fehlt, gilt laut Chrome-Standard: Jede Erweiterung darf sich verbinden, aber keine Webseite. Eine Deklaration ist also die Art, wie man einschränkt.

So gelesen kehrt sich die Tabelle um:

Chromes Regel hat zwei Ebenen. Aus der Manifest-Referenz:

Die großzügige Standardregel hängt an der Abwesenheit des gesamten Schlüssels. Sobald der Schlüssel vorhanden ist, starten beide Unterfelder geschlossen, und benannte Werte öffnen den jeweiligen Kanal.

Axiom.ai deklariert den Schlüssel nur mit matches. Sein ids ist deshalb nicht gesetzt, was bedeutet: Keine Erweiterung kann ihm Nachrichten senden – der Erweiterungskanal ist geschlossen, nicht offen gelassen. Geöffnet wurden hingegen sieben Web-Ursprünge, von denen nur einer eine Axiom-Domain ist: zwei sind nicht zuordenbare Drittanbieter (*://*.tgwc.space/*, *://*.bitmachine.co.uk/*), der Rest sind localhost, 0.0.0.0, ein Google-APIs-Host und eine große soziale Plattform, die Axiom nicht betreibt.

Hexomatic öffnet seinen Erweiterungskanal für acht benannte IDs. Mit vorhandenem Schlüssel ist der Ausgangspunkt null Erweiterungen; acht Namen machen daraus acht. Seine sechs matches öffnen den anderen Kanal ausgehend von null, und zwei davon sind http://localhost:8000/* und http://localhost:3000/* über plain HTTP – also alles, was auf diesen Ports auf dem Rechner des Nutzers antwortet, liegt im Allowlist-Bereich.

Sieben der zehn lassen den Schlüssel ganz weg, einschließlich unserer, und genau diese sieben befinden sich beim Messaging von Erweiterung zu Erweiterung auf dem großzügigen Standard. Zwei Erweiterungen schließen diesen Kanal: Magical explizit mit ids: [] und Axiom.ai, indem es den Schlüssel deklariert, aber nie ids erwähnt. Magical ist die einzige, die beide Kanäle schließt.

Genau deshalb liest man Manifeste und zählt nicht einfach Berechtigungen. Dieselbe Erweiterung kann auf einer Achse sehr breit und auf einer anderen die strengste im Feld sein.

Die Achse, die niemand zählt: OAuth-Scans

Ein Manifest kann einen oauth2-Block enthalten, und die Scopes darin bedeuten Zugriff auf Konten bei anderen Unternehmen – eine andere Art von Reichweite als alles oben Genannte, und eine, die keine Berechtigungszählung abbildet.

Offizielle Referenz: Google OAuth 2.0 scope list.

https://www.googleapis.com/auth/drive ist die breite Variante. Google bietet einen engeren drive.file-Scope an, der nur Zugriff auf Dateien gewährt, die die App selbst erstellt oder die der Nutzer ausdrücklich auswählt; auth/drive erlaubt Sehen, Bearbeiten, Erstellen und Löschen über das gesamte Drive des Nutzers. auth/spreadsheets ist dieselbe Form für jede Tabellenkalkulation, die das Konto erreichen kann. Sowohl Axiom.ai als auch Table Capture koppeln einen Google-Konto-Scope mit <all_urls>-Seitenzugriff.

Zwei Grenzen dessen, was diese Tabelle beweist: Ein Scope wird angefordert, nicht gewährt – Google zeigt einen Zustimmungsdialog und der Nutzer kann ablehnen, und die Erweiterung ruft die API eventuell nie auf. Außerdem sieht das Manifest nur OAuth, das über Chromes identity-Flow läuft; eine Erweiterung, die Sie stattdessen auf eine Web-Login-Seite schickt, würde hier nichts deklarieren. Die sieben Nullen bedeuten „in dieser Datei nicht angefordert“, nicht „kein Zugriff auf Ihr Google-Konto“ – auch bei uns nicht, weshalb diese Achse berichtet und nicht als Enge behauptet wird.

Unsere eigene Erweiterung auf derselben Skala

Thunderbit 4.6.4 lief durch denselben Manifest-Parser wie die anderen neun. Das Paket ist entpackt 15,9 MiB groß und umfasst 78 Dateien.

Deklariertes statisches Verhalten: <all_urls> erscheint in Host-Berechtigungen und in den Content-Script-Matches. Das statische Script läuft in all_frames bei document_end. Weil <all_urls> file: einschließt, kann das Manifest lokale Dateien erreichen, nachdem der Nutzer Chromes Datei-Zugriffs-Schalter aktiviert hat. Thunderbit lässt außerdem externally_connectable weg, sodass Chromes Standard Nachrichten von jeder Erweiterung zulässt, aber von keiner Webseite.

Laufzeitfähigkeits-Grenze: Das permissions-Array enthält neun Strings: activeTab, commands, debugger, offscreen, scripting, sidePanel, storage, tabGroups und tabs. Chrome erkennt acht davon als Berechtigungen; commands ist ein Top-Level-Manifest-Schlüssel und hat als Eintrag in diesem Array keine Wirkung. Thunderbit ist die einzige Erweiterung im Satz, die debugger deklariert und damit CDP an einen Tab anbinden kann. Das Manifest macht außerdem scripting für die Laufzeitregistrierung verfügbar. Diese APIs schaffen Fähigkeiten über die statische document_end-Zeile hinaus, aber aus einem Manifest lässt sich nicht ableiten, ob Thunderbit eine bestimmte CDP-Methode aufruft oder ein Skript zu einem früheren Zeitpunkt registriert.

Diese Unterscheidung blockiert mehrere verlockende, aber falsche Vergleiche. Das Fehlen einer engeren cookies-Berechtigung begrenzt nicht, worauf Code mit debugger zugreifen könnte. Das Fehlen von clipboardRead beweist nicht, dass kein Zwischenablagezugriff möglich ist. Umgekehrt ist die Anwesenheit von debugger kein Beleg dafür, dass diese Wege genutzt werden. Für jede dieser Fragen bräuchte man Quellcode-Inspektion oder Laufzeit-Tracing – beides wurde hier nicht durchgeführt.

In diesem Instrument ist Thunderbit breit beim statischen Seitenzugriff, in diesem Satz einzigartig mit debugger und bei Chromes Standard für Erweiterungs-zu-Erweiterungs-Messaging. Es gibt kein einziges „stärkstes“ Ranking, weil dieses Audit kein gemeinsames Bedrohungsmodell über CDP, OAuth, userScripts, Zwischenablage und Hostzugriff hinweg liefert.

Das zurückhaltende Design, das niemand vermarktet

TexAu ist 0,3 MiB groß – hier der kleinste Kandidat um den Faktor zwei – und benennt vierzehn konkrete Sites statt eines Wildcards: soziale Netzwerke, eine Entwicklerplattform, Publishing-Plattformen, ein Chat-Produkt, einen Anbieter für Geschäftsdaten und die eigene Domain. Seine Content Scripts passen exakt auf dieselben vierzehn Ziele.

Man kann dieses Manifest lesen und genau wissen, wo die Erweiterung aktiv ist. Es ist auch eine Produktoffenlegung – die Zielliste sagt klarer, wofür das Tool da ist, als es das Marketing tut.

Der Kompromiss ist real: Eine benannte Liste kann keine Site abdecken, die nicht darauf steht, und jedes neue Ziel braucht einen Release. Aber „vierzehn benannte Domains“ und „jede URL, die existiert“ sind sehr unterschiedliche Versprechen – und nur eines davon ist nachvollziehbar.

Zwei Produkte, die nicht das waren, was die Liste sagte

Die Erweiterung von Captain Data wird nicht öffentlich verteilt. Googles Update-Endpunkt liefert für ihre Erweiterungs-ID HTTP 204 mit leerem Body – also die Antwort für etwas, das der Store nicht anonym ausliefert. Die Listing-Seite dagegen wurde anonym ausgeliefert: HTTP 200, 509.829 Bytes. Was die Erfassung dort nicht finden konnte, waren eine Versionsnummer, ein Datum der letzten Aktualisierung oder eine Installationszahl; in den Notizen des Skripts steht selbst, dass ein Nullwert dort schwache Evidenz ist, und eine Login-Sperre wurde nicht beobachtet. Die ID ist real und stammt vom Anbieter, daher ist eine rein verlinkte oder nicht gelistete Verteilung die naheliegendste Lesart, aber ich konnte das nicht sicher von einer Delistung unterscheiden und spekuliere nicht.

Dataflow Kit hat überhaupt keine Chrome-Erweiterung. Die Website beschreibt eine gehostete Web-App mit Point-and-Click-Auswahl und einer REST API. Sie war trotzdem auf einer Shortlist für Chrome-Erweiterungen gelandet – so entstehen solche Listen meist.

Aktualität und Reichweite, weil sich beides leicht prüfen lässt

Store-Metadaten liefern Kontext für die Produktauswahl über Berechtigungen hinaus. Dieselben Felder wurden für jede Erweiterung am 2026-07-30 erfasst.

Drei Produkte wurden seit über einem Jahr nicht mehr veröffentlicht, Hexomatic seit fast zwei. Bei Erweiterungen ist das wichtiger als bei Bibliotheken: Chrome bringt etwa alle vier Wochen eine stabile Version heraus, und die Plattform selbst verändert sich ständig darunter. userScripts hat seine Nutzer-Schranke in Chrome 138 verschoben; eine Erweiterung, die zuletzt 2024 erschienen ist, wurde gegen eine andere Regelbasis gebaut als der Browser, der sie heute erzwingt.

Zwei Dinge ist diese Tabelle nicht: Installationszahlen sind von Google gebucketet – 1.000 / 3.000 / 7.000 / 10.000 / 100.000 / 200.000 – vergleichen also nur Größenordnungen, und manche Produkte werben in ihrem Marketing mit größeren Zahlen. Ein aktuelles Datum ist eine Tatsache über den Release, kein Urteil über Wartungsqualität oder Berechtigungsrisiko.

Ein nützlicher Nebeneffekt: Die Store-Version entspricht in allen zehn analysierten Paketen der Manifest-Version. Die hier geparsten CRX-Dateien sind also die, die der Store heute ausliefert – keine veralteten Kopien.

Aktualität verändert, wie viel Nacharbeit eine Auswahl verdient; sie ändert nicht die Bedeutung des Manifests. Eine Erweiterung mit benannten Domains, die vor einem Jahr zuletzt aktualisiert wurde, kann immer noch weniger Seitenfläche freigeben als eine Wildcard-Erweiterung von gestern. Das neuere Paket kann betrieblich trotzdem die bessere Wahl sein, wenn es Chrome-Änderungen schnell nachzieht. Für eine Shortlist nimmt man das Store-Datum, um zu entscheiden, was man erneut testen sollte, und das Manifest, um zu entscheiden, was eine genauere Fähigkeitsprüfung braucht. Aus den zwei Spalten wird kein einziger Score.

Was ein Manifest nicht verrät

Eine deklarierte Berechtigung ist eine Obergrenze, kein Verhalten. <all_urls> bedeutet, dass eine Erweiterung jede Seite lesen darf. Es bedeutet nicht, dass sie es tut oder dass etwas das Gerät verlässt. Was tatsächlich passiert, lässt sich nur durch Beobachtung des Netzwerkverkehrs zur Laufzeit belegen – eine andere Aufgabe, die hier nicht durchgeführt wurde. Nichts oben sollte als Hinweis auf Missbrauch gelesen werden.

Verwandte Analyse: Chrome extension testability experiment.

Drei weitere Grenzen:

• Chrome begrenzt vieles davon. Dateizugriff ist standardmäßig aus; activeTab ist bewusst eng; optionale Berechtigungen brauchen einen Laufzeit-Prompt; beim Installieren sehen Nutzer eine Berechtigungsliste.
• Breite Berechtigungen sind oft notwendig. Ein Tool, dessen Aufgabe lautet „eine Tabelle von jeder geöffneten Seite extrahieren“, kann nicht nur mit einer Allowlist benannter Domains arbeiten. Enge Reichweite ist manchmal Disziplin – und manchmal einfach ein kleineres Produkt.
• Eine Version, ein Tag. Alle Werte stammen aus dem Paket, das am 2026-07-29 ausgeliefert wurde.

Wichtige Korrekturen in der Analyse

Die veröffentlichten Zählungen verwenden drei Regeln, die man bei einem schnellen Manifest-Parser leicht falsch macht. Erstens: <all_urls> enthält das file:-Schema, aber Chrome hält den tatsächlichen Dateizugriff hinter einem vom Nutzer steuerbaren Schalter. Zweitens: web_accessible_resources.matches muss zusammen mit Content Scripts und Host-Berechtigungen geprüft werden; dort nennt Table Capture ausdrücklich file://*/*. Drittens: externally_connectable hat je nach Vorhandensein des gesamten Schlüssels oder eines leeren Unterfelds unterschiedliche Standardwerte. Die Tabellen oben wenden diese Regeln konsistent an.

Auch Thunderbits Berechtigungszahl unterscheidet zwischen Rohstrings und von Chrome erkannten Berechtigungen. Das Array enthält neun Einträge, aber commands gehört auf die oberste Ebene, daher ist die hier verwendete effektive Zahl acht erkannte Berechtigungen plus ein nicht erkannter String. Schließlich sind statische content_scripts-Deklarationen kein Beleg dafür, dass Code scripting.registerContentScripts oder eine CDP-Methode aufruft. Solche Möglichkeiten erscheinen nur unter Laufzeitfähigkeiten, niemals als beobachtetes Verhalten. Roh-Manifeste, CRX-Hashes und Parser-Ausgaben sollten in einem Anhang zur Veröffentlichung verlinkt werden, damit Leser diese Normalisierungen prüfen können, ohne dem Text blind zu vertrauen.

Für eine echte Installationsentscheidung sollte man mindestens vier Dimensionen getrennt vergleichen: Welche Seiten sind standardmäßig im Umfang? Welche explizite Nutzeraktion schaltet mehr Reichweite frei? Welche Browser- oder Konto-APIs werden verfügbar? Und welche externen Aufrufer dürfen der Erweiterung Nachrichten senden? Agentrys activeTab-Modell, Table Captures geschütztes userScripts, Axiom.ais Drive-Scopes und Thunderbits debugger-Deklaration sind keine Punkte auf einer linearen Skala. Es sind unterschiedliche Antworten auf unterschiedliche Bedrohungsfragen.

Hier ist dieser Vergleich auf vier bewusst unterschiedliche Designs angewandt:

Auch diese Tabelle erzeugt keinen Gewinner. Agentrys schmaler dauerhafter Seitenzugriff sagt nichts darüber aus, was sein Backend mit übermittelten Daten macht. Axiom.ais Kontoscopes sind nicht mit einer Erweiterung vergleichbar, die die aktuelle Seite liest. Table Captures userScripts-Deklaration ist inert, bis der Nutzer die separate Schranke aktiviert. Thunderbits debugger-Berechtigung öffnet eine breite Browser-Kontrollfläche, aber das Manifest verrät nicht, welche CDP-Domains oder Methoden der Code aufruft. Jede Zeile sagt nur, was man als Nächstes prüfen sollte: Laufzeit-Netzwerkverkehr, Quellcode, Consent-Flow oder Browser-API-Traces.

Dasselbe Trennen ist wichtig, wenn man den Chrome-Installationsdialog liest. Eine bloße Berechtigungszahl kann Timing, Frame-Reichweite, OAuth-Scopes, web_accessible_resources oder einen weggelassenen externally_connectable-Schlüssel nicht zeigen. Umgekehrt ist eine breite Deklaration kein Beweis für Sammlung oder Exfiltration. Das sinnvolle Ergebnis eines Manifest-Audits ist ein priorisierter Plan für Laufzeittests: Datensurface identifizieren, Nutzer-Schranke notieren, dann beobachten, ob der deklarierte Pfad tatsächlich genutzt wird.

Wie man das eigene liest

Verwandte Anleitung: browser automation guide.

1. chrome://extensions → Details zeigt gewährten Site-Zugriff und erlaubt es, ihn für alles, was keinen dauerhaften Zugriff braucht, auf on click zu setzen. Das verkleinert den Seitenzugriffs-Teil dessen, was oben steht. Es berührt nicht eingehende Nachrichten (externally_connectable erreicht den Service Worker trotzdem) und auch keine Browser-Ebene-Berechtigungen. Thunderbits debugger-Deklaration ist hier wichtig. Die eigene Sicherheitsdokumentation von Chromium zu Erweiterungen sagt, die Debugger-API könne „in some cases also sidestep other typical restrictions, such as host permissions or file access“, sodass „on click“ den Site-Zugriff nicht begrenzt, den sie erreichen kann. Der Schalter berührt auch nicht tabs, webNavigation, clipboardRead, downloads oder irgendetwas in optional_permissions.
2. Für die Rohdatei liegt das Paket im Verzeichnis Extensions/<id>/<version>/ unter Chrome. Lesen Sie sechs Felder: permissions, optional_permissions, host_permissions, content_scripts (die matches, run_at und all_frames darin), externally_connectable – wobei ein abwesender Schlüssel für Erweiterungsaufrufer großzügig ist – und web_accessible_resources, dessen matches Schemen nennen können, die die Content Scripts nie nennen. Thunderbits letztes Feld hat zwei <all_urls>-Einträge, die index.html und zwei gebündelte Skripte für jeden Ursprung freigeben, mit use_dynamic_url: false, sodass eine Seite testen kann, ob diese stabilen Erweiterungs-URLs aufgelöst werden.
3. Prüfen Sie das Datum der letzten Aktualisierung des Store-Eintrags gegen die aktuelle Chrome-Version.

Offenlegung und Ressourcen: Dieser Artikel wird von Thunderbit veröffentlicht, dessen Erweiterung in derselben Tabelle und demselben Parser enthalten ist. Unser open-source scraper pillar behandelt nicht-erweiterungsbasierte Tools.

Thunderbit für Web-Datenextraktion testen

Kurzfassung

Zehn Scraping- und Automations-Erweiterungen, uns eingeschlossen, wurden anhand ihrer eigenen Manifeste gelesen.

Agenty deklariert keinen Site-Zugriff und keine Content Scripts, arbeitet nur auf dem Tab, den Sie beim Klick geöffnet haben, und ist 2,2 MiB groß. Axiom.ai deklariert jede HTTP- und HTTPS-URL und umfasst 37,1 MiB. Magical deklariert dreizehn Berechtigungen, darunter clipboardRead – und ist zugleich die einzige Erweiterung hier, die eingehende Nachrichten vollständig schließt. Table Capture deklariert nur vier Berechtigungen und injiziert bei document_start in alle Frames auf <all_urls> – also auf derselben Match-Obergrenze, die auch wir erreichen, nur früher – plus userScripts auf Anfrage. TexAu ist der kleinste Kandidat und benennt die meisten Ziele – vierzehn Muster über dreizehn unterschiedliche Eigenschaften. Es ist nicht der einzige, der Ziele benennt: Clip to Clay deklariert zwei (clay.com und eine Drittanbieter-Seite), und Hexomatic sowie Clay for Chrome benennen ihre eigenen Domains. TexAu ist der einzige, dessen benannte Liste überwiegend aus fremden Sites besteht. Fünf der zehn können auf Dateien auf Ihrer Festplatte zugreifen, zwei davon – Axiom.ai und wir – ohne file:// jemals zu schreiben.

Thunderbit, also wir, liegt am breiten Ende: <all_urls> sowohl für Hostzugriff als auch für statische Injektion, plus debugger, den keine andere Erweiterung in diesem Satz deklariert. Es liegt bei Chromes Standard, der Nachrichten von jeder Erweiterung erlaubt, und erreicht file://, nachdem Chromes Nutzer-Schranke aktiviert wurde.

Eine Deklaration ist eine Obergrenze, kein Verhalten, und nichts davon belegt Missbrauch. Aber es ist veröffentlicht, kostenlos überprüfbar, und die Spannweite zwischen den beiden Enden ist größer als alles, was auf den Produktseiten steht.

Thunderbit für Web-Datenextraktion testen Get Started Free

FAQs

Bedeutet eine breite Berechtigung, dass die Erweiterung etwas Falsches tut – und warum reicht das Zählen von Berechtigungen nicht aus? Nein. Und das Zählen übersieht zwei Dinge. <all_urls> bedeutet, dass eine Erweiterung jede besuchte Seite lesen darf; es sagt nichts darüber aus, was sie tatsächlich tut oder ob etwas Ihr Gerät verlässt. Und ein Tool, das Daten von jeder Seite extrahieren soll, kann nicht seriös mit einer Liste benannter Domains arbeiten. Das Ergebnis hier ist die Spannweite, nicht Fehlverhalten – das tatsächliche Verhalten müsste man mit Laufzeitverkehr analysieren, was dieses Audit nicht getan hat. Zum Zählen: Injektions-Einstellungen sind keine Berechtigungen, also deklariert Table Capture vier, injiziert aber bei document_start in all_frames passend zu <all_urls>. Und optional_permissions erscheinen gar nicht im Installationsdialog – Table Capture kann userScripts zur Laufzeit anfordern, womit beliebige Nutzerskripte im Seitenkontext laufen dürfen, und Magical kann webRequest anfordern.

Welche davon verlangt am wenigsten? Agenty: vier Berechtigungen, keine Host-Berechtigungen, keine Content Scripts. Es verlässt sich auf activeTab, das Zugriff auf den aktuellen Tab nur nach einem Klick auf die Erweiterung und nur bis zum Verlassen der Seite gewährt. Hexomatic folgt danach, mit zwei Berechtigungen und Content Scripts, die auf die eigenen Domains beschränkt sind.

Wie kann eine Erweiterung auf meine lokalen Dateien zugreifen, ohne file:// zu deklarieren? Weil <all_urls> das file:-Schema einschließt. Listly, Magical und Table Capture nennen file://-Muster ausdrücklich – Magical in seinen Content Scripts und Table Capture in web_accessible_resources. Axiom.ai und Thunderbit erreichen es über das Wildcard, ohne es irgendwo zu nennen. http://*/* und https://*/* decken file:// nicht ab. Chrome hält Dateizugriff standardmäßig aus hinter einem pro-Erweiterung-Schalter, also ist die Deklaration ein Antrag und keine Gewährung.

Was ist externally_connectable, und warum ist das Weglassen die großzügige Variante? Es nennt die Web-Ursprünge oder Erweiterungs-IDs, die an das Background Script einer Erweiterung Nachrichten senden dürfen. Chromes Standard, wenn der Schlüssel fehlt, ist: Jede Erweiterung darf verbinden, keine Webseite darf es. Sieben der zehn lassen ihn weg, einschließlich Thunderbit. Ist der Schlüssel vorhanden, öffnet Hexomatic den Erweiterungskanal für acht benannte IDs; Axiom.ai öffnet sieben Web-Ursprünge und lässt den Erweiterungskanal geschlossen; Magical deklariert leere Listen für beide und schließt beide Kanäle.

Was deklariert Thunderbits eigenes Manifest? <all_urls> für Hostzugriff und statische Content-Script-Injektion, in all_frames bei document_end; 15,9 MiB über 78 Dateien; und neun Strings im Berechtigungs-Array. Acht sind erkannte Berechtigungen: activeTab, debugger, offscreen, scripting, sidePanel, storage, tabGroups und tabs. commands ist ein Top-Level-Manifest-Schlüssel und hat in diesem Array keine Wirkung. Keine andere Erweiterung in diesem Satz deklariert debugger. Thunderbit erreicht file:// außerdem über <all_urls>, nachdem Chromes Datei-Zugriffs-Schranke aktiviert wurde, und lässt externally_connectable weg. Laufzeitverhalten wurde nicht ausgeführt, daher behauptet das Audit nicht, welche CDP- oder Scripting-Methoden die Erweiterung tatsächlich aufruft.