In fast jeder Version von Chrome gibt es eine beträchtliche Anzahl von Updates und Verbesserungen des Produkts, seiner Leistung und auch der Funktionen der Web-Plattform. In diesem Artikel werden die Einstellungen in Chrome 60 beschrieben, das sich seit dem 8. Juni in der Betaphase befindet. Diese Liste kann sich jederzeit ändern.
Sicherheit
crypto.subtle erfordert jetzt einen sicheren Ursprung
Die Web Crypto API, die seit Chrome 37 unterstützt wird, funktioniert schon immer mit nicht sicheren Ursprüngen. Aufgrund der langjährigen Richtlinie von Chrome, dass sichere Ursprünge für leistungsstarke Funktionen bevorzugt werden, ist crypto.subtle
nicht nur für sichere Ursprünge sichtbar.
Absicht der Entfernung | Chromium-Fehler
Von Inhalten initiierte Navigationen im oberen Frame zu Daten-URLs entfernen
Da sie mit nicht-technischen Browsern nicht vertraut sind, wird das data:
-Schema zunehmend für Spoofing- und Phishing-Angriffe verwendet. Um dies zu verhindern, blockieren wir Webseiten am Laden von data:
-URLs im oberen Frame. Dies gilt für <a>
-Tags, window.open
, window.location
und ähnliche Mechanismen. Das Schema data:
funktioniert weiterhin für Ressourcen, die von einer Seite geladen werden.
Diese Funktion wurde in Chrome 58 eingestellt und ist jetzt entfernt.
Entfernungsabsicht | Chromestatus-Tracker | Chromium-Fehler
navigator.sendBeacon() vorübergehend für einige Blobs deaktivieren
Die Funktion navigator.sendBeacon()
ist seit Chrome 39 verfügbar.
Wie ursprünglich implementiert, könnte das Argument data
der Funktion jeden beliebigen Blob enthalten, dessen Typ nicht CORS-sicher ist. Wir glauben, dass dies eine potenzielle Sicherheitsbedrohung ist, auch wenn noch niemand versucht hat, sie auszunutzen. Da wir KEINE angemessene sofortige Lösung dafür haben, kann sendBeacon()
vorübergehend nicht mehr für Blobs aufgerufen werden, deren Typ NICHT CORS-sicher ist.
Diese Änderung wurde zwar für Chrome 60 implementiert, wurde aber inzwischen wieder mit Chrome 59 zusammengeführt.
CSS
Die schattendurchdringende Nachfolgerkombinatorenfunktion wie die des Nachfolgerkombinatoren verhalten
Der Schatten-durchbrechende Nachfolgerkombinator (>>>
), der Teil des CSS-Scoping-Moduls der Ebene 1 ist, sollte die untergeordneten Elemente eines bestimmten Ancestor-Elements zuordnen, selbst wenn sie in einem Schattenbaum auftraten. Dabei gab es einige Einschränkungen.
Laut Spezifikation konnte der Code nur in JavaScript-Aufrufen wie querySelector()
verwendet werden und funktionierte nicht in Stylesheets. Und was noch wichtiger ist: Browseranbieter konnten nicht dafür sorgen, dass es über eine Ebene des Shadow DOM hinaus funktioniert.
Daher wurde der untergeordnete Kombinator aus den relevanten Spezifikationen entfernt, einschließlich Shadow DOM v1. Anstatt Webseiten zu beschädigen, indem wir diesen Selektor aus Chromium entfernen, haben wir uns stattdessen für den Alias des schattenführenden untergeordneten Kombinators auf den untergeordneten Kombinator entschieden. Das ursprüngliche Verhalten wurde in Chrome 45 eingestellt. Das neue Verhalten wird in Chrome 61 implementiert.
Entfernungsabsicht | Chromestatus-Tracker | Chromium-Fehler
JavaScript
RTCPeerConnection.getStreamById() verwerfen und entfernen
Vor fast zwei Jahren wurde getStreamById()
aus der WebRTC-Spezifikation entfernt. Bei den meisten anderen Browsern wurde dies bereits aus ihren Implementierungen entfernt. Obwohl diese Funktion als wenig genutzt wird, wird angenommen, dass sie ein geringes Interoperabilitätsrisiko mit Edge- und WebKit-basierten Browsern mit Ausnahme von Safari aufweist, in denen getStreamById()
noch unterstützt wird. Entwickler, die eine alternative Implementierung benötigen, finden Beispielcode unten im zu entfernenden Intent.
Diese Funktion wird in Chrome 62 entfernt.
Entfernungsabsicht | Chromestatus-Tracker | Chromium-Fehler
SVGPathElement.getPathSegAtLength verwerfen
Vor über zwei Jahren wurde getPathSegAtLength()
aus der SVG-Spezifikation entfernt. Da es in httparchive nur wenige Treffer für diese Methode gibt, wird sie in Chrome 60 eingestellt. Das Update wird voraussichtlich in Chrome 62 verfügbar sein, das Anfang oder Mitte Oktober veröffentlicht wird.
Abzustufen | Chromestatus-Tracker | Chromium-Fehler
„getContextAttributes()“ hinter ein Flag verschieben
Die Funktion getContextAttributes()
wird seit 2013 in CanvasRenderingContext2D
unterstützt. Das Feature gehörte jedoch keinem Standard und ist seitdem nicht mehr in einen Standard eingebunden. Es hätte hinter dem Befehlszeilen-Flag --enable-experimental-canvas-features
implementiert werden müssen, aber irrtümlicherweise nicht. In Chrome 60 wurde dieses Versäumnis korrigiert. Es wird angenommen, dass diese Änderung sicher ist, da keine Daten zeigen, dass jemand die Methode verwendet.
Headers.prototype.getAll() entfernen
Die Funktion Headers.prototype.getAll()
wird gemäß der neuesten Version der Abrufspezifikation entfernt.
Entfernungsabsicht | Chromestatus-Tracker | Chromium-Fehler
indexDB.webkitGetDatabaseNames() entfernen
Wir haben diese Funktion hinzugefügt, als Indexed DB in Chrome noch relativ neu war, und Präfixe waren der Wahnsinn. Die API gibt asynchron eine Liste vorhandener Datenbanknamen in einem Ursprung zurück, was sinnvoll genug erschien.
Leider ist das Design fehlerhaft, da die Ergebnisse möglicherweise veraltet sind, sobald sie zurückgegeben werden, sodass sie wirklich nur für Logging und nicht für ernsthafte Anwendungslogik verwendet werden können. Das GitHub-Problem enthält Links zu früheren Diskussionen über Alternativen, für die ein anderer Ansatz erforderlich ist. Entwickler haben immer wieder das Interesse, aber angesichts des Mangels an browserübergreifendem Fortschritt haben Bibliotheksautoren dieses Problem bereits umgangen.
Entwickler, die diese Funktion benötigen, müssen eine eigene Lösung entwickeln. Bibliotheken wie Dexie.js verwenden beispielsweise eine globale Tabelle, die selbst eine weitere Datenbank ist, um die Namen von Datenbanken zu verfolgen.
Diese Funktion wurde in Chrome 58 eingestellt und ist jetzt entfernt.
Entfernungsabsicht | Chromestatus Tracker | Chromium-Programmfehler
WEBKIT_KEYFRAMES_RULE und WEBKIT_KEYFRAME_RULE entfernen
Die nicht standardmäßigen Konstanten WEBKIT_KEYFRAMES_RULE
und WEBKIT_KEYFRAME_RULE
werden aus der CSS-Regel entfernt.
Entwickler sollten stattdessen KEYFRAMES_RULE
und KEYFRAME_RULE
verwenden.
Entfernungsabsicht | Chromestatus Tracker | Chromium-Programmfehler
Benutzeroberfläche
Nutzergeste für „beforeunload“-Dialogfelder verlangen
Ab Chrome 60 wird das Dialogfeld beforeunload
nur dann angezeigt, wenn der Frame, der angezeigt werden soll, eine Nutzergeste oder Nutzerinteraktion bzw. ein eingebetteter Frame eine solche Geste erhalten hat. Zur Klarstellung: Dies ist keine Änderung an der Auslösung des beforeunload
-Ereignisses. Es ändert sich lediglich, ob das Dialogfeld angezeigt wird.
Das beforeunload
-Dialogfeld ist ein app-modales Dialogfeld. Er ist also von Natur aus nutzerfeindlich. Das heißt, er reagiert auf die Navigation eines Nutzers, indem er seine Entscheidung hinterfragt. Es gibt positive Anwendungsbereiche für diese Funktion. Es wird beispielsweise häufig verwendet, um Nutzer zu warnen, wenn durch die Navigation Daten verloren gehen.
Die Möglichkeit einer Seite, Text für das Dialogfeld beforeunload
bereitzustellen, wurde vor einiger Zeit entfernt, aber beforeunload
-Dialogfelder bleiben weiterhin eine Möglichkeit für Missbrauch. Insbesondere beforeunload
-Dialogfelder sind ein Bestandteil von betrügerischen Websites, auf denen Autoplay von Audio und bedrohlicher Text einen Kontext bieten, bei dem die von Chromium bereitgestellte Meldung „Möchtest du diese Seite wirklich verlassen?“ besorgniserregend ist.
Wir möchten ein Threading durchführen und nur das Dialogfeld beforeunload
sinnvoll nutzen. Der Dialog eignet sich gut für Situationen, in denen der Nutzer einen Status hat, der verloren gehen könnte. Wenn der Nutzer noch nie mit der Seite interagiert hat, kann er keinen Status haben, der verloren gehen könnte. In diesem Fall wird das Dialogfeld daher unterdrückt, um den Verlust von Nutzerdaten nicht zu riskieren.