Chromium ist ein Open-Source-Browserprojekt und zugleich die gemeinsame Basis von Browsern wie Chrome, Edge, Brave und Opera, selbst aber kein fertiges Produkt für normale Nutzer. Der Artikel erklärt das Verhältnis von Projekt und Distribution und was die Aussage auf Chromium basierend belegen kann und was nicht.
Beim Installieren eines Browsers wird den wenigsten bewusst, dass Edge, Brave, Opera, Vivaldi und Chrome denselben zugrunde liegenden Code verwenden. Dieser Code heißt Chromium, und er bestimmt, wie Seiten gerendert werden, wie Skripte ausgeführt werden und welche Schnittstellen Erweiterungen aufrufen können.
Ein Projekt, kein Produkt
Chromium ist ein Open-Source-Projekt, das 2008 zusammen mit Chrome als Open Source veröffentlicht wurde, und umfasst die Rendering-Engine Blink, die JavaScript-Engine V8 sowie den vollständigen Code der Browser-Oberfläche. Die Pflege wird von Google geleitet, doch der Code ist öffentlich, und jeder kann daraus seine eigene Distribution bauen.
Der entscheidende Unterschied: Chromium selbst ist kein fertiges Produkt für normale Nutzer. Offiziell gibt es fortlaufend gebaute Snapshots, ohne Auto-Updater, ohne Kontosystem und ohne Marken- und Service-Support. Das erklärt auch, warum viele nach dem Download von Chromium feststellen, dass sie Updates selbst erledigen müssen.
Warum alle es nutzen
Die Pflege einer Browser-Engine ist unverhältnismäßig teuer. Mit Webstandards Schritt zu halten, Sicherheitslücken zu schließen und verschiedene Betriebssysteme und neue Hardware zu unterstützen, erfordert ein Team mit langfristigem Einsatz. Selbst eine von Grund auf zu schreiben ist unrealistisch; von Chromium abzuzweigen und anzupassen kostet deutlich weniger und erbt direkt das Erweiterungs-Ökosystem und die Debugging-Werkzeuge.
So trennten sich die Wege. Chrome ist Googles eigenes Produkt; Edge gab 2020 seine eigene Engine auf und wechselte zu Chromium; Opera ging diesen Schritt früher; Brave, Vivaldi und Samsung Internet differenzieren sich ebenfalls auf dieser Basis. WebView in Android und Electron-Anwendungen auf dem Desktop nutzen ebenfalls Chromium. Firefox setzt dagegen auf Gecko, Safari auf WebKit – ein anderer technischer Weg.
Der Unterschied zu Chrome
Gleiche Herkunft heißt nicht gleiche Sache. Chrome fügt Chromium einen Auto-Updater, Absturz- und Nutzungsstatistiken sowie die Synchronisierung mit dem Google-Konto hinzu und hat Lizenzen erworben, um proprietäre Codecs wie H.264 und AAC sowie Widevine DRM einzubinden, weshalb Streaming-Websites ordnungsgemäß abspielen. Offizielle Chromium-Builds enthalten das meist nicht; eine Videoseite öffnet sich möglicherweise, spielt aber nicht, und Anmeldung und Synchronisierung sind nirgends zu finden.
Auch die Datenschutz-Standardeinstellungen unterscheiden sich. Chromium sendet keine Telemetrie zurück, bietet aber auch nicht die Datenschutz-Schalter von Chrome; die nachgelagerten Browser treffen jeweils eigene Abwägungen – Brave blockiert standardmäßig Werbung und Tracking-Skripte, Edge ersetzt das Kontosystem durch das von Microsoft. All diese Unterschiede liegen nicht in der Engine.
Ein weiterer oft übersehener Unterschied ist der Versionsfortschritt. Zwischen nachgelagerten Anbietern und dem Upstream gibt es eine Zeitverzögerung; manche Versionsnummern wirken eng im Gleichschritt, tatsächlich werden die Patches getrennt zusammengeführt. Stößt man auf ein Problem, das nur in einem bestimmten Browser auftritt, sollte man zuerst die Version prüfen und erst dann die Engine verdächtigen.
Warum Kompatibilität und Automatisierung es brauchen
Trifft die Frontend-Entwicklung auf eine Seite, die in Chrome funktioniert und in anderen Browsern Fehler zeigt, ist der erste Schritt zu klären, ob es ein Engine-Problem oder eine Anbieteränderung ist. Solange alles auf Chromium läuft, ist das Verhalten von CSS und JavaScript weitgehend vorhersehbar, und Unterschiede stammen meist aus dem Versionsalter und Anbieter-Patches.
Auch die Automatisierung profitiert. Ein gemeinsames Debugging-Protokoll bedeutet, dass ein für Chromium geschriebenes Skript auf einem nachgelagerten Browser oft direkt läuft; auch die DevTools-Schnittstellen und die Art des Aufrufs im Headless-Modus stimmen überein. Schwierig wird es bei den Versionen: Nachgelagerte Anbieter folgen dem Upstream in unterschiedlichem Tempo, manche liegen mehrere Versionen zurück, dasselbe Skript läuft in der alten Version und meldet in der neuen einen Fehler, oder es funktioniert in Browser A, aber nicht in Browser B – deshalb ist eine feste Version wichtiger als das Jagen nach der neuesten.
Automatisierungsaufgaben, die dauerhaft parallel laufen müssen, fixieren üblicherweise eine Chromium-Version und werden mit einer isolierten Laufzeitumgebung eingesetzt. Auch Werkzeuge zur Isolierung mehrerer Konten nutzen meist Chromium als Basis, weil es Open Source ist, die Version fixiert werden kann und die Erweiterungs- und Automatisierungsschnittstellen vollständig sind. PurpleMark gehört zu dieser Art von Werkzeug und gibt jedem Konto eine eigene Browserumgebung, die Profile, Netzwerk-Ausgänge und Geräte-Merkmale trennt.
Was diese Aussage belegt und was nicht
Sagt man, ein Browser basiert auf Chromium, dann belegt das, dass Rendering-Engine und Skript-Engine identisch sind, dass Webseiten sich ähnlich verhalten, dass Erweiterungsschnittstellen und Debugging-Protokoll weitgehend gemeinsam nutzbar sind und dass das Risiko für Webkompatibilität gering ist.
Nicht belegt ist eine lange Liste: Datenschutz-Standardeinstellungen, ob Telemetrie gesammelt wird, Synchronisierungsfähigkeit, Update-Kanäle, ob zusätzliche Blockier- oder Beschleunigungsfunktionen eingebaut wurden und wie viele Versionen es hinter dem Upstream liegt. Noch weniger lässt sich daraus ableiten, ob es sicher ist – Chromium gibt den Code frei, nicht die Standardkonfiguration.
Einen auf Chromium basierenden Browser für dasselbe Produkt zu halten, ist das häufigste Missverständnis. Was den Alltag wirklich bestimmt, ist, was die Anbieter auf dieser Basis hinzufügen, was sie weglassen und wie oft sie mit dem Upstream synchronisieren.
