Was zehn Chrome-Erweiterungen in ihren Manifests wirklich preisgeben

Jede Chrome-Erweiterung bringt eine manifest.json mit. Darin steckt ein großer Teil dessen, was sie auf Browser-Ebene grundsätzlich darf: angeforderte APIs, Host-Muster, statische Content Scripts, optionale Berechtigungen und erlaubte externe Verbindungen. Diese Datei liegt offen im Paket, das du installierst. Sie beweist nicht, welche der deklarierten Fähigkeiten zur Laufzeit tatsächlich genutzt werden, was das Gerät verlässt oder welche Kontozugriffe über einen separaten Web-Login laufen.

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

Das ist kein Vorwurf. Eine weit gefasste Berechtigung ist oft der ehrlichste Weg, ein bestimmtes Feature umzusetzen, und eine enge kann schlicht bedeuten, dass das Produkt weniger kann. Entscheidend ist: Der Unterschied ist enorm, öffentlich einsehbar und taucht in keiner Vergleichstabelle auf.

So wurde analysiert

Jede Erweiterung wurde als .crx direkt über Googles eigenen Update-Endpunkt geladen – also über genau die URL, die auch Chrome selbst verwendet – und anschließend entpackt und ausgewertet. Es wurde keine Erweiterung installiert und kein Erweiterungscode ausgeführt. Es handelt sich um eine Auswertung einer JSON-Datei.

Die Downloads liefen gedrosselt, etwa ein Request alle zwei Sekunden. Jede .crx, ihr SHA-256-Wert und das extrahierte manifest.json wurden als Artefakte gesichert. Thunderbit lief durch exakt dasselbe Skript wie die anderen neun Erweiterungen, nicht über einen Sonderweg, daher ist seine Zeile auf identische Weise abgeleitet.

Die Analyse arbeitet mit zwei getrennten Beweisklassen:

• Deklariertes statisches Verhalten: Host-Muster und content_scripts-Einträge, einschließlich matches, run_at und all_frames.
• Zur Laufzeit verfügbare Fähigkeit: APIs, die in permissions oder optional_permissions genannt sind. Diese Angaben zeigen, was der Code anfordern oder aufrufen könnte – nicht, dass er es tatsächlich tut.

Es wird kein ordinaler Score wie „am mächtigsten“ vergeben. debugger, userScripts, breiter Host-Zugriff, OAuth-Scopes, Clipboard-Zugriff und externe Nachrichtenkanäle betreffen unterschiedliche Daten und setzen unterschiedliche Voraussetzungen voraus. Für einen Vergleich wäre ein Threat Model nötig, das dieses Manifest-only-Audit nicht liefert.

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

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

Was zehn Manifests deklarieren

Offizielle Referenz: Chromes Anleitung zur Berechtigungsdeklaration.

Zwei weitere standen ebenfalls auf der Kandidatenliste und tauchen aus Gründen nicht in der Tabelle auf, die man separat erwähnen sollte.

Die Streuung ist eine Designentscheidung, kein Nebeneffekt der Größe

Agenty deklariert keine Host-Berechtigungen und bringt gar keine Content Scripts mit. Die vier Berechtigungen sind activeTab, scripting, identity und identity.email. activeTab ist die engste davon: Es gewährt Zugriff auf den aktuellen Tab erst nachdem du auf die Erweiterung geklickt hast – und auch nur, bis du weiter navigierst. Ohne deinen Aufruf läuft nichts auf deinen Seiten. Bei 2.2 MiB.

Axiom.ai deklariert http://*/* und https://*/*, injiziert Content Scripts, die zu <all_urls> passen, und entpackt auf 37.1 MiB in 232 Dateien – also das 17-Fache von Agenty, bei dauerhaftem Zugriff auf jede von dir besuchte Seite.

Hexomatic liegt eher bei Agenty: zwei Berechtigungen (storage, tabs), keine Host-Berechtigungen, Content Scripts nur auf die beiden eigenen 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 eng. Eine bloße Berechtigungstabelle vermischt beides.

Fünf von zehn können auf Dateien auf deinem Laufwerk zugreifen

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

Offizielle Referenz: Chrome-Dokumentation zu Match Patterns.

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

http://*/* und https://*/* decken file:// nicht ab; <all_urls> und *://*/* unterscheiden sich auch hier. Die fünf hier sind diejenigen, deren Deklarationen das Schema auf die eine oder andere Weise erreichen – nicht weil sie zufällig den einen oder anderen Wildcard-Typ gewählt haben.

Chrome setzt das alles hinter einen pro Erweiterung aktivierbaren Schalter „Zugriff auf Date-URLs erlauben“, der standardmäßig aus ist. Die Deklaration ist also eine Anfrage, keine automatische Freigabe. Fünf von zehn ist die ehrliche Zahl, und zwei dieser fünf schreiben file:// überhaupt nicht ins 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 ignorieren, würde die Erweiterung fälschlich bei den Tools landen, deren Manifests Dateien erreichen, ohne das Schema zu nennen.

Berechtigungen, die man erst sieht, wenn sie angefordert werden

optional_permissions werden zwar im Voraus deklariert, aber erst zur Laufzeit angefordert. Deshalb erscheinen sie nicht im Installationsdialog. Zwei Erweiterungen nutzen sie, und eine davon ist relevant.

userScripts ist bis zur Anforderung unsichtbar und für jeden, der nur Berechtigungszahlen liest, nicht erkennbar.

Außerdem hat es eine zusätzliche Hürde, die die übrigen Berechtigungen in diesem Audit nicht haben. Nur es wegzulassen würde die Reichweite überzeichnen. userScripts zu deklarieren reicht nicht aus, um es zu verwenden: Chrome verlangt zuerst eine explizite Nutzeraktion. Vor Chrome 138 war das der Developer Mode, der global unter chrome://extensions aktiviert wurde. Ab Chrome 138 ist es ein pro Erweiterung geschalteter Schalter Allow User Scripts auf der Detailseite der Erweiterung, standardmäßig aus. Für eine gewöhnliche Installation ist die Fähigkeit also deklariert, aber inaktiv. Die präzise Aussage ist bedingt: Table Capture kann die userScripts-API verfügbar machen, nachdem der Nutzer Chromes Gate aktiviert hat. Dieses Audit hat nicht gemessen, wie oft Nutzer diese Einstellungsseite aufrufen oder den Schalter einschalten.

Weder das eine noch das andere ist verborgen; beides steht im Manifest. Eine Tabelle, die den optionalen Block ignoriert, unterschätzt zwei Produkte.

Einfügezeitpunkt, nicht nur Umfang

Nicht nur wie weit ein Content Script reicht, sondern wann es injiziert wird, verändert das Bild. document_start ist der früheste Hook, den Chrome anbietet; all_frames erreicht eingebettete Drittinhalte.

Alles im Set, das statisch in alle Frames injiziert, sortiert nach deklarierter Zeit:

Table Capture und Listly nutzen den frühesten Hook über breite Match-Muster hinweg. Axiom.ai und Clay for Chrome verwenden dasselbe Timing, aber nur auf ihren eigenen Domains – gleiche Aggressivität, aber enger Zielbereich.

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

Eine einfache Berechtigungszahl ist eine schlechte Kennzahl. Table Capture deklariert vier Berechtigungen – weniger als die meisten hier – und injiziert trotzdem mit document_start in alle Frames auf <all_urls>, plus userScripts auf Anfrage.

Wer der Erweiterung schreiben 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. Laut Chrome ist beim Fehlen von externally_connectable standardmäßig jede Erweiterung verbindungsberechtigt, aber keine Webseite. Das Deklarieren des Schlüssels ist also die Art, wie man einschränkt.

So gelesen kippt die Tabelle:

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

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

Axiom.ai deklariert den Schlüssel nur mit matches. Sein ids ist also nicht gesetzt; das bedeutet, dass keine Erweiterung Nachrichten senden kann – der Erweiterungskanal ist geschlossen, nicht offen gelassen. Geöffnet hat es sieben Web-Ursprünge, von denen nur einer eine Axiom-Domain ist: Zwei sind nicht zurechenbare Drittparteien (*://*.tgwc.space/*, *://*.bitmachine.co.uk/*), die übrigen sind localhost, 0.0.0.0, ein Google-APIs-Host und eine große Social-Plattform, die es nicht betreibt.

Hexomatic öffnet seinen Erweiterungskanal für acht benannte IDs. Mit vorhandenem Schlüssel ist der Ausgangspunkt null Erweiterungen; acht Namen heben das auf acht. Die sechs matches öffnen den anderen Kanal von null aus, und zwei davon sind http://localhost:8000/* und http://localhost:3000/* über unverschlüsseltes HTTP – alles, was auf diesen Ports auf dem Rechner des Nutzers antwortet, liegt innerhalb der Allowlist.

Sieben der zehn lassen den Schlüssel ganz weg, inklusive uns, und genau diese sieben liegen beim großzügigen Standard für Erweiterungs-zu-Erweiterungs-Nachrichten. Zwei Erweiterungen schließen diesen Kanal: Magical explizit mit ids: [] und Axiom.ai, indem es den Schlüssel deklariert und ids nie erwähnt. Magical ist die einzige, die beide Kanäle schließt.

Diese letzte Zeile ist der Grund, Manifests zu lesen statt nur Berechtigungen zu zählen. Dieselbe Erweiterung kann auf einer Achse sehr breit und auf einer anderen die strengste im Set sein.

Die Achse, die niemand mitzählt: OAuth-Scopes

Ein Manifest kann einen oauth2-Block enthalten, und die darin genannten Scopes bedeuten Zugriff auf deine Konten bei anderen Unternehmen – eine andere Form von Reichweite als alles oben Genannte, und etwas, das keine Berechtigungszahl abbildet.

Offizielle Referenz: Google-OAuth-2.0-Scopes.

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

Diese Tabelle zeigt allerdings nur zwei Grenzen. Ein Scope ist angefordert, nicht automatisch gewährt – Google zeigt einen Zustimmungsbildschirm, den der Nutzer ablehnen kann, und die Erweiterung muss die API möglicherweise nie aufrufen. Und das Manifest sieht nur OAuth über Chromes identity-Flow; eine Erweiterung, die dich stattdessen zu einer Web-Login-Seite schickt, würde hier nichts deklariert haben. Die sieben Nullen bedeuten „in dieser Datei nicht angefordert“, nicht „kein Zugriff auf dein Google-Konto“ – auch bei uns. Deshalb wird diese Achse berichtet und nicht als Beweis für Enge behauptet.

Unsere eigene Erweiterung auf derselben Skala

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

Deklariertes statisches Verhalten: <all_urls> erscheint sowohl in den Host-Berechtigungen als auch in den Content-Script-Matches. Das statische Script läuft in all_frames bei document_end. Da <all_urls> file: einschließt, kann das Manifest lokale Dateien erreichen, sobald du Chromes Dateizugriffs-Schalter aktiviert hast. Thunderbit lässt außerdem externally_connectable weg, sodass Chromes Standard Nachrichten von jeder Erweiterung erlaubt, aber nicht von Webseiten.

Laufzeit-Fähigkeitsobergrenze: 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 Manifest-Schlüssel auf oberster Ebene und hat als Eintrag in diesem Array keine Wirkung. Thunderbit ist die einzige Erweiterung in diesem Set, die debugger deklariert und damit CDP an einen Tab hängen 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 dem Manifest lässt sich nicht ableiten, ob Thunderbit eine bestimmte CDP-Methode oder ein Skript zu einem früheren Zeitpunkt tatsächlich registriert.

Diese Unterscheidung verhindert mehrere verlockende, aber falsche Vergleiche. Dass die engere cookies-Berechtigung fehlt, begrenzt nicht, worauf Code mit debugger zugreifen könnte. Dass clipboardRead fehlt, beweist nicht, dass ein Clipboard-Zugriff unmöglich wäre. Umgekehrt ist das Vorhandensein von debugger kein Beweis dafür, dass diese Wege verwendet werden. Für jede dieser Fragen wären Quellcode-Inspektion oder Runtime-Trace nötig, beides wurde hier nicht durchgeführt.

Auf diesem Prüfstand ist Thunderbit breit beim statischen Seitenzugriff, in diesem Set einzigartig durch debugger, und befindet sich beim Standard von Chrome für Erweiterungs-zu-Erweiterungs-Nachrichten. Es gibt kein einziges „stärkstes“ Ranking, weil dieses Audit kein gemeinsames Threat Model für CDP, OAuth, userScripts, Clipboard und Host-Zugriff liefert.

Das zurückhaltende Design, das niemand vermarktet

TexAu ist 0.3 MiB groß – also halb so groß wie der kleinste Kandidat hier – und nennt vierzehn konkrete Sites, statt einen Platzhalter zu verwenden: soziale Netzwerke, eine Entwicklerplattform, Publishing-Plattformen, ein Chat-Produkt, einen Business-Data-Anbieter und die eigene Domain. Seine Content Scripts passen genau auf dieselben vierzehn Ziele.

Aus diesem Manifest lässt sich sehr genau ablesen, wo die Erweiterung aktiv ist. Es ist zugleich Produkttransparenz – die Zielliste sagt nüchterner, wofür das Tool gedacht ist, als das Marketing es tut.

Der Kompromiss ist real: Eine benannte Liste kann keine Site scrapen, die nicht darauf steht, und jedes neue Ziel erfordert ein Release. Aber „vierzehn benannte Domains“ und „jede existierende URL“ sind zwei sehr unterschiedliche Aussagen – und nur eine davon ist lesbar.

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

Die Erweiterung von Captain Data ist nicht öffentlich verteilt. Googles Update-Endpunkt liefert für ihre Extension-ID HTTP 204 mit leerem Body – die Antwort für etwas, das der Store anonym nicht ausliefert. Die Store-Seite selbst wurde dagegen anonym ausgeliefert: HTTP 200, 509.829 Bytes. Was sich darin nicht finden ließ, waren eine Versionsangabe, ein Aktualisierungsdatum oder eine Installationszahl; die eigenen Notizen des Skripts sagen, dass ein Nullwert dort nur schwacher Beleg ist, und eine Login-Schranke war nicht zu sehen. Die ID ist echt und stammt vom Anbieter selbst, daher ist eine reine Link-Verteilung oder eine nicht gelistete Veröffentlichung die naheliegendste Lesart. Ich konnte das aber nicht von einer Delistung unterscheiden und werde nicht raten.

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.

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

Store-Metadaten liefern zusätzlich Kontext für die Produktauswahl über reine 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 Jahren. Bei Erweiterungen ist das relevanter als bei Bibliotheken: Chrome veröffentlicht ungefähr alle vier Wochen eine stabile Version, und die Erweiterungsplattform verändert sich darunter ständig. userScripts hat sein User-Gate in Chrome 138 verlagert; eine Erweiterung, die zuletzt 2024 veröffentlicht wurde, wurde gegen einen anderen Regelstand gebaut als der Browser heute erzwingt.

Zwei Dinge, die diese Tabelle nicht ist: Installationszahlen sind von Google in Buckets gestuft – 1.000 / 3.000 / 7.000 / 10.000 / 100.000 / 200.000 – daher vergleichen sie nur Größenordnungen, und mehrere Produkte bewerben in ihrem eigenen Marketing höhere Werte. Ein jüngeres Datum ist eine Tatsache zum Veröffentlichungsstand, 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 geprüften CRX-Dateien sind also die, die der Store heute ausliefert, keine veralteten Kopien.

Aktualität beeinflusst, wie viel Nachprüfung eine Auswahl verdient; sie ändert nicht die Semantik des Manifests. Eine Erweiterung mit benannten Domains, die vor einem Jahr zuletzt aktualisiert wurde, kann trotzdem weniger Seitenfläche offenlegen als eine Wildcard-Erweiterung von gestern. Das neuere Paket kann operativ trotzdem die bessere Wahl sein, wenn es Chrome-Änderungen schnell mitzieht. Für eine Shortlist gilt: Erst mit dem Store-Datum entscheiden, was erneut getestet werden sollte, dann mit dem Manifest entscheiden, was eine genauere Fähigkeitsprüfung braucht. Machen Sie aus den zwei Spalten keinen einzigen 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. Das heißt nicht, dass sie es tut oder dass überhaupt etwas dein Gerät verlässt. Was tatsächlich passiert, lässt sich nur durch Beobachtung des Netzwerkverkehrs zur Laufzeit feststellen – eine andere Aufgabe, die hier nicht durchgeführt wurde. Aus dem Obigen sollte nichts als Beleg für Missbrauch gelesen werden.

Verwandte Analyse: Experiment zur Testbarkeit von Chrome-Erweiterungen.

Drei weitere Grenzen:

• Chrome begrenzt vieles davon. Dateizugriff ist standardmäßig aus; activeTab ist absichtlich eng; optionale Berechtigungen brauchen einen Laufzeitdialog; Nutzer sehen bei der Installation eine Berechtigungsliste.
• Breite Berechtigungen sind oft notwendig. Ein Tool mit dem Job „eine Tabelle von jeder beliebigen Seite extrahieren“ kann nicht mit einer Allowlist benannter Domains funktionieren. Enge Reichweite ist manchmal Disziplin, 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 folgen drei Regeln, die man beim Schreiben eines schnellen Manifest-Parsers leicht falsch macht. Erstens: <all_urls> schließt das file:-Schema ein, aber Chrome hält den tatsächlichen Dateizugriff hinter einem vom Nutzer kontrollierbaren Schalter. Zweitens: web_accessible_resources.matches muss zusammen mit Content Scripts und Host-Berechtigungen geprüft werden; dort nennt Table Capture file://*/* ausdrücklich. Drittens: externally_connectable hat unterschiedliche Standardwerte, je nachdem, ob der gesamte Schlüssel fehlt oder ob der Schlüssel mit einem leeren Unterfeld vorhanden ist. Die Tabellen oben wenden diese Regeln konsistent an.

Auch bei Thunderbits Berechtigungszahl wird zwischen Rohstrings und tatsächlich von Chrome erkannten Berechtigungen unterschieden. Das Array enthält neun Einträge, aber commands gehört auf die oberste Ebene; deshalb ist die hier verwendete effektive Zählung acht erkannte Berechtigungen plus ein nicht erkannter String. Und 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ähigkeit, nie als beobachtetes Verhalten. Die Roh-Manifests, CRX-Hashes und Parser-Ausgaben sind der Audit-Trail für diese Normalisierungen, damit Leser sich nicht auf den Fließtext verlassen müssen.

Für eine echte Installationsentscheidung solltest du mindestens vier Dimensionen getrennt vergleichen: Welche Seiten sind standardmäßig im Scope, welche explizite Nutzeraktion schaltet mehr Reichweite frei, welche Browser- oder Konto-APIs werden verfügbar, und welche externen Aufrufer können der Erweiterung Nachrichten senden. Agentys activeTab-Modell, Table Captures geschütztes userScripts, Axiom.ais Drive-Scope und Thunderbits debugger-Deklaration sind keine Punkte auf einer einzigen linearen Skala. Es sind unterschiedliche Antworten auf unterschiedliche Sicherheitsfragen.

Hier ist dieser Vergleich auf vier bewusst unterschiedliche Designs angewendet:

Auch diese Tabelle erzeugt keinen Sieger. Agentys enger dauerhafter Seitenzugriff sagt nichts darüber aus, was das 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 das separate Gate aktiviert. Thunderbits debugger-Berechtigung eröffnet eine breite Browser-Kontrollfläche, aber das Manifest verrät nicht, welche CDP-Domains oder Methoden der Code aufruft. Jede Zeile sagt dir nur, was du als Nächstes prüfen solltest: Runtime-Netzwerkverkehr, Quellcode, Zustimmungsfluss oder Browser-API-Traces.

Die gleiche Trennung ist wichtig, wenn du die Installationsabfrage von Chrome liest. Eine reine Berechtigungszahl kann weder Timing, Frame-Reichweite, OAuth-Scopes, web_accessible_resources noch einen weggelassenen externally_connectable-Schlüssel zeigen. Umgekehrt ist eine breite Deklaration kein Beweis für Sammlung oder Exfiltration. Das nützliche Ergebnis eines Manifest-Audits ist ein priorisierter Runtime-Testplan: Datenoberfläche identifizieren, Nutzer-Gate notieren, dann beobachten, ob der deklarierte Pfad tatsächlich genutzt wird.

So lesen Sie Ihr eigenes Manifest

Verwandte Analyse: Leitfaden zur Browser-Automation.

1. chrome://extensions → Details zeigt gewährten Website-Zugriff und erlaubt es dir, ihn bei allem, was keinen dauerhaften Zugriff braucht, auf on click zu stellen. Das verengt den Seitenzugriffsteil des Obigen. Es ändert nichts an eingehenden Nachrichten (externally_connectable erreicht den Service Worker unabhängig davon) oder an Browser-Level-Berechtigungen. Thunderbits debugger-Deklaration ist hier relevant. In Chromiums eigener Sicherheitsdokumentation zu Erweiterungen heißt es, dass die Debugger-API „in einigen Fällen auch andere typische Einschränkungen umgehen kann, etwa Host-Berechtigungen oder Dateizugriff“. Daher begrenzt „on click“ nicht, worauf sie zugreifen kann. Ebenso wenig betrifft diese Einstellung tabs, webNavigation, clipboardRead, downloads oder irgendetwas in optional_permissions.
2. Die Rohdatei liegt im Chrome-Verzeichnis Extensions/<id>/<version>/. Lies sechs Felder: permissions, optional_permissions, host_permissions, content_scripts (also matches, run_at und all_frames darin), externally_connectable – mit dem Hinweis, dass ein fehlender Schlüssel für Erweiterungsaufrufer permissiv ist – und web_accessible_resources, deren matches Schemen nennen können, die Content Scripts nie angeben. Thunderbits letztes Feld enthält zwei <all_urls>-Einträge, die index.html und zwei gebündelte Skripte für jeden Ursprung freigeben, mit use_dynamic_url: false, was es einer Seite erlaubt zu prüfen, ob diese stabilen Extension-URLs aufgelöst werden.
3. Vergleiche das Aktualisierungsdatum des Listings mit der aktuellen 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 Tools ohne Erweiterung.

Thunderbit für Web-Datenextraktion testen

Kurzfassung

Zehn Scraping- und Automation-Erweiterungen, einschließlich unserer, wurden allein anhand ihrer eigenen Manifests gelesen.

Agenty deklariert keinen Seitenzugriff und keine Content Scripts, arbeitet nur auf dem Tab, den du gerade ansiehst, wenn du klickst, und das in 2.2 MiB. Axiom.ai deklariert jede HTTP- und HTTPS-URL über 37.1 MiB hinweg. Magical deklariert dreizehn Berechtigungen, darunter clipboardRead – und ist zugleich die einzige Erweiterung hier, die eingehende Nachrichten komplett schließt. Table Capture deklariert nur vier Berechtigungen und injiziert bei document_start in alle Frames auf <all_urls> – also auf dieselbe Match-Obergrenze, die auch wir erreichen, nur früher – plus userScripts auf Anfrage. TexAu ist die kleinste Erweiterung und nennt die meisten Ziele – vierzehn Muster über dreizehn unterschiedliche Eigenschaften. Sie ist nicht die einzige, die Ziele nennt: Clip to Clay deklariert zwei (clay.com und eine Drittseite), und Hexomatic sowie Clay for Chrome nennen ihre eigenen Domains. TexAu ist die einzige, deren benannte Liste überwiegend aus fremden Domains besteht. Fünf von zehn können auf Dateien auf deinem Laufwerk zugreifen, zwei davon – Axiom.ai und wir – ohne file:// jemals auszuschreiben.

Thunderbit, also wir, liegt am breiten Ende: <all_urls> sowohl für Host-Zugriff als auch für statische Injektion, plus debugger, den keine andere Erweiterung in diesem Set deklariert. Es liegt auf dem Chrome-Standard, der Nachrichten von jeder Erweiterung erlaubt, und es erreicht file://, nachdem Chromes User-Gate aktiviert wurde.

Eine Deklaration ist eine Obergrenze, kein Verhalten, und nichts davon zeigt Missbrauch. Aber es ist veröffentlicht, frei prüfbar und die Spreizung 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 weil Zählen zwei Dinge verfehlt. <all_urls> bedeutet, dass eine Erweiterung jede von dir besuchte Seite lesen darf; es sagt nichts darüber aus, was sie tatsächlich tut oder ob etwas dein Gerät verlässt. Ein Tool, das Daten von jeder beliebigen Seite extrahieren soll, kann realistisch nicht mit einer Liste benannter Domains arbeiten. Die Erkenntnis ist die Streuung, nicht Fehlverhalten – das tatsächliche Verhalten müsste über Runtime-Netzwerkanalyse festgestellt werden, und das hat dieses Audit nicht gemacht. Zum Zählen selbst: Injektions-Einstellungen sind keine Berechtigungen, daher deklariert Table Capture vier, obwohl es bei document_start in all_frames auf <all_urls> injiziert. Und optional_permissions erscheinen im Installationsdialog gar nicht – Table Capture kann userScripts zur Laufzeit anfordern, wodurch beliebige Nutzer-Skripte im Seitenkontext laufen können, und Magical kann webRequest anfordern.

Welche dieser Erweiterungen fordert am wenigsten? Agenty: vier Berechtigungen, keine Host-Berechtigungen, keine Content Scripts. Es basiert auf activeTab, das nur nach einem Klick auf die Erweiterung und nur bis zur nächsten Navigation Zugriff auf den aktuellen Tab gewährt. Hexomatic ist als Nächstes dran, mit zwei Berechtigungen und Content Scripts, die auf die eigenen Domains begrenzt 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 den Wildcard, ohne es irgendwo zu nennen. http://*/* und https://*/* decken file:// nicht ab. Chrome hält Dateizugriff hinter einem pro Erweiterung aktivierbaren Schalter standardmäßig aus, daher ist die Deklaration eine Anfrage und keine Freigabe.

Was ist externally_connectable, und warum ist das Weglassen die großzügige Option? Es nennt die Web-Ursprünge oder Erweiterungs-IDs, die an das Background Script einer Erweiterung schreiben dürfen. Chromes Standard, wenn der Schlüssel fehlt, ist: Jede Erweiterung darf verbinden, aber keine Webseite. Sieben der zehn lassen ihn weg, darunter 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 damit beide Kanäle.

Was deklariert Thunderbits eigenes Manifest? <all_urls> für Host-Zugriff und statische Content-Script-Injektion, in all_frames bei document_end; 15.9 MiB über 78 Dateien; und neun Strings im Berechtigungsarray. Acht davon sind erkannte Berechtigungen: activeTab, debugger, offscreen, scripting, sidePanel, storage, tabGroups und tabs. commands ist ein Manifest-Schlüssel auf oberster Ebene und hat im Array keine Wirkung. Keine andere Erweiterung in diesem Set deklariert debugger. Thunderbit erreicht außerdem file:// über <all_urls>, nachdem Chromes Dateizugriffs-Gate aktiviert ist, und es lässt externally_connectable weg. Das Laufzeitverhalten wurde nicht ausgeführt, daher behauptet das Audit nicht, welche CDP- oder Scripting-Methoden die Erweiterung tatsächlich aufruft.