"Chromium ist ja nicht so schlimm...

"Chromium ist ja nicht so schlimm... (42 Beiträge, 1416 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

...denn Google will das Web schließlich verbessern, was gut ist. Und außerdem ist's ja Open Source." Right?

Sprüche wie diese oder ähnliche gab's Zuhauf, als Microsoft offiziell bekanntgab¹, dass man in Zukunft, anstatt die eigene Engine zu pflegen, auf Chromium (und damit Blink + V8) setzen wird, denn im Endeffekt kann's ja nur gut für den User sein, wenn es de facto nur noch eine einzige Engine gibt, die man als Web-Entwickler berücksichtigen muss, und das verbessert dann wiederum die vielgeliebte "Benutzererfahrung".

Dummerweise hat man mit Google einen Konzern hinter Chromium stehen, der es nicht nur mit Datensparsamkeit nicht ganz so hat, wie man es sich als Nutzer eigentlich vorstellt, sondern auch gleichzeitig einer der größten Werbeanbieter im Netz ist, und so ist es nicht verwunderlich, dass man im aktuellsten Entwurf der Manifest-Spezifikationen² so lustige Änderungen wie diese findet:

WebRequest: Restrict the blocking capabilities of the webRequest API.

Macht man sich dann die Mühe, nicht nur die Zusammenfassung zu lesen, wird's tatsächlich höchst interessant:

In Manifest V3, we will strive to limit the blocking version of webRequest, potentially removing blocking options from most events (making them observational only).

Was an und für sich nicht ein Problem ist, denn Google liefert (bekannterweise) auch gleich einen "brauchbaren" Nachfolger für eine deprecated API mit:

The declarativeNetRequest API³ is an alternative to the webRequest API. At its core, this API allows extensions to tell Chrome what to do with a given request, rather than have Chrome forward the request to the extension.
...
This allows us to ensure efficiency since a) we have control over the algorithm determining the result and b) we can prevent or disable inefficient rules. This is also better for user privacy, as the details of the network request are never exposed to the extension.

Ineffiziente Blockierregeln deaktivieren bzw. verhindern? Wer sich die Mühe macht und durch die API-Dokumentation³ stöbert, kann auch relativ einfach feststellen, dass declarativeNetRequest's primärer speedup factor durch die Limitierung auf maximal 30000 Regeln zustande kommt, und eher weniger durch das Vermeiden asynchroner Requests von der jeweiligen Erweiterung.

Neben der aktiven Sabotierung der Performance von Browsern, die nicht auf Chromium basieren⁴, sowie der Flutung des Internets mit schwachsinnigen und halbgaren Standards (dazu gab's von mir schon einmal einen Beitrag, der leider im Tratsch-Bereich für alle Ewigkeiten verschwunden ist...) haben wir jetzt also eine weitere Innovation des Konzern, dessen Mantra bis vor ein paar Jahren noch "Don't be evil" lautete.

¹: https://blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration/
²: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit
³: https://developer.chrome.com/extensions/declarativeNetRequest
⁴: https://twitter.com/cpeterso/status/1021626510296285185

Man kann nur allen, die man kennt, nachdruecklich nahelegen, Firefox zu benutzen. Gecko braucht wieder mehr Gewicht bei den Coolaid-trinkenden Webdevs, sonst ist das Web endgueltig verloren.

Und dann...

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

Gecko braucht wieder mehr Gewicht bei den Coolaid-trinkenden Webdevs, sonst
ist das Web endgueltig verloren.

Aber Gecko ist doch so langsam. Und welchen Grund hätte ich, Firefox überhaupt zu nutzen, wenn eine komplett veraltete, absolut grottenschlecht performende Erweiterungsschnittstelle entfernt wurde, damit der Browser in seiner Gesamtheit endlich in 21. Jahrhundert überführt werden kann?

Bis vor zwei Jahren sah das Web eigentlich noch ganz "meh, okay" aus, aber mittlerweile kannst dich bei den ganzen FE-Überarbeitungen nur noch an einem Strick erhängen. Responsive Design, welches mit irgendwelchen zusammengekleisterten Frameworks und Libs zusammengehalten wird und dir bei mobilen Endgeräten den Akku leernuckelt, weil erst einmal 4500 ms CPU-Zeit draufgehen, damit der Dreck überhaupt pfunziwunzifunztatatut. Das ist mit Sicherheit nicht die Kernidee hinter Responsive Design.

Bin vor kurzem auch wieder auf Firefox als Hauptbrowser umgestiegen und habe es nicht bereut.

Noch nie den "Hauptbrowser", Firefox, überhaupt gewechselt.

mfg

Und ich habe nach wie vor einen hoffnungslos veralteten Presto-Unterbau, allerdings mittlerweile nur mehr fürs GH-Forum, derStandard (werbefreie Darstellung, wenn man die Cookies regelmäßig löscht), generell für später zu lesende News-Artikel und vor allem als RSS-Reader, wo mir noch keine befriedigende Browser-Alternative untergekommen ist. (Auch aufgrund des Alters) natürlich nur unter eingeschränkten Benutzerrechten und sehr restriktiven Default-Einstellungen.

Ansonsten immer nur Firefox als erste Alternative (mit mehreren Profilen, eins z.B. lediglich für E-Commerce-Sachen) genutzt, der seit einigen Versionen angenehm schnell geworden ist. Umso weniger mit Opera noch zufriedenstellend funktioniert, desto mehr wandert zum Firefox.

Chromium verwende ich lediglich in Form von Vivaldi als Video-Abspielbrowser für meinen Uralt-Opera (via Open with) und zum Überprüfen, ob die Entwickler vom Funktionsumfang irgendwann dorthin kommen, wo sie vor zig Jahren mit Opera Presto schon mal waren.

RSS-Reader, wo mir noch keine befriedigende Browser-Alternative untergekommen
ist

Ich verwende Feedly im Browser und als Android-App. Ich bin zufrieden aber ist vielleicht nicht jedermanns Sache.

Ist mir schon mal untergekommen, aber war nicht so richtig für meine Zwecke passend (brauch z.B. keine Synchronisation über mehrere Geräte).

Hab noch zusätzlich RSSOwl für reine RSS-Video-Feeds (hauptsächlich Youtube).

RSS-Reader, wo mir noch keine befriedigende Browser-Alternative untergekommen ist

ich war lang bei netvibes - hab dann aber dann was auf github gefunden. taugt mir total und ist aktuell noch in entwicklung: https://tt-rss.org/ (gibts auch als App)

https://tt-rss.org/

Thx, kenne ich noch nicht. Werd' mal einen Blick reinwerfen.

Faustregel: 1 Langstreckenflug emittiert (pro Passagier) so viel CO₂ wie 1 Jahr Autofahren (pro Auto)

24.01.2019, 19:40 Uhr - Editiert von Lazy Jones, alte Version: hier

Einen neuen Browser mit diesen Charakteristika wuerde ich auch verwenden/unterstuetzen - aber ich glaube nicht, dass sowas kommen wird oder auch nur kann; dafuer ist das "moderne" Web inzwischen viel zu komplex und vor allem unnoetig kompliziert geworden.

Safari gibt es fuer meine Plattform nicht - wuerde ich aber auch dann nicht nutzen wollen, da nicht quelloffen. Ich bin mit Firefox als Browser-Werkzeug gegenwaertig ziemlich zufrieden, auch wenn ich die juengsten Fehltritte von Mozilla (der Mr.-Robot-Werbe-*PIEP*up, die Pocket-Zwangsintegration, etc.) aehnlich kritisch bewerte wie du. Dass die weltfremden Deppen in deren Kooperationsabteilungen (oder wo auch immer diese Idiotien ihren Ursprung finden) die Haxn nicht stillhalten koennen, koennte der ganzen Foundation irgendwann das Genick brechen...

Aufgrund der Hoffnung auf eine Loesung wie in Absatz 1 auf die sich bietende Alternative aus Absatz 2 zu verzichten, halte ich fuer ziemlich vermessen, und einen klassischen Fall von "perfect is the enemy of good"

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

Ich bin ein Fox User seit ewigen Zeiten. Aber das Ding ist wirklich saulangsam.

Seit e10s ist Firefox bei mir ebenbürtig zu Chromium-basierten Browsern, wobei man Vivaldi hier eigentlich dezidiert benchen müsste, denn die tiefgehenden Erweiterungen des Browsers sind alle auf CSS und JS-Basis und bremsen den Browser dementsprechend stark aus, was das Aufrufen und Rendern von Seiten angeht.

Ich verwende Google gezwungenermaßen nur am Handy. Sonst habe ich Fox, IE7, Edge am PC und Apple am iPad.

Der Fox fühlt sich einfach von allen am langsamsten an.

https://venturebeat.com/2018/07/09/browser-benchmark-battle-july-2018-chrome-vs-firefox-vs-edge/

Pffft, ja mit sowas wie einem popeligen Kabylake Zweikerner kann ich nicht wirklich dienen.

Willst jetzt Schwanzvergleichen, oder was?

Mein Laptop mit genau der CPU wurde erst vor 4 Monaten abgelöst. Die Performance unter Win7 war vollkommen ausreichend. Und ich habe mitunter monströse Excels oder MS Projects am laufen.

Ich hab mein E7450 mittlerweile auch schon aus dem Fenster geworfen. Das Ding wurde mit zwei Kernen für meine Einsatzzwecke einfach viel zu langsam. Word und Excel war noch ganz erträglich, aber alles andere war mit dem Ding schon echt lahmarschig.

Mein PC ist jetzt auch schon wieder in die Jahre gekommen, aber ich hab beim Umstieg von Chrome zu Firefox keine Geschwindigkeitseinbußen gemerkt, eher im Gegenteil.

ich glaube nicht, dass sowas kommen wird oder auch nur kann; dafuer ist das
"moderne" Web inzwischen viel zu komplex und vor allem unnoetig kompliziert
geworden.

Da müsste man einiges weglassen. Kenne aber auch niemanden, der sich das antun würde.

Konqueror gibt es aber noch immer - pfuscht Google da auch schon mit rein, oder ist der noch immer nicht brauchbar?

…………………………………………………………………………………………………………………………………………………………………
Wenn ich auf Provokationen nicht reagiere, liegt das wohl daran, dass ich sie dank "Plonk" nicht sehen kann.

Faustregel: 1 Langstreckenflug emittiert (pro Passagier) so viel CO₂ wie 1 Jahr Autofahren (pro Auto)

Zweiteres. Konqueror ist tatsächlich der Minimalismus in Reinform, kenne aber auch niemanden, der sich das Ding freiwillig antut, nicht einmal der größte ASCII-Freak.

Aber an der Engine bzw. deren Kompatibilität kann das nicht liegen? Oder ist das kein aktuelles WebKit, sondern noch immer uralt-KHTML?

…………………………………………………………………………………………………………………………………………………………………
Wenn ich auf Provokationen nicht reagiere, liegt das wohl daran, dass ich sie dank "Plonk" nicht sehen kann.

Faustregel: 1 Langstreckenflug emittiert (pro Passagier) so viel CO₂ wie 1 Jahr Autofahren (pro Auto)

Das ist tatsächlich noch KHTML in ihrer Protoform. Wenn man sich den Quellcode anschaut, wird einem erst bewusst, wie dermaßen viel Dreck eigentlich heutzutage (PWAs und RIAs sei dank) in einem modernen Browser drinnen ist. Das sind fast eigene kleine Betriebssysteme.

Tja, alles wegwerfen und zurück zu Chimera, wo man sogar für die image-MIME-types externe Filter-pipelines (zu .ppm) definieren konnte...

…………………………………………………………………………………………………………………………………………………………………
Wenn ich auf Provokationen nicht reagiere, liegt das wohl daran, dass ich sie dank "Plonk" nicht sehen kann.

Faustregel: 1 Langstreckenflug emittiert (pro Passagier) so viel CO₂ wie 1 Jahr Autofahren (pro Auto)

Yay, it's IE6 all over again...

________________________________________________________________________

There's a typo in the Bible. It should read "The geek shall inherit the earth".

Es birgt schon eine gewisse Ironie, wenn ein Browser, der ursprünglich dazu entwickelt wurde, um sich gemeinsam mit Firefox aus dem Joch der Tridentifizierung zu befreien, jetzt dazu ansetzt, um das gesamte Web irgendwelchen Schwachsinnsstandards zu unterwerfen.

Weißt, bei Trident war das Klump wenigstens einfach nur broken, mit Chromium ist's so richtig broken und es gibt keine Alternative, weil der moderne WebDev anscheinend zu blöd ist, sich einfach an 0815-Standards vom W3C zu halten.

Der WebDev könnte vielleicht schon, nur hat er die gleichen Probleme, wenn nicht noch größere, als zu Zeiten von IE6. Wenn er's nicht so macht wie der Marktleader diktiert, ist seine Seite inkompatibel, langsam oder funktioniert nicht.

________________________________________________________________________

There's a typo in the Bible. It should read "The geek shall inherit the earth".

Er hat definitiv größere Probleme. MS kontrollierte nur den Browser, das OS und einige Webseiten, Google hingegen hat bei vielen 3rd Party Dienstleistungen die Hohheit. Beispiele Gefällig? ReCaptcha, Analytics, AdSense etc. pp. Und nachdem der Blödsinn ebenfalls primär für ihren eigenen Browser optimiert wurde, kannst dir das Ergebnis ausmalen.

der ursprünglich dazu entwickelt wurde, um sich gemeinsam mit Firefox aus dem
Joch der Tridentifizierung zu befreien,

Rührende Geschichte.

Als ob Google nicht von Anfang an die Kontrolle über das Browsing-Verhalten der User haben wollte.
…………………………………………………………………………………………………………………………………………………………………
Wenn ich auf Provokationen nicht reagiere, liegt das wohl daran, dass ich sie dank "Plonk" nicht sehen kann.

Faustregel: 1 Langstreckenflug emittiert (pro Passagier) so viel CO₂ wie 1 Jahr Autofahren (pro Auto)

So blöd es klingen mag, aber nope: Als das Chromium-Projekt initiiert wurde, ging's tatsächlich darum, den unsicheren und veralteten Crapxplorer so schnell wie möglich loszuwerden - natürlich nicht aus altruistischen Motiven, sondern weil man, als aufstrebender Internetkonzern, - schlicht und ergreifend Angst hatte, dass der Dreck irgendwann einmal eine Datenpanne in epochalem Ausmaß verursachen würde.

Natürlich hat sich das Ganze relativ schnell verschoben, als man erkannte, dass man es mit einem Browser-Monopol viel leichter hat die Daten der Nutzer abzugreifen und WebDevs in einen Vendor-Lock-in zu treiben, besonders dann, wenn die Leute schon einmal ans "Internet" (für viele User auch besser bekannt als "Facebook" oder "Google") angefixt wurden.

So blöd es klingen mag, aber nope: Als das Chromium-Projekt initiiert wurde,
ging's tatsächlich darum, den unsicheren und veralteten Crapxplorer so schnell
wie möglich loszuwerden - natürlich nicht aus altruistischen Motiven, sondern
weil man, als aufstrebender Internetkonzern, - schlicht und ergreifend Angst
hatte, dass der Dreck irgendwann einmal eine Datenpanne in epochalem Ausmaß
verursachen würde.

Faustregel: 1 Langstreckenflug emittiert (pro Passagier) so viel CO₂ wie 1 Jahr Autofahren (pro Auto)

24.01.2019, 20:05 Uhr - Editiert von Lazy Jones, alte Version: hier

Mozilla wurde damals schon tatkräftig von Google unterstützt - nicht nur finanziell (durch den Einkauf als default SE), sondern auch bei der Entwicklung.

Der Faden für Chromium selbst beginnt weit früher - nämlich bei der Entwicklung von Android. Als die ersten Eval-Builds fertiggestellt wurden und man einen Browser brauchte, bastelte man sich einen KHTML/WebKit-basierten Browser zusammen, da Gecko im damaligen Zustand (mehr oder weniger) als unportierbar galt (viel Spaß, den x86-Intrinsics-Spaghetticode zu portieren, Multiplattform my ass). Irgendwann hat man den Faden dann weitergesponnen und kam so zu Chrome.

bastelte man sich einen KHTML/WebKit-basierten Browser zusammen, da Gecko im
damaligen Zustand (mehr oder weniger) als unportierbar galt (viel Spaß, den
x86-Intrinsics-Spaghetticode zu portieren, Multiplattform my ass). Irgendwann
hat man den Faden dann weitergesponnen und kam so zu Chrome.

Faustregel: 1 Langstreckenflug emittiert (pro Passagier) so viel CO₂ wie 1 Jahr Autofahren (pro Auto)

Kommt der Sache schon nahe. KHTML/WebKit war einfach weitaus portabler als vergleichbare Engines. Man hätte sich durchaus bei Opera einkaufen können, die Presto ja für Nokia auf ARM portiert haben, da scheiterte es aber afaik an einem Abkommen zwischen Nokia und Opera.

Willkommen zum nächsten Schritt des Vendor Locks.

Wie lange werden wohl Unternehmen brauchen, um zu erkennen, dass ihre super fancy- leider performance unterirdischen - angemieteten Cloud Lösungen (Azure, AWS, ...) wieder nur ein weiterer Vendor Lock sind. Wenigstens migrierens grad alle weg von Notes/Domino, nur leider hin zu Outlook/Exchange/Sharepoint. Ob die wissen, dass sie in 10 Jahren genau wieder dort sind wo sie gestern waren, nur um €00000 ärmer? Eben nicht, also weg vom pösen Ie/Edge zum fancy Chrome.

Es passt einfach alles so herrlich ins Bild, dass es nur zum Heulen ist, wennst ein Mensch und kein Manager bist.

pong
Satire erfordert Intelligenz beim Empfänger.

Ich bin da technisch nicht so weit drinnen, aber Frank Rieger hat's IMHO auf Twitter schön auf den Punkt gebracht:

"The biggest performance bottleneck in normal web browsing is ... advertising. Even thinking about breaking @ublockorigin for "performance reasons" ist far removed from the reality of normal browser users."

Nur zur Info: Google hat die Idee von Apple geklaut. Dort (in Safari) ist schon seit einiger Zeit eine ähnliche Technik zum blockieren von Werbung vorgeschrieben.

Es funktioniert auch eigentlich ganz gut aber die Funktion der AdBlocker wird dadurch eingeschränkt.

Najo, ich lass' mir gerne einreden, dass die aktuelle webRequest API alles andere als geil ist, werden doch sämtliche Requests durch die Erweiterung verwaltet, aber Safari macht's dann doch a bisserl anders:

1. liegt die Anzahl der max. Regeln (pro Instanz!) bei 50k
2. lässt sich die Beschränkung durch Aufteilung auf mehrere Subprozesse umgehen - das wird bspw. von 1Blocker X gemacht, damit lassen sich dann bis zu 350.000 Regeln festlegen

declarativeNetRequest ist prinzipiell gleich (max. Anzahl der Regeln 30k), mit dem Unterschied, dass Chromium hier keine Mehrfachinstanzierung (zumindest aktuell) zulassen soll und der Browser - und das ist's größte Problem - gewisse Regeln nach eigenem Gutdünken einfach aussetzen kann. Bei einem Browser, der primär von einem der größten Werbeanbieter der Welt entwickelt wird, ist die Optik daher reichlich schief.

26.01.2019, 23:08 Uhr - Editiert von User587913, alte Version: hier

Ich bin der letzte, der gerne freiwillig zu 96,31%-ig tote Threads wieder zum Leben erweckt, aber "Don't be evil" geht nach einer gefühlten halben Ewigkeit in die nächste Runde und holt zum vollen Rundrumschlag der Schwarmdummheitsverbreitung aus. Wie sieht diese Runde nun genau aus? Nachdem man auf das wertvolle Feedback zahlreicher Entwickler gehört hat, kam man zum Entschluss, dass man die webRequests API doch nicht vollständig in die Obsoleszenz verdrängen, sondern stattdessen nur noch die Blockingfähigkeiten beschränken wird.

Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments)

Der wirklich wichtige Teil wurde hervorgehoben, denn scheinbar kam man bei Google nun zum Entschluss, dass die Performance von Chromium doch nicht ganz so sehr darunter leiden wird, wenn man doch nur die Blockingfähigkeiten selektiv auf Nutzer mit im Browser aktivierter Enterprise-flag beschränkt.

An den grundsätzlichen technischen Einschränkungen hinter der im ManifestV3 vorgeschlagenen declarativeNetRequests API hat sich bislang nicht viel geändert. Die Anzahl der maximalen statischen Regeln wurde beibehalten, dafür hat man jetzt 5.000 dynamische Regeln hinzugefügt, die von der jeweiligen Erweiterung in der Laufzeit reingepfuscht werden können.

The first and IMO largest change is that Chrome now has support for dynamic modification of DNR rules ... DNR has two groups of rules: static rules declared in JSON files and dynamic rules set at runtime. ... We are planning to raise these values but we won't have updated numbers until we can run performance tests to find a good upper bound that will work across all supported devices.

Eine großartige Änderung, welche die Beschränktheit der API auch bis auf Weiteres nicht umgeht und webRequest auch weiterhin zur API der Wahl macht. Diese API steht dummerweise den eigenen wirtschaftlichen Interessen im Wege:

Technologies have been developed to make customizable ads more difficult or to block the display of ads altogether and some providers of online services have integrated technologies that could potentially impair the core functionality of third-party digital advertising. Most of our Google revenues are derived from fees paid to us in connection with the display of ads online. As a result, such technologies and tools could adversely affect our operating results.

Don't be evil - wenn dir jemand seinen Finger (also wertvolle Nutzerdaten) reicht, dann reiße ihm sogleich den gesamten Arm mitsamt der Hälfte des Torsos ab, indem man den Nutzer mit dem Dünnschiss des Internets des 21. Jahrhunderts bombardiert ohne ihm eine Möglichkeit zu geben, sich dagegen zur Wehr zu setzen.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung