Einstellungen und Entfernungen in Chrome 81

Joe Medley
Joe Medley

.

Die Unterstützung des Payment Handler zur Unterstützung von "basic-card" wird eingestellt und entfernt

In dieser Version von Chrome wird das Basiskarten-Polyfill für die Payment Request API in iOS Chrome entfernt. Aus diesem Grund ist die Payment Request API in iOS Chrome vorübergehend deaktiviert. Ausführliche Informationen hierzu finden Sie unter Rethinking Payment Request for iOS.

Zu entfernende Absicht | Status der Chrome-Plattform | Chromium-Fehler

Feld „supportedType“ aus „BasicCardRequest“ entfernen

Wenn Sie den Parameter "supportedTypes":[type] für die Zahlungsmethode "basic-card" angeben, werden nur Karten des angeforderten Typs angezeigt, also „Kreditkarte“, „"debit"“ oder „"prepaid"“.

Der Kartentyp-Parameter wurde aus der Spezifikation entfernt und nun aus Chrome entfernt, da die Bestimmung des Kartentyps schwierig ist. Händler müssen den Kartentyp bei ihrem PSP prüfen, da sie dem Kartentypfilter im Browser nicht vertrauen können:

  • Nur ausstellende Banken kennen den Kartentyp mit Sicherheit. Herunterladbare Kartentyp-Datenbanken haben eine geringe Genauigkeit. Daher ist es unmöglich, den Typ der lokal im Browser gespeicherten Karten genau zu bestimmen.
  • Bei der Zahlungsmethode „Basic-card“ in Chrome werden keine Karten von Google Pay mehr angezeigt, die möglicherweise mit ausstellenden Banken verbunden sind.

Zu entfernende Absicht | Status der Chrome-Plattform | Chromium-Fehler

Entfernen Sie das -Element.

In Chrome 81 wird das <discard>-Element entfernt. Sie wird nur in Chromium implementiert und kann daher nicht interoperabel verwendet werden. In den meisten Anwendungsfällen kann er durch eine Kombination aus Animation des Attributs display und einem JavaScript-Callback bzw. Ereignis-Handler ersetzt werden.

Zu entfernende Absicht | Status der Chrome-Plattform | Chromium-Fehler

TLS 1.0 und TLS 1.1 entfernen

TLS (Transport Layer Security) ist das Protokoll zum Schutz von HTTPS. Es hat eine lange Geschichte, die mit dem fast 20 Jahre alten TLS 1.0 und seinem noch älteren Vorgänger, SSL, zurückreicht. Sowohl TLS 1.0 als auch TLS 1.1 haben eine Reihe von Schwächen.

  • TLS 1.0 und 1.1 verwenden im Transkript-Hash der Nachricht „Finished“ die beiden schwachen Hashes MD5 und SHA-1.
  • Für TLS 1.0 und 1.1 werden in der Serversignatur MD5 und SHA-1 verwendet. (Hinweis: Dies ist nicht die Signatur im Zertifikat.)
  • TLS 1.0 und 1.1 unterstützen nur RC4- und CBC-Chiffren. RC4 ist fehlerhaft und wurde inzwischen entfernt. Die CBC-Moduskonstruktion von TLS ist fehlerhaft und anfällig für Angriffe.
  • Außerdem erstellen die CBC-Chiffren von TLS 1.0 ihre Initialisierungsvektoren falsch.
  • TLS 1.0 ist nicht mehr PCI-DSS-konform.

Die Unterstützung von TLS 1.2 ist eine Voraussetzung, um die oben genannten Probleme zu vermeiden. Die TLS-Arbeitsgruppe hat TLS 1.0 und 1.1 verworfen. Chrome hat diese Protokolle jetzt ebenfalls eingestellt.

Entfernungsabsicht | Chromestatus-Tracker | Chromium-Fehler

Umgehung der Härtung beim TLS 1.3-Downgrade

TLS 1.3 umfasst eine abwärtskompatible Härtungsmaßnahme, um den Downgrade-Schutz zu verstärken. Als wir im letzten Jahr TLS 1.3 ausgeliefert haben, mussten wir diese Maßnahme aufgrund von Inkompatibilitäten mit einigen nicht konformen, TLS-terminierenden Proxys teilweise deaktivieren. Chrome implementiert derzeit die Härtungsmaßnahme für Zertifikate, die mit bekannten Roots verkettet sind, ermöglicht jedoch eine Umgehung für Zertifikate, die zu unbekannten Stammen verkettet sind. Wir beabsichtigen, sie für alle Verbindungen zu aktivieren.

Der Downgradeschutz verringert die Auswirkungen der verschiedenen Legacy-Optionen, die wir aus Kompatibilitätsgründen beibehalten haben. Das bedeutet, dass die Verbindungen der Nutzer sicherer sind und es weniger mühselig ist, darauf zu reagieren, wenn Sicherheitslücken entdeckt werden. Dies bedeutet wiederum, dass Nutzern später weniger Websites instabil werden. Dies entspricht auch RFC 8446.

Zu entfernende Absicht | Status der Chrome-Plattform | Chromium-Fehler

Einstellungsrichtlinie

Damit die Plattform intakt bleibt, entfernen wir manchmal APIs von der Webplattform, die bereits im Vorfeld ausgeführt wurden. Es gibt viele Gründe, warum wir eine API entfernen, z. B.:

  • Sie werden durch neuere APIs ersetzt.
  • Sie werden aktualisiert, um Änderungen der Spezifikationen widerzuspiegeln und so für eine einheitliche und einheitliche Darstellung mit anderen Browsern zu sorgen.
  • Es handelt sich dabei um frühe Experimente, die in anderen Browsern noch nie zum Laufen gekommen sind und daher den Support für Webentwickler erhöhen können.

Einige dieser Änderungen wirken sich auf eine sehr geringe Anzahl von Websites aus. Um Probleme frühzeitig zu minimieren, informieren wir Entwickler vorab, damit sie die erforderlichen Änderungen vornehmen können, damit ihre Websites weiterhin funktionieren.

Für Chrome gibt es derzeit einen Prozess zur Einstellung und Entfernung von APIs, der im Wesentlichen so aussieht:

  • Mitteilung in der Mailingliste blink-dev ankündigen
  • In der Chrome-Entwicklertools-Konsole kannst du Warnungen festlegen und eine Zeitskala festlegen, wenn Nutzung auf der Seite erkannt wird.
  • Warten Sie, überwachen Sie die Funktion und entfernen Sie sie dann, wenn die Nutzung sinkt.

Eine Liste aller eingestellten Funktionen finden Sie auf chromestatus.com mit dem eingestellten Filter . Entfernte Funktionen finden Sie unter Filter entfernt. Außerdem werden wir versuchen, in diesen Beiträgen einige der Änderungen, Überlegungen und Migrationspfade zusammenzufassen.