Anzeige

Am Puls von Microsoft

Anzeige

Kurzer Einwurf: Kommende Einschränkungen bei Chromium sorgen für Zündstoff

DrWindows

Redaktion
Kurzer Einwurf: Kommende Einschränkungen bei Chromium sorgen für Zündstoff
chromium.png


Die Entscheidung von Google, den Zugriff auf private und nur für Google Chrome gedachte Schnittstellen bei Chromium zu beschränken, hatte ich an dieser Stelle ja schon mal bei uns verbloggt. Die entsprechenden Beschlüsse scheinen nun vor allem in der Linux-Welt für einige Aufregung zu sorgen. Führende Distributionen wie Fedora, Arch Linux, openSUSE, Debian und Slackware wollen Chromium deswegen aus ihren Repositories werfen, darauf aufbauende Distributionen wären entsprechend auch davon betroffen.

Bevor das auch noch in der Microsoft-Welt größere Kreise zieht, lasst mich das Ganze an dieser Stelle nochmal verdeutlichen, damit wir das richtig einordnen können:

Chromium ist ein OpenSource-Projekt, was unter der BSD-Lizenz steht und an dem neben Google auch noch zahlreiche andere Unternehmen wie Microsoft, Opera oder Samsung mitarbeiten. Viele Entwickler nehmen diese Plattform dann als Basis und bauen ihre eigenen Implementierungen darauf auf, um damit eigene Projekte zu realisieren. Besonders die größeren Browser wie Microsoft Edge, Opera, Vivaldi, Brave, Maxthon oder Yandex haben auch viel Arbeit in Funktionen wie die Synchronisation über einen entsprechenden Account – mit Ausnahme von Brave, die hier einen dezentralen Ansatz verfolgen – investiert. Gerade bei Microsoft erinnert ihr euch sicherlich noch daran, dass die Redmonder zusammen mit den Nutzern sehr intensiv diskutiert und Feedback eingeholt haben, nachdem die Variante beim alten Edge so eine Katastrophe war.

Es gibt neben den namhaften Vertretern aber auch zahlreiche kleinere Vertreter wie den Centbrowser oder den japanischen Kinza Browser, die zumindest teilweise auch eine Synchronisation über den Google-Account angeboten haben. Genau das will Google mit den kommenden Einschränkungen unterbinden und räumt dabei auch andere Sachen mit auf, die nur für Google Chrome bestimmt sind, genau wie die Implementierungen von Microsoft eben nur für Microsoft Edge gedacht sind. Google hat in dem entsprechenden Blogpost im Übrigen auch ausschließlich den Google-Account angesprochen, sodass die vorher synchronisierten Daten dort und lokal auf dem Rechner vorhanden bleiben und die Nutzer ihre Daten auch über Google Takeout herunterladen können.

Was bedeutet das für euch als Nutzer?

Wenn ihr einen Browser wie Edge, Chrome, Vivaldi oder Opera verwendet, der eine eigene Synchronisation über einen entsprechenden Account des Entwicklers mitbringt, kann euch die ganze Diskussion schlichtweg egal sein. Für euch ändert sich überhaupt nichts und Browser wie Edge werden bei Features wie der Synchronisation Mitte März natürlich nicht ihren Dienst einstellen. Kleinere Browser, die eben die privaten Schnittstellen verwendet und die Nutzung des Google-Accounts angeboten haben, stehen dafür natürlich vor einem Dilemma. Nutzer von Firefox und Safari sind sowieso ganz außenvor.

Dass Google ein dominanter Player im Bereich des Internets ist, stimmt zwar, greift aber mit Blick auf Chromium in der Art, wie bei der aktuellen Diskussion argumentiert wird, viel zu kurz. Tatsache ist letztlich, dass es sich bei Chromium mittlerweile um einen Industriestandard handelt, der sich nicht nur auf Browser beschränkt, sondern in verschiedenen Formen auch bei zahlreichen Desktop- und Mobile-Apps, Entwicklertools wie Qt und .NET und nicht zuletzt auch als Basis für die vielen verschiedenen JavaScript-Frameworks – einschließlich dem allgegenwärtigen Node.js – die tragende Rolle einnimmt.


Hinweis: Der Artikel wird möglicherweise nicht vollständig angezeigt, eingebettete Medien sind in dieser Vorschau beispielsweise nicht zu sehen.

Artikel im Blog lesen
 
Anzeige
Gute Frage, aber wie ich das einschätze, ist das eine reine Protestaktion, weil sie damit die Freiheit der Nutzer bedroht sehen. Ein ähnliches Drama hatten wir ja schon bei Linux Mint, die Chromium erst nicht mehr ausliefern wollten, weil Canonical das nur noch als Snap angeboten hat.

Ich warte da eigentlich nur noch auf die Forderung, Chromium zu forken. Wie gut das bei Gecko funktioniert hat, sieht man ja bei Pale Moon, und viele sehen ja auch in einem Community-Fork von Qt die Zukunft. Letztlich wird das qualitativ immer deutlich abstinken, weil man bei FOSS-Projekten - und unabhängigen sowieso - einen gewaltigen Entwicklermangel hat und da auch kaum die Ressourcen vorhanden sind, die große Entwickler haben. GTK nennen viele bei den Frameworks ja gerne als Paradebeispiel, aber die meisten Beiträge kommen da auch von Red Hat.
 
Also das übliche "mimimi". Denn technisch, wenn man Sync nicht komplett deaktiviert wie bei anderen Chromium-Builds, ist es doch nur eine sonstige Kompilation, wie man es auch bei woolyss bekommt. Allerdings kompilieren die ohne Sync und ansonsten wird auf die Repos verwiesen. Es muss aber einen Grund haben, warum selbst RobRich (und andere) mit "nosync" kompiliert, es gibt nur wenige Builds mit Sync.
 
Zuletzt bearbeitet von einem Moderator:
Abbilder von Chromium ohne Sync sind ja nun nicht so selten, sieht man ja unter anderem auch bei Ungoogled Chromium, Iridium oder SRWare Iron, die ja letztlich auch nur normale Chromium-Browser mit leicht anderen Flags sind. Dass es aber Derivate gibt/gab, die den Sync über den Google-Account angeboten haben, weiß ich selbst. Kinza aus Japan ist wie gesagt so ein Beispiel.

Für mich kommt das rüber wie ein Sturm im Wasserglas. Google hat ja explizit gesagt, dass sie das Chromium Sync Protocol nur in der Hinsicht einschränken, dass der Zugriff auf die Private APIs, die nur für Google Chrome gedacht sind, verhindert wird. Sie haben nie gesagt, dass sie den Rohbau an sich rauswerfen. Und wenn die ganzen Zwergenbrowser wirklich so viel wert auf einen unabhängigen Sync legen, steht es ihnen ja zum Beispiel frei, den Sync V2 von Brave zu nutzen oder auch zu forken, der steht unter der MPL 2.0 auf GitHub bereit.

Völlig rauswerfen könnten sie Chromium-Browser sowieso nicht. Unabhängige wie Arch Linux sind sowieso eher irrelevant, für jemanden wie SUSE wäre sowas sogar kompletter Selbstmord, wenn man bedenkt, dass sie SLE und openSUSE wesentlich enger zusammenfassen wollen. Gleiches gilt für IBM/Red Hat im Bezug auf Fedora, und Debian hat ja auch durchaus Einfluss im Enterprise-Bereich. Ich glaube zwar nicht, dass sie Vertreter wie Edge, Opera und Brave blockieren würden, aber wenn sie das tun sollten, was haben sie dann? Firefox hat mit der Gecko-Engine nicht umsonst große Probleme gegen Chromium und alles andere ist qualitativ und von der Relevanz her noch deutlich weiter unten.
 
Ein Chromium Browser unter Linux ohne Sync Funktion dürfte sicher an Beliebtheit verlieren. Manche Linux Nutzer wechseln zu Googles Chrome, andere dürften zu Firefox wechseln oder zu einen anderen Chromium basierten Browser. Die Chromium Lesezeichen sind nicht weg, nur der Sync mit Chrome oder Chromium Geräten funktioniert nicht mehr. Fedora will die Google Sync Funktion aus Chromium schon ab sofort deaktivieren. Dadurch sieht man schneller, welche Alternativen die Benutzer wählen.

Google verzichtet dadurch auf Daten in Form von Lesezeichen oder Browser Verläufe der Chromium Nutzer. Mal sehen, ob Chromium OS auch seine Verbindungen zu Google verliert.
 
Ein Chromium Browser unter Linux ohne Sync Funktion dürfte sicher an Beliebtheit verlieren. Manche Linux Nutzer wechseln zu Googles Chrome, andere dürften zu Firefox wechseln oder zu einen anderen Chromium basierten Browser.
Dass tatsächlich viele zu Firefox wechseln, nachdem Mitchell Baker ihren Blogpost zum Deplatforming Anfang Januar veröffentlicht hat, wage ich mal zu bezweifeln. Wesentlich wahrscheinlicher wäre in meinen Augen, dass Brave einen enormen Schub bekommt und die Zahl von aktuell 24 Millionen Nutzer kräftig wachsen dürfte. Viele reichweitenstarke Linux-YouTuber trommeln aktuell auch für den Browser und sein Grundkonzept mit dem IPFS-Support, Sync V2 und Tor passt auch gut in den Trend zur Dezentralisierung und Federation, der in der FOSS-Community mittlerweile eingesetzt hat. Mozilla hat auf sowas eigentlich keine Antworten.

Davon mal abgesehen: Wenn die Linux-Nutzer tatsächlich proprietäre Browser vermeiden wollen und auch keine speziellen Nerds sind, die sowas wie Qutebrowser lieben, wirds halt schnell eng. Die Goanna-Ecke hat ohnehin mehr als genug Probleme, die Browser auf Basis der QtWebEngine werden auch nur unzureichend gepflegt (vor allem Falkon, der der massentauglichste Browser wäre), und bei den Gecko-basierten Browsern sind viele entweder abgeschlagen (SeaMonkey) oder unten durch (Waterfox). GNU IceCat ist sehr speziell, Purebrowser und Abrowser sind nur Firefox ohne Label, und LibreWolf als neuer Hype muss sich erst noch beweisen. Und da vielen von denen genau wie Epiphany auf Linux beschränkt sind, fällt das für Leute, die crossplattform unterwegs sind, ohnehin raus. Das gilt auch für die meisten Chromium-Derivate wie Iridium oder Ungoogled Chromium, wobei das mehr zusammengetackert als wirklich entwickelt ist.

Unterm Strich wäre Brave da für die breitere Masse der beste Ausweg. Einige haben zwar auch Vivaldi mit auf der Liste, aber mit seinen knapp zwei Millionen Nutzern wirft der bei aller Liebe nicht mal ansatzweise die Masse von Brave in den Ring, der selbst trotz starkem Wachstum immer noch ein Zwerg ist. Und Chrome dürfte für die meisten unter Linux sowieso nur eine Notlösung sein.
 
Seit wann ist Google nicht mehr am "mitlesen" interessiert? Gibts da echt ein "zuviel"?
Oder waren die Sync-APIS so designed bzw. benutzbar das Google etwa leer ausging?
 
Wundert mich, daß OSS Vertreter so scharf darauf sind ihre Daten bei Google zu lagern, daß sie mit Rauswurf drohen.

Lest die verlinkte Newsgroup wenn ihr mehr wissen wollt.
Google argumentiert mit der Sicherheit seiner Nutzer :LOL: .


Möglicherweise kann man einfach die API Keys aus Chrome klauen und Sync weiternutzen... zumindest theoretisch.

We won't remove the API from your key, but we'll limit the quota to the quota for development. It's true that this will make the keys unsuitable for production use.
In that case, what's stopping us from switching our Chromium builds to use Chrome's keys? [1] [2]

And unless you obscure Chrome's keys, how does killing our keys improve user data security?


[1] google_apis/google_api_keys.cc - chromium/src - Git at Google
[2] adobe/chromium

The keys being public implies that user data safety is not significantly improved by limiting the keys of Linux distributions shipping Chromium.

I honestly don't see the issue if a Chromium build were to use Chrome's keys. They have been publicly known since 2012 and have not been rotated even once during the past 8 years or so. Unless you are planning to obfuscate them in the chrome binary, this is nothing more than a security theater, in my opinion.
 
Unterm Strich wäre Brave da für die breitere Masse der beste Ausweg. Einige haben zwar auch Vivaldi mit auf der Liste, aber mit seinen knapp zwei Millionen Nutzern wirft der bei aller Liebe nicht mal ansatzweise die Masse von Brave in den Ring, der selbst trotz starkem Wachstum immer noch ein Zwerg ist. Und Chrome dürfte für die meisten unter Linux sowieso nur eine Notlösung sein.

Das Rennen dürfte ein Browser machen, der gute Unterstützung von den Linux Distros bekommt. Gibt sicher auch Linux Nutzer, die keine Open Source oder Datenschutz Fanatiker sind. Die Zeit wird es zeigen. Firefox ist bei vielen Distros der Standard Browser. Ein Chromium Browser ohne Google Verbindungen kann auch freier agieren und damit Firefox unter Druck setzen.
 
@Beebo99

Keine Frage, aber den Trend zur Dezentralisierung und Federation gibt es in der FOSS-Community ja trotzdem. In der letzten Zeit gewinnen Projekte wie Mastodon, PeerTube, Matrix, LBRY, Odysee usw. immer mehr Anhängerschaft in diesen Communities (zusätzlich zu Projekten wie Mumble, BitTorrent etc., die es schon ewig gibt). Neben Kryptowährungen gehört diese Klientel genau zu der Zielgruppe, die Brave anspricht, und unter den Evangelisten bekommt der Browser auch immer mehr Rückendeckung.

Das Problem für Firefox ist, dass Mozilla mit ihren Entscheidungen immer mehr in Ungnade fallen, und da isses egal, ob man die Enthusiasten oder die Pragmatiker nimmt. Die Enthusiasten verweisen auf Dinge wie die Integration von Pocket, Telemetrie-Geschichten wie Mr. Robot oder eben den Blogpost zum Deplatforming von Mitchell Baker. Die Pragmatiker sehen unter anderem die zunehmenden Performanceprobleme von Gecko gegenüber Chromium oder das wichtige Arbeiten wie eine neue Lesezeichenverwaltung etc. einfach nicht angegangen werden. Und der Ottonormalnutzer merkt einfach, dass ein Chromium-Browser wie Edge oder Opera deutlich besser und flüssiger funktioniert als Firefox, quelloffen hin oder her.

Meistens endet das, wenn du der FOSS-Community zu sehr auf die Nüsse gehst, ohnehin in einem harten Fork, das hat die Geschichte der letzten 10 bis 15 Jahren gezeigt. Bei OpenOffice war es LibreOffice, bei MySQL war es MariaDB, bei Node.js war es Deno, nach Microsofts Kauf von npm sind alle zu yarn als Paketmanager für Node.js geflüchtet, bei Qt steht der durch die Community betreute Fork schon am Horizont (wenn sich KDE und die Qt Company nicht zusammenraufen), und bei Firefox könnte das unter Umständen auch so enden. Gibt ja schon Unternehmen wie Purism, die eine eigene Version von Firefox ohne Label pushen, die aber trotzdem weitgehend vom aktuellen Sourcecode her kompiliert wurde (mit dem Unterschied, dass sowas wie Pocket fehlt). Wenn sich eine Foundation findet und unter deren Dach die Projekte wie LibreWolf, Purebrowser, Abrowser etc. ihre Arbeiten zusammenwerfen, schließe ich sowas auch nicht aus.

Wie gut das nachher am Ende von der Qualität und Betreuung her wird, steht auf einem ganz anderen Blatt. Jedenfalls bewegt sich Mozilla momentan ziemlich nah an der Toleranzschwelle.
 
Mozilla lernt halt auch nichts.
Statt weiter dem Mainstream-Chrome hinterherzulaufen, könnte man wieder etwas mehr auf die Enthusiasten zugehen.

@Topic
Betrifft auch Chromium OS, was nur zur Onlinenutzung gedacht ist.
 
Was Brave angeht, bin ich immer noch kein Freund davon. Interner Werbeblocker, ok, aber das ist wie bei Firefox, wie wir neulich wieder festgestellt haben ("Benutzerdefiniert", alles markiert, "in allen Fenstern").

Was mich persönlich stört, ist der Online-Installer, man muss erst suchen lassen, um via "community" auf github zu laden und auf Seite 3 oder 4 die letzte Final (1.19) zu finden, während beta, dev und nightly bei 1.21 sind.
Dazu die Fülle an Builds. Das ist nicht "Kunden"-freundlich, anders als Chromium oder Firefox.
 
Google möchte mit der nächsten oder einer der nächsten neuen Chrome Versionen Drittanbieter Cookies generell blocken. Dafür soll eine Google KI den Browserverlauf analysieren und den Nutzer einer Gruppe zuordnen. Google wird in den Open Source Browser Chromium keine geschützte KI oder eine Schnittstelle zu einer Google KI einbauen können. Nur beim eigenen Chrome kann sich Google eine Einverständniserklärung für die KI vom Nutzer holen, beim Chromium geht das nicht. Der Chrome könnte sich mehr vom Chromium entfernen. Mal sehen, wie sich das noch entwickelt.
 
Anzeige
Oben