Chrome und Chromium nutzen dieselbe Engine; die Unterschiede liegen bei Codec-Lizenzen, DRM-Komponenten, automatischen Updates, Telemetrie und Kontodiensten. Der Artikel erklärt Punkt für Punkt die Versionsrhythmen und Lizenzunterschiede der beiden und zeigt, was Alltagsnutzer und wer eine saubere Engine braucht jeweils wählen sollten.
Chrome und Chromium sehen fast identisch aus – Menüs, Tastenkürzel und Erweiterungssystem stimmen überein –, deshalb ist es beim ersten Mal etwas überraschend zu hören, dass es nicht dasselbe ist. Getrennt werden sie durch das Unsichtbare: Codec-Lizenzen, DRM-Komponenten, Update-Kanäle, Telemetrie und Kontodienste.
Das eine ist ein Projekt, das andere ein Produkt
Chromium ist ein Open-Source-Projekt, das 2008 zusammen mit Chrome quelloffen wurde und dessen Code in einem eigenen Repository liegt. Es gibt keine offizielle Veröffentlichung im eigentlichen Sinn; herunterladen lassen sich fortlaufend gebaute Snapshots, deren Versionsnummern dem Hauptzweig folgen. Chrome ist ein Produkt, das Google auf dieses Projekt aufsetzt und mit Zusätzen paketiert: mit Marke, Release-Rhythmus, Richtlinien- und Supportstruktur – und es trägt auch die Kosten für Lizenzierung und Compliance.
Codecs und DRM
Open-Source-Bestandteile unterliegen Patent- und Lizenzbeschränkungen, deshalb enthalten die offiziellen Chromium-Builds in der Regel keine proprietären Codecs wie H.264 und AAC und auch kein Widevine DRM. Die Folge: Manche Videoseiten öffnen sich, spielen aber nicht ab, und Streamingdienste wie Netflix und Spotify verweigern die Wiedergabe direkt. Chrome zahlt die Lizenzgebühren und packt all das in seine Distribution. Linux-Distributionen ergänzen die Dekodierung allerdings häufig über das systemeigene ffmpeg, deshalb ist „Chromium kann keine Videos abspielen“ nicht absolut – es hängt vom konkreten Build ab.
Update-Weg und Versionsrhythmus
Chrome bringt einen Updater mit, der im Hintergrund still aktualisiert, was Nutzer kaum bemerken. Die stabile Version rückt etwa alle vier Wochen um eine Hauptversion vor; dazu gibt es Canary (täglich), Dev und Beta (wöchentlich) als Kanäle, auf die Entwickler umschalten können, die neue Funktionen früher testen wollen. Chromium hat keine offiziellen automatischen Updates: Neue Snapshots muss man selbst herunterladen und überschreiben. Der Rhythmus des Hauptzweigs ist ungefähr mit Chrome synchron, aber es gibt keinen gebrandeten stabilen Zweig – welches Datum man nimmt, hängt ganz von einem selbst ab.
Der Versionsunterschied ist bei Kompatibilitätstests entscheidend: Chromes Versionsnummer ist eindeutig, während Chromium-Snapshots nur ein Commit-Datum haben, wodurch sich Umgebungen bei Problemen schwer abgleichen lassen.
Automatische Updates sparen nicht nur Mühe, sie bestimmen auch, wann Sicherheitspatches ankommen. Chromes Schwachstellenkorrekturen werden mit der stabilen Version ausgeliefert, und Nutzer aktualisieren, ohne es zu merken. Wer Chromium nutzt, muss Sicherheitshinweise selbst verfolgen, einschätzen, ob der vorliegende Build die Korrektur enthält, und dann entscheiden, wann ein neuer Snapshot kommt. Die Zeit dazwischen ist die Risikolücke.
Telemetrie, Synchronisierung und Konto
Chrome sendet standardmäßig Absturzberichte und Nutzungsstatistiken zurück; nach der Anmeldung mit einem Google-Konto synchronisieren Lesezeichen, Passwörter, Verlauf und Erweiterungen. Chromium bringt diese Dienste nicht mit: keinen Anmeldezugang für Konten, kein Sync-Backend, und Absturzberichte werden standardmäßig ebenfalls nicht gesendet. Nebenbei bemerkt fallen Funktionen, die auf Google-Dienste angewiesen sind – Standort, Rechtschreibprüfung, Übersetzung – in Chromium aus oder arbeiten eingeschränkt, weil kein eingebetteter API-Schlüssel vorhanden ist.
Alltagsnutzer und Leute, die an der Engine basteln
Normale Nutzer haben keinen Grund, auf Chromium umzusteigen. Die eingesparten Telemetriedaten kosten Videos, die nicht abspielen, Lesezeichen, die nicht synchronisieren, und Sicherheitsupdates, die man selbst im Blick behalten muss – nicht lohnend. Sinnvoll ist es nur, wenn man ausdrücklich keine Verbindung zu Google-Diensten will. Chromium installieren und sich dann beschweren, dass Streaming nicht öffnet, ist die häufigste Quelle der Enttäuschung.
Umgekehrt wählen Leute, die eine saubere Engine brauchen, eher Chromium. Bei der Frontend-Kompatibilitätsprüfung will man klären, ob ein Problem in der Standard-Engine oder in einem Hersteller-Patch steckt; beim Schreiben von Automatisierungsskripten will man die Version festnageln und nicht von automatischen Upgrades durcheinanderbringen lassen; und wer eigene Distributionen baut und weiterentwickelt, kommt ohne die Open-Source-Lizenz nicht aus. Der Ärger liegt meist nicht an der Engine selbst, sondern an fehlenden lizenzierten Komponenten und Versionsdrift. Deshalb installieren viele beides: Chrome zum alltäglichen Surfen, eine feste Chromium-Version zum Testen und für Skripte.
Was „auf Chromium basierend“ aussagt
Wenn ein Browser sagt, er basiere auf Chromium, dann ist sicher, dass Rendering-Engine und JavaScript-Engine identisch sind und sich Seitenverhalten, Erweiterungsschnittstellen und Debugging-Protokoll weitgehend gleichen. Nicht sicher ist, wie die Datenschutz-Standardwerte, das Sync-Backend, die Telemetrie-Strategie und die Update-Kanäle aussehen – und auch nicht, wie viele Versionen er hinter dem Upstream liegt. Wähle einen Browser nicht nur nach diesem einen Satz; schau, was er gegenüber dem Upstream geändert und was er weggelassen hat. Aus demselben Grund sollte der Vergleich von Chrome und Chromium nicht bei der Frage stehen bleiben, ob die Oberflächen ähnlich aussehen – vergleichen sollte man die Teile, die installiert sind oder nicht, die sich verbinden oder nicht und die sich selbst aktualisieren oder nicht.
