Die unterschätzte Stärke von Browser-Erweiterungen: das Versprechen hackbarer Software (2019)

 (geoffreylitt.com)
1 Punkte von GN⁺ 2024-02-05 | 1 Kommentare | Auf WhatsApp teilen
  • Browser-Erweiterungen sind – anders als Smartphone- und Desktop-Plattformen – ein seltenes Ökosystem hackbarer Software, in dem Nutzer Web-Apps auf eine Weise verändern können, die von den ursprünglichen Entwicklern nicht vorgesehen war
  • Die mehr als 180.000 Erweiterungen im Chrome Web Store und die Installationsrate bei fast der Hälfte aller Chrome-Nutzer zeigen, dass selbst normale Nutzer sich ihre personalisierte Nutzungsumgebung selbst zusammenstellen, wenn es dafür einen einfachen Weg gibt
  • Die breite Nutzbarkeit von Erweiterungen beruht auf der Offenheit des Webs – etwa auf menschenlesbarem Client-Code, semantischem Markup und standardisierten Web-Layouts – statt auf app-spezifischen APIs
  • Erweiterungen für Passwort-Eingabe, Kanji-Lesehilfen, Annotationen, Werbeblockierung oder 2x-Wiedergabe sind kleine Werkzeuge, die über viele Websites hinweg funktionieren und eine andere Software-Erfahrung schaffen als das Modell rund um große Apps
  • Bösartige Erweiterungen und Eingriffe in die Privatsphäre müssen weiter adressiert werden, doch wenn Zugänglichkeit, Kompatibilität und Berechtigungen ausbalanciert werden, lässt sich die Erweiterbarkeit bewahren, mit der Nutzer die von ihnen verwendete Software tiefgreifend verändern können

Warum Browser-Erweiterungen besonders sind

  • In der jüngeren Debatte über Browser-Erweiterungen ging es vor allem um bösartige Erweiterungen, die den Browserverlauf sammeln, und um Googles Einschränkungen für Werbeblocker, doch Erweiterungen bleiben ein besonderes Beispiel für nutzergesteuerte Software
  • Unter den großen Software-Plattformen sind Browser-Erweiterungen eine seltene Ausnahme, bei der Nutzer die Apps, die sie täglich verwenden, auch jenseits der Absicht ihrer ursprünglichen Entwickler verändern dürfen und sogar dazu ermutigt werden
  • Auf Smartphone- und Desktop-Plattformen sind solche Veränderungen selten oder unmöglich, im Browser dagegen gehören sie zum Alltag
  • Erweiterungen geben das Gefühl zurück, die eigene Computernutzung tiefer kontrollieren zu können

Software, die Nutzer selbst zusammensetzen

  • Wenn eine Software-Plattform ab einem gewissen Maß offen ist, verändert sich auch die Art, wie normale Nutzer mit Software umgehen
  • Wer vier Gmail-Erweiterungen installiert und damit vom visuellen Design bis zu Kernfunktionen alles verändert, hat sich in gewissem Sinne einen eigenen E-Mail-Client zusammengestellt
  • Nutzer bleiben nicht bloß passive Konsumenten vorgefertigter Apps, sondern können ihre persönliche Art der Computernutzung selbst gestalten
  • Im Chrome Web Store gibt es mehr als 180.000 Erweiterungen, und fast die Hälfte aller Chrome-Nutzer installiert Browser-Erweiterungen
  • Diese Popularität zeigt, dass viele Nutzer die Möglichkeit tatsächlich nutzen, wenn es einen einfachen Weg gibt, Software zu erweitern

Eine hackbare Plattform statt app-spezifischer APIs

  • Browser-Erweiterungen decken ein sehr breites Spektrum ab: Passwort-Eingabe, das Lesen japanischer Kanji, vereinfachte visuelle Gestaltung von Gmail, Hervorhebungen und Annotationen in Artikeln, Später-lesen-Speicherung, 2x-Videowiedergabe, Werbeblockierung und mehr
  • Entscheidend für diese Breite ist, dass die meisten Erweiterungen Anwendungen auf eine Weise verändern, die von den ursprünglichen Entwicklern nicht konkret eingeplant wurde
    • Wenn eine japanische Zeitung Artikel veröffentlicht, muss sie keine Kompatibilität mit einer Kanji-Lesehilfe berücksichtigen, damit die Erweiterung trotzdem funktioniert
    • Entwickler von Erweiterungen sind nicht an app-spezifische APIs gebunden, in denen bereits die Sichtweise der App-Entwickler auf Erweiterbarkeit eingebaut ist, und haben dadurch größere kreative Freiheit
  • Einige Eigenschaften der Web-Plattform ermöglichen diese ungeplante Erweiterbarkeit
    • Die traditionelle Art der Web-Auslieferung sendet Client-Code in menschenlesbarer Form an den Browser
    • Selbst wenn Code obfuskiert oder aus anderen Sprachen kompiliert wird, sind Source Maps wichtig, um diesen Vorteil zu erhalten
    • Das Layout-Modell des Webs fördert standardisiertes semantisches Markup
    • Passwort-Manager-Erweiterungen funktionieren, weil Webseiten für die Passwortübermittlung zuverlässig das form-Tag verwenden, statt alles selbst zu implementieren
  • Auch wenn eine Website nicht für Erweiterungen gebaut wurde, sind manchmal clevere Umgehungen nötig, doch meist ist das mit vertretbarem Aufwand möglich und ohne jahrelanges Reverse Engineering
  • Zwischen Website-Entwicklern und Erweiterungsentwicklern kann es Spannungen geben, doch wenn die Website-Betreiber dafür keine zusätzliche Arbeit leisten müssen, akzeptieren sie kreative Erweiterungen oft eher
  • Nischenfunktionen, die nur eine kleine Nutzergruppe will, können von motivierten Community-Mitgliedern als Erweiterung gebaut werden, was auch die Last für App-Entwickler reduziert

Keine großen Apps, sondern kleine Werkzeuge

  • Viele Browser-Erweiterungen funktionieren als universelle Werkzeuge, die das Nutzungserlebnis auf allen Websites verbessern
  • Eine Annotations-Erweiterung muss nicht für jeden Artikel ein anderes Hervorhebungswerkzeug verlangen, sondern funktioniert auf allen Websites
  • Wie bei einem echten Textmarker lernt man ein Werkzeug einmal und nutzt es dann in vielen Kontexten mit großem Hebel
  • Auf vielen Software-Plattformen gilt die Vorstellung, dass das Betriebssystem plattformübergreifende Werkzeuge bereitstellt und Drittanbieter isolierte Einzel-Apps liefern, doch bei Browser-Erweiterungen fügen auch Drittanbieter Werkzeuge hinzu
  • Kleine Software-Einheiten verändern auch die Ökonomie
    • Die meisten Erweiterungen sind kostenlos, und ihr Funktionsumfang ist oft zu klein, um als vollwertiges Geschäft tragfähig zu sein
    • Trotzdem bauen Menschen Erweiterungen, und Nutzer ziehen großen Nutzen aus diesen kleinen Software-Bausteinen
    • Das Erkunden eines Erweiterungs-Stores ähnelt eher einem lokalen Flohmarkt als einem Supermarkt
  • Große Software großer Unternehmen ist nicht die einzige mögliche Form

Die Wurzeln der Offenheit des Webs

  • Seit den frühen Tagen des Personal Computing gibt es eine philosophische Tradition, Computer als interaktive Medien zu sehen, in die Nutzer ihre eigenen Ideen einbringen und ihre eigenen Werkzeuge schaffen
  • Diese Tradition spiegelt sich in Systemen wie Smalltalk, Hypercard und neuerdings Dynamicland wider
  • Als Tim Berners-Lee das World Wide Web entwickelte, stellte er sich ein System in genau dieser Tradition vor
    • Seine Vision war „ein System, in dem es genauso einfach ist, das zu teilen, was man weiß oder denkt, wie das zu lernen, was andere wissen“
    • Er fand, dass ein Webbrowser auch ein Web-Editor sein sollte, doch der Mosaic-Browser wurde ohne diese Funktion populär, was er bedauerte
  • Das Web wurde am Ende zwar zu einem Ort, an dem jeder über Social-Media-Plattformen Meinungen oder Fotos veröffentlichen kann
  • Innerhalb von Apps wie Facebook geschieht das jedoch in vorgegebenen Formaten und auf eine Weise, die die App bestimmt – einschließlich Werbung
  • Browser-Erweiterungen gehen weit über das Eingeben in bereitgestellte Textfelder hinaus und erlauben es, die Art, wie man beliebige Web-Anwendungen nutzt, tiefgreifend zu verändern
  • Sie schaffen eine Dezentralität, die verhindert, dass Unternehmen hinter großen Websites jedes Detail der Nutzererfahrung vollständig bestimmen

Wie Erweiterungen besser werden können

  • Es bleibt notwendig, Nutzer davor zu schützen, dass bösartige Erweiterungen ihre Privatsphäre verletzen

  • Zugänglichkeit

    • Der Übergang vom Nutzen zum Entwickeln von Erweiterungen erfordert derzeit noch erhebliche Kenntnisse in der Webentwicklung
    • Es ist auch schwierig, Erweiterungen direkt im Browser einfach zu entwickeln
    • Denkbar wäre ein fließender Übergang vom Bearbeiten einer Website in den Developer Tools zum Veröffentlichen einer kleinen Erweiterung

  • Kompatibilität

    • Erweiterungen hängen sich auf nicht offiziell unterstützte Weise in Websites ein, weshalb Website-Updates Erweiterungen vorübergehend kaputt machen können
    • Entwickler von Erweiterungen müssen dann teils schnell nachbessern, um mit Änderungen Schritt zu halten
    • Es braucht Wege für eine stabile Verbindung zwischen Website-Entwicklern und Erweiterungsentwicklern, ohne von expliziten Erweiterungs-APIs abhängig zu sein
    • Sauberes semantisches Markup, menschenlesbares CSS und Source Maps sind bereits heute etablierte Praktiken, die die Entwicklung von Erweiterungen erleichtern
    • Wenn Nutzer nach dem Release einer neuen Version von Cloud-Software drei Monate lang weiter die alte Version verwenden könnten, hätten Erweiterungsentwickler Zeit, Updates an die neue Version anzupassen

  • Berechtigungen

    • Web-Erweiterungen können den Browser-Client breit verändern, aber nicht den Server anfassen
    • Wenn der Server einer Social-Media-App nur einen Endpunkt zum Abruf von Posts in chronologischer Reihenfolge bereitstellt, kann eine Browser-Erweiterung nicht alle Beiträge per Stichwort durchsuchen
    • Wenn man die Client-Server-Grenze neu denkt, könnten Erweiterungen tiefere Änderungen ermöglichen
    • Stärkere Berechtigungen machen Sicherheits- und Datenschutzfragen schwieriger, doch wenn Erweiterbarkeit als Wert zählt, muss ein Gleichgewicht gefunden werden

Das Potenzial der nächsten Plattform

  • Beaker Browser und die Community rund um das dezentrale Web erforschen, wie das Web ohne zentrale Server funktionieren kann
  • Solche Architekturen könnten Nutzern vollständigere Kontrolle darüber geben, auch die „Server“-Seite von Web-Anwendungen zu verändern
  • Tim Berners-Lees neues Projekt SOLID umfasst Prinzipien, nach denen Nutzer mehr Eigentum an ihren eigenen Daten haben
  • Mit stärkerem Dateneigentum könnten Nutzer ihre Daten über Erweiterungen und andere Software flexibler handhaben, als es die APIs von Anwendungsservern erlauben
  • Computing ist noch jung, und Plattformen verändern sich schnell
  • Moderne Browser-Erweiterungen und Smartphone-Plattformen existieren erst seit ungefähr zehn Jahren
  • Wie offen künftige Plattformen sein werden, ist eine Frage, die wir gemeinsam entscheiden
  • Browser-Erweiterungen sind ein Beispiel für einen Ort, an dem Nutzer die von ihnen verwendete Software im Alltag hacken und zu ihrer eigenen machen

Update 2024

  • Beim Rückblick auf den 2019 geschriebenen Text fünf Jahre später sind einige verwandte Projekte hinzugekommen
  • Ich habe eine populäre Browser-Erweiterung für Twitter gebaut und in einem Text meine Erfahrungen damit festgehalten, Erweiterungen zu nutzen, um Probleme in Software zu beheben, die ich täglich verwende
  • Während meiner Promotion am MIT bei Daniel Jackson habe ich Wildcard entwickelt, das Nicht-Programmierern ermöglicht, Browser-Erweiterungen in Tabellenkalkulationen zu erstellen
  • Glen arbeitet an ExtensionPay, einer Monetarisierungsplattform für Menschen, die Browser-Erweiterungen zu nachhaltigen Projekten machen wollen
  • In jüngerer Zeit arbeite ich im Forschungslabor Ink & Switch in Richtung AI-basierter malleable software

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-02-05
Kommentare auf Hacker News

  • Ich bin der Autor. Ich habe diesen Beitrag vor fünf Jahren geschrieben, und seitdem ist meine Überzeugung vom Wert anpassbarer Software noch gewachsen, aber einige meiner Gedanken haben sich geändert.

    1. AI: AI wird schnell gut im Programmieren. Die heutige AI ist bei High-Level-Architektur oft schwach, kann aber kleine lokale Änderungen gut umsetzen; das scheint gut zu dem Code zu passen, der für Browser-Erweiterungen nötig ist. Ich erkunde diese Richtung und habe in „Malleable software in the age of LLMs“ mehr dazu geschrieben: https://www.geoffreylitt.com/2023/03/25/llm-end-user-program...
    2. Sicherheit: Durch Gespräche mit Leuten, die verschiedene Erweiterungsplattformen gebaut haben, darunter Browser-Extension-APIs, ist mir klarer als vor fünf Jahren geworden, dass Sicherheit bei der Verbreitung populärer Erweiterungsplattformen oft der zentrale Flaschenhals ist. Es ist schwer, Schutzmechanismen zu finden, wenn normale Nutzer invasive Erweiterungen von nicht vertrauenswürdigen Dritten in wichtige Software installieren sollen.
      Trotzdem denke ich, dass die Diskussion über Erweiterungen zu stark auf Sicherheit fixiert ist und dabei andere Werte opfert. Anpassbarkeit kann in manchen Fällen so wichtig sein, dass sie Vorrang vor Sicherheit haben sollte. Es gibt auch mehrere Lösungsansätze. Statt Erweiterungen von irgendwelchen Leuten aus dem Internet zu installieren, kann man sie innerhalb von Vertrauensbeziehungen austauschen, etwa mit Kolleginnen oder Freunden, oder nur selbst erstellte Erweiterungen nutzen. AI-gestütztes Programmieren kann das Selberbauen realistischer machen, bringt aber neue Sicherheitsprobleme mit sich. Außerdem habe ich Menschen getroffen, die Softwarearchitektur-Ideen haben, die diese zentrale Spannung reduzieren; ein Beispiel steht hier: https://www.wildbuilt.world/p/inverting-three-key-relationsh...
    3. Backend-Zugriff: Mir wird immer stärker bewusst, dass Browser-Erweiterungen im serverzentrierten Web nur auf Client-Code zugreifen können und dadurch tiefe Anpassungen oft blockiert werden. Man kann gewünschte Daten möglicherweise nicht lesen oder es fehlt eine Schreib-API, um die nötigen Aktionen auszuführen. Ich bin optimistisch, was Erweiterungen innerhalb der Client-Grenzen leisten können, aber das ist eine grundlegende Grenze der Plattform selbst.
      In dem Forschungslabor, in dem ich derzeit arbeite, Ink & Switch, entwickeln wir local-first Software: kollaborative Software, bei der Daten und Code auf dem eigenen Gerät liegen. Neben Vorteilen wie Privatsphäre sehen wir das auch als richtige Grundlage für mächtigere Erweiterungen, weil Daten und App-Code nicht auf einem Server eingeschlossen sind: https://www.inkandswitch.com/local-first/
    • Das Sicherheitsproblem offener Plattformen ist der Kernpunkt. Wenn ein System so offen ist, dass fähige Menschen es nach Belieben anpassen können, können auch böswillige Akteure weniger versierte Menschen dazu überreden, das System auf schädliche Weise zu verändern.
      Dass man unter Android eigene Custom-Keyboards bauen kann, ist großartig; dass jemand die Großeltern dazu überreden kann, eine Tastatur mit eingebautem Keylogger zu installieren, ist überhaupt nicht gut. Browser-Erweiterungen waren schon immer ein Ökosystem mit viel Malware, und der Witz, dass man jedes Mal, wenn man zu Thanksgiving nach Hause fährt, Toolbars aus dem Internet Explorer der Eltern entfernt, existiert ungefähr seit 1999.
    • Wenn Browser und mobile Betriebssysteme es einfach machen würden, Apps oder Erweiterungen gefälschte Ressourcen bereitzustellen, könnte das Ausführen nicht vertrauenswürdigen Codes deutlich sicherer werden.
      „Ja, Sie dürfen den Inhalt meines Telefons lesen. Für Sie sieht es so aus, als wäre das der gesamte Inhalt, und das ist alles. Aus meiner Sicht ist es allerdings nur ein Ordner, und zwar ein leerer. Es ist ja ein neues Telefon.“
      „Ja, hier ist meine Kontaktliste. Tut mir leid, dass sie fast leer ist. Es gibt nur eine teure Premiumnummer. Ich hoffe, Ihre Zentrale ruft dort nicht an.“
      „Ja, hier ist mein Mikrofon. Danke. Ich kann Rick Astley ziemlich gut imitieren.“
      „Fotos auf dem Telefon? Hier sind sie. Alles Fotos von Steckrüben. Mögen Sie die?“
    • Der Schnittpunkt von malleable software, local-first und lokaler AI begeistert mich sehr. Es fühlt sich an wie der Beginn einer neuen Software-Ära, und wenn es gut läuft, können wir die Kontrolle über unsere Daten von großen Unternehmen zurückholen und mehr Kontrolle über Eigentum und Arbeitsweisen gewinnen.
      Besonders interessiert mich, dass universelle CRDT-Tools wie Automerge oder Yjs zu grundlegenden Dateiformaten für local-first Software werden und interoperable Sync- und Kollaborations-Backends daran angeschlossen werden. Nutzer können mit Standardwerkzeugen direkt auf die zugrunde liegenden Daten zugreifen, und Dateien können miteinander verknüpft, eingebettet, geforkt und gemergt werden. So könnte eine neue Hypermedia-Plattform entstehen, auf der jedes Dokument geteilt, geforkt und in Echtzeit bearbeitet werden kann. Ich finde die Arbeit von Ink & Switch wirklich großartig und freue mich auf die nächste Veröffentlichung.
    • Eine große Einschränkung von Browser-Erweiterungen ist, dass es selbst für Erweiterungen, die man nur für sich selbst schreibt, keinen nutzerfreundlichen und skalierbaren Installationsweg gibt. Es gibt keine Möglichkeit, dem Browser zu sagen: Ich vertraue allen Erweiterungen in einem bestimmten Verzeichnis; lade sie bitte automatisch, ohne Signatur und ohne sie als XPI zu paketieren.
      Es gibt keine Funktion nach dem Motto: „Wenn Code und manifest in einem Verzeichnis liegen, nutzt der Browser sie.“ Damals, als Greasemonkey einfach normale Dateien aus dem Unterverzeichnis gm_scripts/ des Browser-Profils geladen hat, habe ich wegen dieser einfachen Verteilung Unmengen von Userscripts erstellt. Damals war das Erweitern von Websites spaßig und einfach, aber Mozilla hat das alles abgeschafft.
      Die Distribution ist wirklich furchtbar. Ich habe absolut keine Lust, jedes Mal, wenn ich eine Änderung vornehme, um auf meinem eigenen Computer meinen eigenen Code zu verwenden, die Erweiterung irgendwo ins Internet zu schicken, damit sie signiert wird. Außerdem war das Signierwerkzeug, als ich zuletzt nachgesehen habe, eine über 100 MiB große NPM/node-App, der man vertrauen musste, und größer als ein Linux-Kernel-Build.
    • Im Großen und Ganzen stimme ich der Einschätzung zu, aber das Problem ist, dass Browserhersteller oft APIs zurückziehen und dadurch gute und beliebte Erweiterungen kaputtmachen.

  • Im Jahr 2024 ist der Rahmen Browser-Erweiterung an sich sehr problematisch. Die meisten Browser-Erweiterungen sind anteilig Google-Chrome-Erweiterungen, und Google Chrome zeigt im Zuge seiner Bemühungen, die Einnahmen zu steigern, ganz klar, dass keine API sicher ist.
    Wer Erweiterungen für die Chrome API baut, sollte wissen, dass er seine Mühe möglicherweise in etwas steckt, das ein Großkonzern gedankenlos plattmachen kann. Ich will nicht in einer Situation leben, in der man strategisch schon verloren hat; deshalb sollte es in der Diskussion meiner Meinung nach um Firefox-Erweiterungen gehen. Auch Firefox hat keine makellose Bilanz. Die Umstellung auf Google-Chrome-Kompatibilität vor ein paar Jahren ist immer noch extrem ärgerlich. Trotzdem ist Firefox qualitativ die deutlich bessere Gegenseite.

    • Abgesehen davon: Erweiterungen 1) vergrößern die Angriffsfläche des Browsers, 2) wurden häufig gegen Geld an böswillige Akteure verkauft oder von ihnen übernommen, und 3) machen Dinge oft subtil kaputt – für erfahrene Nutzer noch okay, für andere aber ein Grund für Support-Anfragen. Erweiterungen insgesamt sind ein Chaos.
    • Browser-Erweiterungen scheinen in Firefox häufiger genutzt zu werden. Der Grund ist, dass Google Chrome-Erweiterungen gegenüber so feindselig ist. Mit dem Niedergang von Firefox ist auch die Welt der Erweiterungen kleiner geworden.
      Zehn Jahre lang habe ich in Firefox und Chrome etwas namens „Ad Limiter“ genutzt, mit identischem Code. Letztes Jahr hat Google, als es Adblocker weiter einschränkte, eine Drohbotschaft geschickt, und ich habe die Chrome-Version aufgegeben.
    • Man kann es auch so sehen, dass es sich buchstäblich überhaupt nicht davon unterscheidet, in irgendeiner anderen Umgebung zu entwickeln.
    • Ich frage mich, ob die Synchronisierungsfunktion von Firefox inzwischen repariert ist. Früher musste man die Profildateien tatsächlich verschieben. Als ich vor langer Zeit in der IT gearbeitet habe, war Firefox in Unternehmensumgebungen wirklich ein Albtraum. Natürlich konnte man damals auch die Installation von Chrome-Erweiterungen nicht kontrollieren.
    • Für Browser-Erweiterungen gibt es einen Standard. Ich habe schon Browser-Erweiterungen gebaut, bevor es diesen Standard gab. Heute kann man Erweiterungen erstellen, die in Chrome, Firefox, Edge und Safari funktionieren.
      Natürlich kann man auch APIs nutzen, die nur für einen bestimmten Browser gedacht sind. Das ist genauso schlecht wie eine Website zu bauen, die nur für einen einzigen Browser gedacht ist. Die Basis sollte kompatibel sein. Und weil der Quellcode von Erweiterungen immer einsehbar ist, kann man ihn für eine Version anpassen, die im eigenen Browser gut funktioniert, und ihn auch wieder teilen.

  • Ein erheblicher Teil populärer Browser-Erweiterungen wurde von Datenbrokern übernommen und zum Abgreifen des Browserverlaufs genutzt; daher ist es schwer zu sagen, sie seien unterschätzt. Das Sicherheits- und Privatsphäre-Modell von Erweiterungen war oder ist ziemlich miserabel, weshalb man sehr vorsichtig sein sollte.
    Ich weiß zum Beispiel, dass Screenshot-Erweiterungen wie Awesome Screenshot den Browserverlauf absaugen und an einen israelischen Datenbroker senden. Solche Funktionen sind vermutlich besser als eingebaute Browser-Funktionen aufgehoben.

    • Als jemand, der eine im Voraus bezahlte Webbrowser-Erweiterung anbietet, würde ich sagen, dass im Voraus bezahlte Erweiterungen unterschätzt werden.
      Der Satz „Wenn ich nicht der Kunde bin, bin ich das Produkt“ ist so abgedroschen wie zutreffend. Aber was, wenn ich tatsächlich der Kunde bin? Ein großer Teil des Misstrauens gegenüber Browser-Erweiterungen kommt meiner Meinung nach daher, dass es schwierig ist, Erweiterungen direkt zu monetarisieren. Wenn man mit einer Erweiterung kein Geld verdient und jemand mit einem ordentlichen Scheck zur Übernahme winkt, ist es schwer abzulehnen – besonders wenn die Erweiterung für den Entwickler Support-Aufwand bedeutet. Natürlich habe ich, wie fast jeder, meinen Preis, aber im Moment müsste er wohl im siebenstelligen, vielleicht sogar achtstelligen Dollarbereich liegen, und niemand wird diesen Betrag für meine Erweiterung zahlen. Weil sie kostenpflichtig ist, ist die Nutzerbasis vergleichsweise klein, und gerade deshalb ist sie auch keine große Gelegenheit für Datensammlung oder finstere Pläne.
    • Aus diesen Gründen und wegen der fehlenden feingranularen Berechtigungen nutze ich, wenn möglich, Desktop-Apps statt Erweiterungen und halte meine Erweiterungsliste sehr klein. Im Grunde installiere ich nur FOSS-Erweiterungen von „großen“, vertrauenswürdigen Autoren wie Raymond Hill oder Projekte, die nicht verkauft werden.
      Natürlich gibt es auch bei Desktop-Apps Risiken, aber historisch gesehen war diese Art von Datenabfluss nach einer Übernahme bei Desktop-Apps relativ selten. Besonders unter macOS werden signierte Apps in einer Sandbox ausgeführt und können ohne Nutzerberechtigungen nicht allzu viel tun.
    • Es ist absurd, dass man einem unbekannten Coder alle seine Browserdaten anvertrauen muss, nur um in Firefox vertikale Tabs zu nutzen. Deshalb stimme ich zu, dass so etwas besser eine eingebaute Browser-Funktion sein sollte.
      Natürlich sind viele dieser Erweiterungen Open Source und können geprüft werden. Allerdings habe ich nicht die Fähigkeiten, bösartigen Code zu erkennen, und frage mich daher, ob das nicht ein guter Anwendungsfall für KI sein könnte. Ich frage mich, ob es Ideen dazu gibt, gute Prompts zur Malware-Erkennung zu erstellen.

  • Ich wünschte, Browser-Erweiterungen hätten feingranularere Berechtigungen. Allerdings ist es schwierig zu überprüfen, ob Software Berechtigungen missbräuchlich nutzt; das sieht man etwa am Obfuscated C Code Contest oder am Underhand C Contest. Außerdem ist es schwer, nuancierte Berechtigungen an Nutzer zu kommunizieren. Die meisten Nutzer lesen technische Details nicht oder verstehen sie nicht und lassen sich leicht in die Irre führen.
    Es gibt einen Tipp, wie man Erweiterungen in Chrome sicherer ausprobieren kann: Unter Profiles > Add profile > Continue without account ein separates Profil anlegen und die gewünschte Erweiterung dort installieren; dann ist sie vollständig von Tab-Logins, Verlauf, Cookies usw. des normalen Profils isoliert. Genauso kann man neben dem normalen Chrome auch Chrome Beta oder Chrome Canary eigens für installierte Erweiterungen laufen lassen.
    Man kann zum Beispiel Dutzende potenziell riskante Web-Development-Erweiterungen in diesem Profil installieren und es wie eine Sandbox von dem Profil trennen, das man für private Bankgeschäfte oder Logins auf Firmen-Websites nutzt. Das ist nicht für alle Erweiterungen praktikabel, aber für Webentwicklung mache ich es so und nutze privat nur ein paar Erweiterungen.
    Die Berechtigung, die ich für die von mir verkaufte Browser-Erweiterung wirklich anfordern möchte, wäre „darf nur den Netzwerkverkehr beobachten, der in den eigenen Tabs gesendet und empfangen wird“. Tatsächlich muss ich aber die Berechtigung „alle Daten lesen und schreiben“ anfordern. Deshalb teile ich diesen Tipp in der Beschreibung: https://chromewebstore.google.com/detail/checkbot-seo-web-sp...

    • Als Firefox-Nutzer wünschte ich, man könnte Erweiterungen in Multi-Account Containers pro Container deaktivieren. Für Banking-Websites brauche ich keine Erweiterungen. Man kann zwar ein separates Profil verwenden, aber die User Experience ist schlecht.
    • Die Berechtigung „alle Daten lesen und ändern“ ist für Shopping-Erweiterungen eine große Hürde. Eigentlich muss man nur Shopping-Seiten identifizieren. Um Vertrauen aufzubauen, habe ich versucht, die Tracking-Analyse als Open Source zu veröffentlichen: https://github.com/Score-Extension/score-extension-analytics...
      Ich hoffe, dass Transparenz ein Weg sein kann, diese Vertrauenshürde zu überwinden.
    • Ich wünschte, es gäbe eine Möglichkeit, den gesamten Umfang der Erweiterungsberechtigungen per Domain-Allowlist einzuschränken. In Chromium gibt es zwar eine Möglichkeit, Domains auf eine Allowlist zu setzen, auf denen eine Erweiterung ausgeführt werden darf[1], aber soweit ich gesehen habe, wirkt sich das nicht auf umfassendere Berechtigungen wie den allgemeinen Verlauf aus.
      [1] Man klickt bei der Erweiterung auf „Details“, ändert die Option „Allow this extension to read and change all your data on websites you visit“ auf „On specific sites“ und fügt die Sites der Allowlist hinzu.
    • Unter Windows kann man die von portableapps.com paketierten Apps verwenden. In der .ini ist AllowMultipleInstances=true erforderlich.

  • „Browser-Erweiterungen erinnern an das Gefühl, tiefgreifend kontrollieren zu können, wie man seinen Computer nutzt“ — dazu hätten Linux-Nutzer wohl ein Wörtchen mitzureden.
    Allgemeiner gesagt ähnelt das ziemlich der Frage, die ich vor ein paar Jahren in einem Text mit dem Titel „Is Open Source a diversion from what users really want?“ diskutieren wollte. Die Begeisterung darüber, Software auf eine Weise zu „hacken“, bei der man das Build-System nicht anfassen muss, scheint viel größer zu sein als bei dem vollständigen, offenen und theoretisch unbegrenzten Zugriff, den FLOSS bietet. Es gibt offensichtliche Gründe dafür, aber ein wenig enttäuschend ist es trotzdem.
    Ich habe das hier anhand des Gegensatzes zwischen Reapers skriptbarer, aber Closed-Source-Architektur und Ardours skriptbarer Open-Source-Architektur diskutiert: https://discourse.ardour.org/t/is-open-source-a-diversion-fr...

    • Ich bin Linux-Nutzer, stimme aber nicht zu. Es ist nicht ganz dasselbe Problem. Wenn man will, kann man den Kernel neu kompilieren und auch den Großteil des Userlands neu kompilieren. Aber das ist umständlich, besonders wenn man sich vom Upstream abspaltet und diese Unterschiede langfristig pflegen will.
      Mit Dingen wie LD_PRELOAD kann man interessante Hacks machen, aber an die Flexibilität und Zugänglichkeit von Browser-Erweiterungen kommt das überhaupt nicht heran. Man hat zwar das Recht, jede Software nach Wunsch zu verändern, aber die praktische Reibung dabei ist vergleichsweise hoch.
    • Der Wechsel von Linux zu systemd war eine Erfahrung, die dem Niedergang von Browser-Erweiterungen sehr ähnelte. Natürlich kann ich ändern, wie mein Computer funktioniert. Aber wenn ich nicht bereit bin, viel Aufwand in die Pflege dieser Änderungen zu stecken, wird mir die API, die ich nutze, unter den Füßen weggezogen, und es wird immer schwieriger, meinen Computer so funktionieren zu lassen, wie ich es will, statt so, wie es sich jemand anderes gedacht hat.
    • Erweiterungen wirken wie ein Weg, Code-Signierung, Distribution und Markenaufbau zu umgehen. Deshalb werden Browser wie Chrome zu Plattformen für die Verteilung und Ausführung von Software.

  • Ich habe eine im Chrome Web Store empfohlene Chrome-Erweiterung gebaut[1], und es ist wirklich beunruhigend, wie viele dubiose Datenbroker mir Anfragen schicken, meine Erweiterung zu kaufen und sie mit Spyware zu füllen.
    Ein naiver Entwickler baut etwas Cooles, verkauft es in der Annahme, dass jemand es weiter pflegt, und am Ende kann es den Nutzern tatsächlich schaden. Google scheint die Nutzung von Berechtigungen ziemlich gut zu prüfen, aber es gibt eben Erweiterungen wie meine, die auf alles auf der Seite zugreifen müssen. Man muss sich nur vorstellen, was ein Datenbroker damit anfangen könnte. Bei der Installation sollte man vorsichtig sein.
    [1] https://chromewebstore.google.com/detail/css-selector-helper...

  • Am nötigsten wäre meiner Meinung nach view source für Browser-Erweiterungen, die man aus dem Store installiert hat. Man sollte den Source leicht einsehen und Browser-Erweiterungen als Ordner extrahieren können.
    Auch sollte leicht erkennbar sein, auf welche Webseiten sie zugreifen und was sie verändern. Minifizierter oder verschlüsselter Code in Erweiterungen sollte verboten sein, und der Code sollte sehr leicht lesbar sein. Diese Erweiterung sagt zum Beispiel, sie „zeichnet Nutzeraktivitäten auf“, aber es ist schwer zu erkennen, was das tatsächlich bedeutet: https://chromewebstore.google.com/detail/coffeelings/hcbddpp...

    • Wenn man in Chrome zu chrome://extensions geht und den Entwicklermodus aktiviert, kann man in den DevTools bei jeder Erweiterung Source ansehen. Content Scripts sind auch ohne aktivierten Entwicklermodus bereits in den DevTools normaler Webseiten sichtbar.
      Die vollständige Liste der Websites sieht man im Installations-Popup der Erweiterung. Der Chrome Web Store verbietet Code-Obfuskation bereits. Minifizierung ist erlaubt, weil es keine sinnvolle Möglichkeit gibt, die Qualität von Variablennamen zu erzwingen.
    • Bei Browser-Erweiterungen im Chrome Web Store kann man den Source auch ohne Installation ansehen. Ich nutze dieses Tool gelegentlich dafür: https://robwu.nl/crxviewer/
      Gegen absichtlich obfuskierten Code hilft es zwar nicht, aber für Sicherheits- und Datenschutzforschung zu den meisten Erweiterungen dürfte es nützlich sein.

  • Keine vollständigen Erweiterungen, aber Userscripts und User-Styles leisten ziemlich viel, und es gibt Erweiterungen, mit denen Leute sie direkt im Browser erstellen und verwenden können. Beispiele sind Tampermonkey[0] und Stylus[1].
    Auch wenn sie nicht so viel können wie Erweiterungen, halte ich sie für enorm wichtig.
    [0] https://www.tampermonkey.net/
    [1] https://chrome.google.com/webstore/detail/stylus/clngdbkpkpe...

    • Userscripts sind unterschätzt. Ich nutze sie für alles Mögliche. Zum Beispiel korrigiere ich damit GitHubs nutzlose Landingpage so, dass sie zu meinen Repositories führt, hardcode meine Instanz-Domain, damit der Mastodon-„Follow“-Button funktioniert, und blockiere nutzlose Treffer wie stackshare in Google-Suchergebnissen.
      Außerdem nutze ich sie, um von YouTube-„Short“-Ansichten zur normalen Videoansicht umzuleiten und den dummen Leerraum rechts neben der Gmail-Scrollbar zu entfernen.

  • Ich programmiere, wenn auch nicht in JavaScript/TypeScript, nutze sehr viele Erweiterungen und würde mich als Power User bezeichnen, der niemals einen Browser ohne Chrome-/Firefox-Erweiterungsökosystem verwenden würde. Ich habe auch Chrome- und VSCode-Themes erstellt, stehe aber trotzdem weiterhin an diesem Punkt. Falls ihr Pink/Türkis mögt, hier: https://marketplace.visualstudio.com/items?itemName=mikejk8s...
    Allein aus dem Chrome-Prompt verstehe ich überhaupt nicht, was eine Erweiterung tun, lesen, sehen und worauf sie zugreifen kann. Bedeutet „Zugriff auf Daten auf allen Websites erlauben“ wirklich alle Daten? Auch das, was ich eintippe? Weiß sie, wenn ich von URL zu URL navigiere? Liest sie nur Assets? Gibt es eine Chrome-API, die den Zugriff einschränkt, und kann ich das sehen? Ich weiß nicht, worüber ich mir tatsächlich Sorgen machen sollte.
    Ich nutze eine Video-Zoom-Erweiterung, mit der ich jedes Video auf jeder Website vergrößern kann. Muss ich jede Erweiterung selbst auditieren, um sicherzugehen, dass sie meine Daten nicht irgendwohin kopiert? Ich habe keine Ahnung, und wie soll ein nichttechnischer Nutzer das wissen?

    • Es scheint genau so schlecht zu sein, wie es klingt. Deshalb vertraue ich, wie jemand anders sagte, nur einigen wenigen Kern-Erweiterungen wie uBlock und Bitwarden solchen Zugriff an.
      Bei Startup-Produkten für Bildschirm- und Session-Recording wäre ich besonders vorsichtig. Schon allein, weil sie besonders anfällig für Supply-Chain-Angriffe sein können.
    • Ja, es ist so schlimm. Ich habe ein paar webexts geschrieben, und wenn man alle Daten anfordert, bedeutet das wirklich alle Daten. Wenn man etwas auf der Seite ändern muss, fragt man sich allerdings auch, wie es sonst funktionieren sollte.
      Deshalb halte ich meine Liste auf einmalige Erweiterungen, die ich selbst erstellt habe, bekannte große Erweiterungen oder solche, deren Code ich selbst auditiert habe, beschränkt.

  • Ich bevorzuge Bookmarklets. Sie sind leicht zu bearbeiten, bleiben inaktiv, bis man sie anklickt, funktionieren in allen Browsern, auch mobil, und integrieren sich gut in die UI.
    Man kann sie beliebig verschieben, in jeden Lesezeichenordner legen und auch Tastenkürzel zuweisen. Ich habe einen Editor gebaut, mit dem man sauberen Code und Bookmarklets leicht ineinander umwandeln kann: https://www.gibney.org/bookmarklet_editor

    • Ziemlich nützliche Seite. Als ich zuletzt mit Bookmarklets herumgespielt habe, funktionierten sie in Firefox für Android nicht, inzwischen aber schon. Zusammen mit meiner Node-RED-Instanz dürfte das nützlich sein.
      Ich frage mich, ob es gute Bookmarklets gibt, die man teilen sollte.