Wróć do bloga

Chrome i Chromium: kanały aktualizacji i różnice w kodekach

Chrome i Chromium korzystają z tego samego silnika, a różnice skupiają się na licencjach kodeków, komponentach DRM, automatycznych aktualizacjach, telemetrii i usługach konta. Artykuł omawia po kolei rytm wydań i różnice licencyjne obu przeglądarek oraz wskazuje, co powinni wybrać zwykli użytkownicy, a co osoby potrzebujące czystego silnika.

Interfejs Chrome i Chromium wygląda niemal identycznie – menu, skróty klawiszowe i system rozszerzeń się zgadzają – dlatego pierwsza informacja, że to nie to samo, trochę zaskakuje. Różni je część niewidoczna: licencje kodeków, komponenty DRM, kanały aktualizacji, telemetria i usługi konta.

Jedno jest projektem, drugie produktem

Relacja komponentów wspólnego silnika Chromium i różnych dystrybucji przeglądarki

Chromium to projekt open source, udostępniony jako otwarty kod w 2008 roku razem z Chrome, którego kod jest hostowany we własnym repozytorium. Nie ma oficjalnego wydania w ścisłym tego słowa znaczeniu; do pobrania są stale budowane snapshoty, których numery wersji podążają za główną gałęzią. Chrome to produkt, który Google pakuje na tym projekcie po dodaniu do niego różnych rzeczy: ma markę, rytm wydań, politykę i obsługę klienta, a także ponosi koszty licencji i zgodności.

Kodeki i DRM

Komponenty open source podlegają ograniczeniom patentowym i licencyjnym, dlatego oficjalne kompilacje Chromium zwykle nie zawierają własnościowych kodeków, takich jak H.264 i AAC, ani Widevine DRM. W efekcie niektóre strony z wideo otwierają się, ale nie odtwarzają, a serwisy streamingowe takie jak Netflix i Spotify wprost odmawiają odtwarzania. Chrome płaci opłaty licencyjne i włącza to wszystko do swojej dystrybucji. Dystrybucje Linux często jednak uzupełniają dekodowanie systemowym ffmpeg, więc „Chromium nie odtwarza wideo” nie jest twierdzeniem absolutnym – zależy to od konkretnej kompilacji.

Sposób aktualizacji i rytm wersji

Chrome ma wbudowany aktualizator od momentu instalacji i po cichu aktualizuje się w tle, czego użytkownik prawie nie zauważa. Stabilna wersja przesuwa się o jedną wersję główną mniej więcej co cztery tygodnie, a dostępne są też kanały Canary (codziennie), Dev i Beta (co tydzień), na które mogą przełączyć się deweloperzy chcący wcześniej przetestować nowe funkcje. Chromium nie ma oficjalnych automatycznych aktualizacji: nowy snapshot trzeba pobrać i nadpisać samodzielnie. Rytm głównej gałęzi jest w przybliżeniu zsynchronizowany z Chrome, ale nie ma markowej stabilnej gałęzi, więc to, z której daty kompilacji korzystasz, zależy wyłącznie od ciebie.

Ta różnica wersji ma kluczowe znaczenie przy testach zgodności: numer wersji Chrome jest jednoznaczny, a snapshot Chromium ma tylko datę commita, przez co przy problemie trudno wyrównać środowiska.

Automatyczne aktualizacje to nie tylko wygoda, ale też kwestia tego, kiedy trafiają poprawki bezpieczeństwa. Poprawki luk w Chrome są dostarczane wraz ze stabilną wersją, a użytkownicy aktualizują się, nie zauważając tego. Użytkownik Chromium musi sam śledzić komunikaty bezpieczeństwa, ocenić, czy posiadana kompilacja zawiera poprawkę, i dopiero wtedy zdecydować, kiedy przejść na nowy snapshot. Ten czas pomiędzy jest ekspozycją na ryzyko.

Telemetria, synchronizacja i konto

Chrome domyślnie odsyła raporty o awariach i statystyki użycia, a po zalogowaniu na konto Google synchronizują się zakładki, hasła, historia i rozszerzenia. Chromium nie zawiera tych usług: brak wejścia do logowania na konto, brak backendu synchronizacji, a raporty o awariach też nie są domyślnie wysyłane. Dodatkowo funkcje zależne od usług Google, takie jak lokalizacja, sprawdzanie pisowni i tłumaczenie, w Chromium nie działają lub są ograniczone, ponieważ nie ma wbudowanego klucza API.

Zwykli użytkownicy i osoby grzebiące w silniku

Zwykły użytkownik nie ma powodu przechodzić na Chromium. Zaoszczędzone dane telemetryczne okupione są wideo, które się nie odtwarza, zakładkami, które się nie synchronizują, i aktualizacjami bezpieczeństwa, które trzeba samemu pilnować – nie warto. Ma to sens tylko wtedy, gdy wyraźnie nie chce się łączyć z usługami Google. Zainstalowanie Chromium i narzekanie, że streaming się nie otwiera, to najczęstsze źródło rozczarowania.

Odwrotnie, osoby potrzebujące czystego silnika częściej wybierają Chromium. Przy walidacji zgodności front-endu trzeba ustalić, czy problem leży w standardowym silniku, czy w poprawce producenta; pisząc skrypty automatyzacji, chce się zablokować wersję, żeby nie mieszały jej automatyczne aktualizacje; a tworząc własne dystrybucje i prowadząc dalszy rozwój, nie można obejść się bez jego licencji open source. Kłopoty zwykle nie wynikają z samego silnika, lecz z brakujących komponentów objętych licencją i dryfu wersji. Dlatego wiele osób instaluje oba: Chrome do codziennego przeglądania, a przypiętą wersję Chromium do testów i uruchamiania skryptów.

Co mówi „oparty na Chromium”

Gdy przeglądarka mówi, że jest oparta na Chromium, pewne jest to, że silnik renderujący i silnik JavaScript są takie same, a zachowanie stron, interfejsy rozszerzeń i protokół debugowania są w dużej mierze identyczne. Niepewne są domyślne ustawienia prywatności, backend synchronizacji, polityka telemetrii i kanały aktualizacji, a także to, o ile wersji odstaje od upstreamu. Nie wybieraj przeglądarki na podstawie samego tego zdania; sprawdź, co zmieniła względem upstreamu i co z niego usunęła. Z tego samego powodu porównanie Chrome i Chromium nie powinno zatrzymywać się na tym, czy interfejsy wyglądają podobnie; porównania warte są te części, które są lub nie są zainstalowane, które łączą się lub nie i które same się aktualizują lub nie.