In der vergangenen Woche hatte sich breiter Widerstand gegen Federated Learning of Cohorts (FLoC), Googles neue Strategie zum Tracking der Anwender des Chrome-Browsers zu Werbezwecken formiert. Jetzt hat auch WordPress als das mit rund 41 % Marktanteil am weitesten verbreitete CMS Stellung bezogen.
FLoC als Sicherheitsrisiko
Der Vorschlag eines WordPress-Entwicklers vom Wochenende plädiert dafür, FLoC als Sicherheitsrisiko einzustufen und dementsprechend generell zu blockieren. Dazu liefert er gleich einen Patch mit vier Zeilen, der genau das tut. Es gehe darum, die Webseitenbetreiber zu schützen, denen gar nicht bewusst sei, dass Google den Anwendern FLoC per Opt-out weltweit unterschieben möchte. In Europa sind wir derzeit noch durch die DSGVO geschützt. Die Zukunft wird zeigen ob FLoC damit kompatibel ist.
Mehrheit stimmt zu
Durch die Einstufung als Sicherheitsrisiko seien die Entwickler in der Lage, FLoC kurzfristig zu sperren, ohne auf WordPress 5.8 zu warten, dass erst im Juli zur Veröffentlichung vorgesehen ist. Admins, die FLoC bewusst zulassen möchten, wüssten sowieso, was dafür zu tun ist. Ein Schalter zum Ein- und Ausschalten von FLoC könne in einem späteren Release folgen. Bereits jetzt steht ein Plug-in zum Sperren von FLoC für WordPress bereit. Die überwiegende Mehrheit der kommentierenden Entwickler stimmen zu, dass Handlungsbedarf bestehe und FLoC zur sofortigen Sperrung als Sicherheitsrisiko einzustufen sei.
Predatory Targeting
Die Electronic Frontier Foundation (EFF) sieht dagegen eher Risiken für die Privatsphäre, wenn sie schreibt: »Die Technologie vermeidet zwar die Datenschutzrisiken von Drittanbieter-Cookies, aber sie wird dabei neue Risiken schaffen. Sie kann auch viele der schlimmsten Probleme mit verhaltensbezogenen Anzeigen verschärfen, die nicht mit dem Datenschutz zusammenhängen, wie z. B. Diskriminierung und Predatory Targeting«.
Seit einiger Zeit tüftelt Google zusammen mit dem W3C und anderen am Projekt Privacy Sandbox, einem Werkzeugkasten, der den Schutz der Privatsphäre ernst nehmen und trotzdem zielgerichtete Werbung erlauben soll. Durch den in letzter Zeit zunehmenden Widerstand gegen das Tracking durch Cookies aus dritter Hand sah sich Google zum Handeln gezwungen, denn Werbung ist die Haupteinnahmequelle des Unternehmens.
»Föderiertes Lernen in Gruppen« klingt harmlos…
Eines der Werkzeuge in der Box ist FLoC, was für »Federated Learning of Cohorts« und im Deutschen etwa für »Föderiertes Lernen in Gruppen« steht. Hier formiert sich in den letzten Tagen eine Front von Gegnern diese Technik. Die Kritik geht dahin, dass sich mit FLoC die Situation keineswegs verbessere, einige Kritiker halten es sogar für gefährlicher, denn dabei wird eine ID erzeugt, von der Kritiker sagen, sie erlaube Fingerprinting.
…ist es aber nicht
FLoC soll interessenbasierte Werbung ohne Cookies ermöglichen, indem Unternehmen, die heute das Surfverhalten von Einzelpersonen per Cookie beobachten, stattdessen das Verhalten von Gruppen (Kohorten) tausender ähnlich interessierter Personen verfolgen. Der Browser stellt dazu die Interessengruppen zusammen. Das Problem mit Cookies aus dritter Hand ist, dass sie Benutzer persönlich identifizieren können und daher besonders in Europa Datenschutzbedenken aufwerfen. FLoC läuft dagegen lokal im Browser und analysiert anstelle eines persönlich identifizierbaren Cookies das Surfverhalten, indem es Anwender mit anderen Personen mit ähnlichen Interessen gruppiert.
FLoC wird weltweit in Googles Browser Chrome eingeführt, einige Länder sind in der Testphase seit Kurzem freigeschaltet, Europa bisher noch nicht. Bis Mitte Juli und Chrome 91 soll die Technik weltweit ausgerollt sein und nach dem Opt-out-Prinzip funktionieren, wonach der Anwender der Verwendung von FLoC explizit widersprechen muss. Somit kann man davon ausgehen, dass derzeit viele Anwender ungewollt Tester von FLoC sind. Nach dem Ende der Tests sollen Cookies aus dritter Hand in Chrome zum Jahresende blockiert sein. allerdings ist derzeit noch unklar, ob FLoC überhaupt mit der DSGVO konform ist.
Shipping a privacy harming feature, while exploring how to fix the privacy harm, is exactly the “keep digging your way out of the deep hole” anti-pattern that has made browser fingerprinting such a difficult problem to solve.
Brendan Eich, Brave CEO
Browserhersteller wie Vivaldi oder Brave, die Chrome als Basis für ihre Browser verwenden, haben nun in ausführlichen Artikeln erklärt, dass in ihren Produkten FLoC nicht erlaubt sein wird. Beide sind sich einig, dass es mit FLoC noch einfacher wäre, das Surfverhalten zu verfolgen. Brave hat FLoC bereits in einer Nightly-Version von Chrome deaktiviert. Unter Vivaldi funktioniert FLoC nicht, da die Entwickler die Chromium-Engine an entscheidenden Stellen entschärfen, wenn es um den Schutz von Daten und Privatsphäre geht.
Einige Unternehmen haben FLoC bereits von ihren Webseiten verbannt, die Zahl wird sich vermutlich noch erhöhen. So blockiert etwa die Suchmaschine DuckDuckGo die ungeliebte Technik mit einem Add-on für Chrome. Geharnischte Kritik kommt auch aus den Reihen der Electronic Frontier Foundation (EFF).
Google hat die Auslieferung seines Browsers Chrome 79 für Android aufgrund eines fatalen Fehlers gestoppt, nachdem bereits am 13.12. geschätzt die Hälfte aller Anwender das Update erhalten hatten. Der Fehler kann zu völligem Verlust der gespeicherten Daten bei Dritt-Apps führen.
Fataler Fehler
Den Entwicklern der Chrome-App ist bei der Vorbereitung des Updates von Chrome 78 auf 79 ein folgenschwerer Fehler unterlaufen. Ausgelöst wurde der Fehler dadurch, dass durch eine Reorganisation das WebView-Verzeichnis an eine andere Stelle verschoben wurde. Dabei haben die Entwickler wohl vergessen, auch die Inhalte unter LocalStorage und WebSQL mitzunehmen. WebView ist eine vorinstallierte App für eine Systemfunktion von Android, mit der Apps Web-Inhalte wie HTML, CSS und JavaScript anzeigen und in Dritt-Apps darstellen können.
Daten aus Dritt-Apps verschwunden
Durch den Fehler mit den vergessenen Daten können Anwender nach dem Update auf Chrome 79 nicht mehr auf die Daten unter LocalStorage und WebSQL zugreifen, was einem Datenverlust gleichkommt. Die beiden Speichermechanismen ermöglichen es einer Website oder App, Daten auf dem Gerät im Chrome-Profilverzeichnis eines Benutzers zu speichern.
Der Verlust erstreckt sich neben Daten auch auf Einstellungen und teilweise die Möglichkeit sich bei betroffenen Apps anzumelden. Viele Anwender geben fälschlicherweise den App-Entwicklern die Schuld, wie auf Reddit nachzulesen ist.
Gelöscht oder nur nicht im Zugriff?
Ein Fix für dieses Problem ist alles andere als trivial und Google vermutet, dass mindestens 5 – 7 Tage vergehen werden, bevor Chrome 79 für Android erneut ausgerollt wird. Das Problem ist, dass Google nicht einfach auf die alte Verzeichnisstruktur zurückrollen kann, da dann weiterer Datenverlust für die 50 Prozent derer, die das Update bereits erhalten haben, droht. Denn derzeit wissen die Entwickler nicht mal genau, ob die Daten in den beiden Verzeichnissen überschrieben wurde oder nur nicht zugreifbar sind.
Eine Lösung wird derzeit noch im Bugtracker diskutiert. Ob eure App schon auf Version 79 aktualisiert wurde, könnt ihr in der Chrome-App im Menü rechts oben unter dem Punkt Einstellungen | Über Google Chrome überprüfen. Ist dies der Fall, bleibt nur abzuwarten, ob Google eine Lösung findet, die Daten wieder zugreifbar zu machen.
Wenn stimmt, was auf der Webseite Windows Central heute berichtet wird, dann sind die Browser-Wars endgültig vorbei und Chrome hat gewonnen. Dort wird nämlich berichtet, Microsoft wolle seinen seit 2015 entwickelten Browser Edge und dessen Engine EdgeHTML aufgeben und einen Browser auf der Basis von Chromium entwickeln.
Zu viele Fehler
Der Grund für die Einstellung der Bemühungen für einen Browser mit einer hauseigenen Engine soll die fehlende Akzeptanz durch die Anwender aufgrund von Beginn an bestehender Fehler sein. Auch der Marktanteil ist kläglich. Nach drei Jahren liegt dieser beim Desktop laut StatCounter bei gerade einmal 4 Prozent und damit noch um einiges hinter dem Internet Explorer mit 5.38 Prozent, den er eigentlich ablösen sollte.
Codename Anaheim
Laut Windows Central findet die Neuentwicklung unter dem Codenamen Anaheim statt. Der Wechsel könnte frühestens mit der Veröffentlichung von Windows 10, Codename 19H1 im April 2019 stattfinden. Dann könnte der »Browser, mit dem man Chrome herunterladen kann« Geschichte sein.
Nah an Blink
Neben »Informationen aus gut informierter Quelle« führt der Autor Beiträge von Microsoft-Mitarbeitern zur Chromium-Codebase zum Beleg seiner Behauptung an. Dabei geht es allerdings darum, Chromium auf der ARM-Architektur zu verbessern. Fakten sind bisher kaum bekannt, jedoch soll die Web-Engine sich nah an Googles Blink-Engine orientieren.
Keine Konkurrenz
Wenn sich das Gerücht bewahrheitet, steht nicht mehr viel zwischen der Chrome-Webengine Blink und der Weltherrschaft. Mozilla hat den Kampf schon längst verloren und liegt bei 9,1 Prozent Marktanteil, während Chrome seinen Höhenflug bei derzeit 72.38 wohl noch steigern können wird.
Anwender als Verlierer
Aus Sicht der Anwender ist das angesichts des mangelhaften Schutzes der Privatsphäre bei Chrome und seiner Engine eine bedauerliche Situation. Das Ausmaß der Aushöhlung der Nutzerrechte bereitet ein Artikel des Kryptographen Matthew Green, Professor an der Johns Hopkins University auf.
Heute vor 10 Jahren erschien, angekündigt durch einen Blogeintrag und einen Comic, die erste Version von Googles Browser Chrome mit der Versionsnummer 0.2. Seither zeigt Google der Welt, wie man einen Markt von hinten aufrollt. Chrome beherrscht heute den Browsermarkt mit einem Anteil von fast 60 Prozent.
Als Chrome damals antrat, sah die Browserwelt noch anders aus. Microsofts Internet Explorer hatte eine beherrschende Stellung mit 65 Prozent Marktanteil, Mozillas Firefox stand bei 27 Prozent, Opera belegte 3 Prozent. Heute verwenden viele Browser und Anwendungen die Blink-Engine von Chrome, darunter Opera, Steam, Samsung Internet und alles, was Electron als Grundlage hat.
Omnibox brachte Vorteile
Chrome erschien zunächst nur für Windows und wurde erst später, ab Version 5 auch für Linux und macOS freigegeben. Noch später folgten mobile Versionen für iOS und Android. Die Hauptzutaten, die Google zum Erfolg verhalfen waren ein beschleunigter Release-Zyklus, der neue Funktionen schnell zu den Anwendern brachte und innovative Entwicklungen wie die Omnibox und Sandboxing.
Grundlage Chromium
Google entwickelt Chrome im Open-Source-Projekt Chromium, dass ebenfalls als Browser veröffentlicht wird und hauptsächlich unter Linux Anwendung findet, da der Quellcode unter BSD-Lizenz offen liegt und die Kontrolle über die Funktionen erlaubt. Chrome wird im Takt von rund sechs Wochen veröffentlicht. Zusätzlich zur stabilen Version bietet Google Chrome auch in den drei Vorabversionen Beta, Dev und Canary an.
Überlegen schnell
In den frühen Jahren war die Geschwindigkeit, die Chrome mit V8, der virtuellen Laufzeitumgebung von JavaScript erreichte, ein Alleinstellungsmerkmal. So war Javascript in Chrome bei Tests im Jahr 2010 in etwa doppelt so schnell wie im Mozilla Firefox 3.6 oder rund neunmal so schnell wie der Internet Explorer 8. Es dauerte bis 2015, bis andere Browser wie Microsofts Neuentwicklung Edge hier mithalten konnten. Firefox gelang erst 2017 mit Firefox 57 Quantum ein entsprechender Geschwindigkeitsschub.
Aufgeräumt
Chrome strebte von Anfang an eine aufgeräumte Benutzerschnittstelle an. Ein Weg dahin war die Omnibox, eine Kombination aus Adressleiste und Suchfeld. Die Omnibox wurde durch Suchvervollständigung weiter ausgebaut. Heute kann die Omnibox Fragen beantworten und mathematische Probleme lösen bevor die Eingabetaste gedrückt wird.
Ein Prozess pro Tab
Google Chrome hat das Konzept des Privatmodus in Browsern zwar nicht erfunden, hat es aber populär gemacht. Was Google für Chrome aber zweifelsfrei erfunden hat ist die Multiprozessarchitektur, die den Renderer und jeden einzelnen Tab in einem eigenen Prozess in einer Sandbox laufen lässt. Das brachte erhöhte Sicherheit und Stabilität. Eine instabile Webseite ließ nur den eigenen Tab crashen und zog nicht den ganzen Browser hinter sich her. Nachteil war zur damaligen Zeit der hohe Verbrauch an Hauptspeicher, der heute nicht mehr ganz so schwer wiegt, wo viele Rechner bereits mit 8 GByte RAM ausgeliefert werden.
Weiterhin kann sich Chrome auf die Fahnen schreiben, der einzige Browser zu sein, der die Basis für ein eigenes Betriebssystem darstellt. Chrome OS macht vorinstalliert auf Chromebooks mittlerweile Furore im Bildungsmarkt und im Büro.
Bis heute in der Kritik
Bereits kurz nach der ersten Veröffentlichung rief Chrome die Kritiker in Sachen Datenschutz auf den Plan. Sie warfen Google vor, das Programm sammle Daten, die eine Identifizierung des Anwenders erlaubten und im Zusammenhang mit weiteren erhobenen Informationen ein Profil des Nutzers ergäben. Google wies die Vorwürfe, Anwender könnten identifiziert werden, immer zurück und argumentierte, der Anwender könne bei Bedenken ja jederzeit eine andere Suchmaschine einstellen. Auf Twitter hat Google für Dienstag eine Geburtstagsüberraschung angekündigt.
Vor rund sechs Wochen erschien Chrome 67 und führte als neues Sicherheitsmerkmal Site Isolation, zu deutsch Seiten-Isolierung, ein. Damit verschärfte Google die Trennung von Inhalten im Browser. Jetzt wurde bekannt, dass Mozilla seit April an einem ähnlichen Projekt arbeitet, dass unter dem Namen Project Fission läuft. Dabei soll jeder Rendering-Prozess auf Dokumente von einer einzigen Domain beschränkt werden.
Ein Prozess pro Domain
Seiten-Isolierung stellt sicher, dass Zugriffe von einer Webseite auf eine andere Domain immer in eigene Prozesse eingebunden werden, die jeweils in einer Sandbox laufen, die die Möglichkeiten des Prozesses einschränkt. Außerdem wird der Empfang bestimmter Arten von sensiblen Daten von anderen Websites eingeschränkt. Infolgedessen wird es für eine bösartige Webseiten schwieriger, Daten von anderen Seiten zu stehlen. Firefox Seiten-Isolierung richtet sich im Besonderen gegen Universal Cross-Site-Scripting (UXSS).
Gegen UXSS-Angriffe
Technisch wird das bei Chrome etwa so gelöst, dass seitenübergreifende Inhalte immer in einen eigenen Prozess geladen werden, unabhängig davon, ob sich die Navigation im aktuellen Tab, einem neuen Tab oder einem Iframe befindet. Seitenübergreifende Daten wie HTML-, XML- und JSON-Dateien werden nicht an den Prozess einer Webseite ausgeliefert, es sei denn, der Server sagt, dass dies erlaubt sei.
Firefox im Wandel
Mozilla hatte bereits 2016 seit Firefox 48 mit Electrolysis die Aufteilung des Renderns in mehrere Prozesse begonnen und im späteren Verlauf sukzessive bis hin zu Firefox 57 Quantum weiter ausgebaut. Diese Multi-Prozess-Architektur besteht derzeit aus einem Prozess für die grafische Benutzerschnittstelle (GUI) und mehreren Prozessen zum Rendern der Seiten. Bei Firefox ist die Zahl der maximal möglichen Prozesse nach oben beschränkt, weil mehr Prozesse auch mehr RAM binden.
RAM-Verbrauch herunterfahren
Um Firefox Seiten-Isolierung sinnvoll umzusetzen, müssen mindestens 100 Prozesse in einer Firefox-Sitzung laufen können. Derzeit erzeugt ein Prozess, unabhängig von seinem Inhalt, einen Overhead zwischen 17 und 35 MByte, je nach Plattform. Somit würde eine Sitzung mit Firefox Seiten-Isolierung bis zu 3,5 GByte belegen. Um hier nicht noch weiter in den Verruf des Speicherfressers zu geraten, versucht Mozilla, diesen Overhead im Rahmen von Fission MemShrink auf 10 MByte pro Prozess zu reduzieren. Im vergangenen Monat konnte bereits eine Reduzierung um 3 – 4 MByte erreicht werden. Die Erfolge können im Bugzilla verfolgt werden. Derzeit gibt es noch keine Angaben darüber, wann Ergebnisse aus Project Fission in Firefox ankommen werden.
Mit Chrome 67 dreht Google weiter an der Sicherheitsschraube. Das neueste Feature im Kampf gegen Spectre & Co. heißt Site Isolation, zu deutsch Seiten-Isolierung. Mit der Sicherheit erhöht sich allerdings auch der RAM-Bedarf des Browsers.
Verschärfte Trennung
Mit Site Isolation verschärft Google die Trennung von Inhalten im Browser. Galt bisher die Maxime, dass jeder Tab in einem eigenen Prozess läuft, so verfeinert Google nun diese Aufteilung weiter. Mit der bisherigen Lösung liefen etwa Cross-Site-Iframes oder -Pop-Ups im gleichen Prozess wie die Seite, die sie erzeugt hatte. Das erlaubte einem erfolgreichen Spectre-Angriff unter Umständen, Daten wie unter anderem Cookies oder Passwörter anderer Frames oder Pop-ups zu lesen.
Spectre-Angriffe erschweren
An Site Isolation arbeitete Google schon lange, bevor die Spectre-Angriffe Furore machten. Dabei geht es um eine einschneidende Änderung der Chrome-Architektur, die jeden Rendering-Prozess auf Dokumente von einer einzigen Seite beschränkt. Dies bedeutet, dass alle Navigation zu Cross-Site-Inhalten den jeweiligen Tab zum Wechseln der Prozesse veranlasst. Es bedeutet auch, dass alle Cross-Site-Iframes in einen anderen Prozess als ihr übergeordnetes Frame gesetzt werden, indem out-of-process iframes verwendet werden.
Site Isolation für (fast) alle
Mit Chrome 67 ist Site Isolation für 99 Prozent der Nutzer auf allen Betriebssystemen aktiviert, das verbleibende eine Prozent dient als Kontrollgruppe. Mit der Aktivierung reduziert sich die Datenmenge, die ein Angreifer stehlen könnte, und »reduziert die Bedrohung durch Spectre erheblich«, so Google.
Kehrseite der Medaille
Google plant, die Site Isolation auf Chrome für Android auszudehnen und arbeitet an der Lösung bekannter Probleme. Mit Chrome 68 kann die Seiten-Isolierung sowohl manuell auf dem Handy über ein Flag als auch über Unternehmensrichtlinien aktiviert werden. Wie so oft, hat aber auch diese Verbesserung einen Pferdefuß: Dadurch, dass mehr Rendering-Prozesse erzeugt werden, erhöht sich der RAM-Verbrauch des beliebtesten Browsers weiter. Google-Entwickler Charlie Reis führte das im Sicherheitsblog des Unternehmens aus:
Site Isolation führt dazu, dass Chrome mehr Rendering-Prozesse erstellt, was mit Leistungseinbußen verbunden ist: Auf der positiven Seite ist jeder Rendering-Prozess kleiner, kurzlebiger und hat intern weniger Konkurrenz, aber es gibt aufgrund der größeren Anzahl von Prozessen etwa 10-13 Prozent Gesamtspeicher-Overhead in realen Workloads. Unser Team arbeitet weiterhin hart daran, dieses Verhalten zu optimieren, um Chrome schnell und sicher zu halten.
Ab dem 15. Februar blockiert Googles Browser Chrome Werbung, notfalls auch die eigene. Dabei will der Konzern, der selbst massiv von Werbung lebt, aber nicht den Ad-Blockern Konkurrenz machen, die durchschnittlich von 31 Prozent aller Besucher im Internet benutzt werden. Ad-Blocker versuchen, jegliche Werbung zu unterdrücken. Der Browser Opera bringt bereits einen solchen restriktiven Adblocker mit, ebenso der Browser Brave des ehemaligen Mozilla-Vorstands Brendan Eich. Google verfolgt ein anderes Modell und will Werbung selektiv blockieren.
Webseiten, die nicht als reines Hobby betrieben werden, müssen sich finanzieren, das ist einzusehen. Das geschieht auf verschiedenen Wegen. Werbung ist eines der Finanzierungsmodelle, Walled Gardens mit Subskriptionspreis ein anderes. Ein alternatives Modell ist Patreon, das bereits von vielen Blogs und anderen Projekten zur Finanzierung genutzt wird.
Wie auf dem Jahrmarkt
Viele Webseiten übertreiben es mit der Werbung so sehr, dass der Besucher beim Betreten denkt, er sei auf einem Jahrmarkt. Solche Seiten machen die Benutzung eines Ad-Blockers zwingend und schaden anderen Webseiten, die Werbung dezent, ziel- und themengerichtet einsetzen. Hier setzt Google mit seiner Blockade an. Webseiten, die den Besucher aufdringlich mit Bild, Ton und Effekten drangsalieren, werden von Google ermahnt, dies abzustellen. Passiert dies innerhalb 30 Tagen nicht, wird Werbung auf dieser Seite künftig geblockt.
Veträgliche Standards
Dabei richtet sich Google an den Standards der Vereinigung Better Ads aus, in deren Vorstand der Suchmaschinenriese sitzt. Webseitenbetreiber können ihre Seite mit dem »Ad Experience Report« selbst überprüfen. Die Standards, nach denen Google blockiert, verhindern Werbung, die automatisch Videos abspielt, Pop-ups einblendet, Werbung, die Seiteninhalte so lange verdeckt bis ein Timer abgelaufen ist oder Werbung die trotzt Scrollens große Teile des Seiteninhalts verdeckt. Auf Mobilgeräten soll zudem Werbung geblockt werden, die mehr als 30 Prozent des Displays einnimmt oder blinkt.
Kein Tracking-Schutz
Bisher nicht von Googles Maßnahmen erfasst ist Ad-Tracking. Das Anzeigen-Tracking, bei dem Programmcode im Browser ausgeführt wird, trägt dazu bei, dass Werbung dazu beiträgt, Webseiten langsamer zu laden, mehr Speicherplatz beanspruchen, die Datenmenge von Anwendern ohne Flatrate zu erhöhen und die Akkus von Smartphones und Laptops schneller zu leeren. Es kann aber durchaus sein, dass sich »Better Ads« dieses Problems noch annimmt. Mozilla blockiert bereits aktiv Tracking in Firefox.
Die Werbebranche lenkt ein
Google handelt hier natürlich nicht uneigennützig, sondern gehorcht der Erkenntnis, dass zu viel und zu aufdringliche Werbung zu einer Steigerung des Einsatzes von Adblockern führt. Hier gilt es einen Weg zu finden, der sowohl die Besucher im Internet als auch die Bedürfnisse der Webseitenbetreiber und der Werbewirtschaft berücksichtigt. Ich bin beispielsweise beruflich den ganzen Tag im Internet auf unzähligen Seiten unterwegs und hätte ohne strikten Ad-Blocker vermutlich andauernd Kopfschmerzen. Ich bin aber gerne bereit, auf Seiten mit unaufdringlicher Werbung eine Ausnahme in Ad-Blocker einzurichten.
Google hat Chrome 63 für Linux, macOS und Windows freigegeben. Es wurden insgesamt 37 Sicherheitslücken beseitigt, wovon einige eine hohe Gefährdung darstellten. Google zahlte den Entdeckern der Lücken im Rahmen seines Bug-Bounty-Programms über 45.000 US-Dollar aus.
Google hat Chrome 63 an einigen Stellen übersichtlicher gestaltet. So bietet die Seite chrome:flags, die experimentelle Funktionen von Chrome zum Aktivieren anbietet, nun einen wesentlich besseren Überblick. Die Schaltfläche zum Zurücksetzen aller Funktionen auf Standardwerte sitzt prominent und größer als zuvor am Kopf der Seite. Außerdem wurde ein Suchfeld hinzugefügt.
Chrome 63 wird übersichtlicher
Auch die Informationen zur Sicherheit einer Seite, die links neben dem Adressfeld angezeigt werden, sieht nach einem Klick darauf nun aufgeräumter aus. Es werden weniger Informationen direkt angezeigt, der Rest ist über eine Schaltfläche erreichbar, die auf eine Seite in den Einstellungen führt.
Eine neue experimentelle Sicherheitsfunktion bei Chrome 63 ist Strict Site Isolation, eine Funktion, mit der jede Webseite in einem eigenen Prozess ausgeführt wird. Zunächst nur in Chrome for Business offiziell verfügbar, lässt sich die Funktion in Chrome 63 manuell freischalten.
Ein eigener Prozess pro Webseite
Google selbst erklärt die zusätzliche Sicherheit beim Sandboxing so:
»Googles Website-Isolationsfunktion verbessert die Sicherheit für Chrome-Browser-Benutzer. Wenn Sie die Site-Isolation aktivieren, wird der Inhalt für jede geöffnete Website im Chrome-Browser immer in einem dedizierten Prozess gerendert, der von anderen Websites isoliert ist. Dadurch wird eine zusätzliche Sicherheitsgrenze zwischen den Websites geschaffen.«
Zur Freischaltung wird in chrome:flags in das Suchfeld der Begriff site-per-process eingegeben. Daraufhin wird das Experiment angezeigt und kann aktiviert werden. Google warnt allerdings derzeit noch vor erhöhtem Speicherbedarf von 10 – 20 Prozent. Dieser Wert soll erst erheblich reduziert werden bevor die Anwender von Chrome offiziell auf diese Funktion zugreifen können.
Neue API nutzt RAM besser aus
Mit »Device Memory JavaScript API« steht eine neue API zur besseren RAM-Ausnutzung zur Verfügung. Diese Funktion soll Anwendern auf Geräten mit wenig RAM helfen. Die API erkennt automatisch die Menge des Speichers im Gerät und kann bei hohem RAM-Verbrauch auf Lite-Versionen von Websites umleiten. Der Sicherheit zugute kommt zudem der neue Schutz von GMail durch TLS 1.3.
