Der Verrat der Grammarly-Erweiterung

 (dbushell.com)
2 Punkte von GN⁺ 2025-03-31 | 1 Kommentare | Auf WhatsApp teilen

Warum die Grammarly-Erweiterung Websites kaputtgemacht hat

  • In den vergangenen Monaten gab es immer wieder Berichte über seltsam kaputte Website-Layouts
  • Als Ursache stellte sich die Grammarly-Browser-Erweiterung heraus, und um das zu verifizieren, installierte der Autor sie selbst

Wie das Problem entdeckt wurde

  • Die Grammarly-Erweiterung fordert folgende Berechtigungen an:
    • Zugriff auf Daten aller Websites
    • Anzeigen von Benachrichtigungen
    • Zugriff auf Browser-Tabs
  • Bei Experimenten in Firefox zeigte sich, dass Grammarly ein eigenes Stylesheet in Webseiten einfügt
    • Dieses Stylesheet kann auf der Webseite selbst nicht direkt erkannt werden (verstecktes Stylesheet)
    • Es umgeht sogar die Content Security Policy
  • Innerhalb des <html>-Tags wird außerdem ein Element <grammarly-desktop-integration> eingefügt (Zweck unklar)

Warum ausgerechnet meine Website?

  • Am Ende des Grammarly-Stylesheets steht folgender Code: 
    :host,  
:root {  
  --rem:16  
}
  • Diese Einstellung kollidiert mit der Standard-CSS-Einheit 1rem = 16px, und der Autor verwendete ebenfalls die Custom Property --rem
  • Grammarly setzt global einen festen --rem-Wert und versucht damit dynamische Schriftgrößen umzusetzen
  • Dadurch wurden die fluiden Typografie-Berechnungen des Autors zerstört

Reaktion des Autors

  • Zunächst erkannte er per Mutation Observer die von Grammarly eingefügten Elemente und überschieb sie mit !important-Styles
  • Danach änderte er den Namen seiner CSS-Variable von --rem zu --🤡 (Unicode-Emoji)
  • Emojis sind als CSS-Variablennamen gültig
  • So lässt sich der Konflikt mit Grammarlys globaler --rem-Definition vermeiden

Der Kern des Problems

  • Grammarly erzwingt als Web-Erweiterung globale Styles auf allen Websites
  • Besonders schädlich ist die Verwendung eines allgemeinen CSS-Variablennamens wie --rem
  • Intern werden zufällige Klassennamen verwendet, daher ist kaum nachvollziehbar, warum ausgerechnet ein öffentlicher Name global angewendet wurde
  • Der Code wird sogar eingefügt, wenn man die Erweiterung gar nicht aktiv nutzt

Fazit und Vorschlag

  • Der Autor kontaktierte Grammarly; zwar kam schnell eine Antwort, er wurde aber nicht mit jemandem verbunden, der das technische Problem wirklich verstand
  • Die ideale Lösung wäre, dass Grammarly einen Variablennamen wie --🤡 verwendet und andere Entwickler --rem frei nutzen können

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-31
Hacker-News-Kommentare

  • Mein Problem mit Erweiterungen ist etwas anders. Wir verteilen eine Erweiterung, die das einfache Umschalten zwischen Proxy-Servern für Geolokalisierungstests ermöglicht

    • Vor einigen Monaten hatte ich die schlimmste Client-Demo überhaupt. Es sah so aus, als würde das Produkt nicht funktionieren
    • Nach viel Debugging fanden wir heraus, dass ein kürzliches Update der 1Password-Erweiterung unsere kaputtgemacht hatte
    • Sie hatten ein Authentifizierungsereignis abonniert, aber nichts zurückgegeben, wodurch unser Subscriber nicht aufgerufen wurde
    • Das Support-Team von 1Password war besser als Grammarly, aber es war schwer, sie von der Priorität zu überzeugen
    • Eine russische Erweiterung, die für Regierungswebsites benötigt wird, hat dasselbe Problem

  • Wenn man Skripte oder Styles in Seiten mit unbekanntem Inhalt injiziert, ist es das Mindeste an Anstand, Variablen mit einem Namespace zu versehen

  • Es ist beängstigend zu sehen, wie viele Bildschirmfreigaben und Aufzeichnungen standardmäßig den grünen Eindringling auf jeder Website enthalten

    • Nicht nur die visuelle Ablenkung ist ein Problem, sondern auch Datenschutz und Angriffsvektoren
    • Chrome kann Erweiterungen nur bei Bedarf aktivieren. Ich frage mich, warum das niemand so macht

  • Ich bin Engineer für die Grammarly Extension. Es tut mir leid, dass wir die UX von dbushell.com kaputtgemacht haben

    • Das war nicht beabsichtigt, und wir verwenden verschiedene Techniken, um das zu verhindern
    • Wir haben vorübergehend eine Ausnahme für dbushell.com hinzugefügt
    • Wir arbeiten an Änderungen, um Stil-Isolation sicherzustellen

  • Ich habe dieses Problem an das Engineering-Team weitergeleitet

  • Ich habe ein ähnliches Problem damit, dass Google Translate meine Web-App kaputtmacht

    • Nutzer, die Google Translate verwenden, beschweren sich, dass die App kaputt ist
    • Das liegt daran, dass Google den Zustand der App auf einer höheren Meta-Ebene verändert hat
    • Ich versuche, Google Translate zu erkennen und eine Warnung auszugeben

  • Bei der Arbeit haben wir viele Sentry-Fehler im Zusammenhang mit Browser-Erweiterungen

    • Google Translate in Chrome ist berüchtigt dafür, React-basierte Websites kaputtzumachen
    • Es ist mühsam, neue Erweiterungsprobleme zu ignorieren
    • Wir nutzen clientseitige Filterung, um das Erfassungsvolumen zu reduzieren

  • Ich frage mich, welche Variable das Web am stärksten kaputtmachen könnte

    • --primary-color: transparent

  • Ich frage mich, wie andere mit feindseligen Browser-Erweiterungen umgehen

  • Ich frage mich, ob man mit dieser Methode Plugins kapern kann

    • Man sollte zumindest Text injizieren können und möglicherweise auch ein Login-Formular rendern, indem man das Vertrauen der Nutzer ausnutzt
    • Ich frage mich, ob es wirklich sicher ist, Elemente in ein Dokument zu injizieren, das von jemand anderem kontrolliert wird