API-Einstellungen und -Entfernungen in Chrome 56

Joe Medley
Joe Medley

Bei fast jeder Chrome-Version gibt es eine große Anzahl von Updates und Verbesserungen am Produkt, an seiner Leistung und auch an den Funktionen der Webplattform. In diesem Artikel werden die Einstellung und Entfernung von Funktionen in Chrome 56 beschrieben, die seit dem 8. Dezember in der Betaphase ist. Diese Liste kann sich jederzeit ändern.

Unterstützung für SHA-1-Zertifikate entfernen

Der kryptografische Hash-Algorithmus SHA-1 zeigte vor über elf Jahren erste Anzeichen von Schwächen und neuere Forschungsergebnisse deuten auf die unmittelbare Möglichkeit von Angriffen hin, die sich direkt auf die Integrität der Public-Key-Infrastruktur (PKI) des Webs auswirken könnten.

Um Nutzer vor solchen Angriffen zu schützen, unterstützt Chrome ab Version 56, die im Januar 2017 veröffentlicht wurde, keine SHA-1-Zertifikate mehr. Wenn Sie eine Website mit einem solchen Zertifikat aufrufen, wird eine Zwischenwarnung angezeigt. Weitere Informationen finden Sie im Chrome Security Blog.

Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler

ECDSA-Chiffren im CBC-Modus in TLS entfernen

Der CBC-Modus von TLS ist fehlerhaft, was ihn anfällig und sehr schwer sicher zu implementieren macht. Obwohl CBC-Modus-Chiffren bei RSA noch weit verbreitet sind, werden sie bei ECDSA praktisch nicht verwendet. Andere Browser unterstützen diese Chiffren weiterhin. Wir gehen davon aus, dass das Risiko gering ist. Außerdem wird ECDSA in TLS von nur wenigen Organisationen und in der Regel mit einer komplexeren Einrichtung verwendet (einige ältere Clients unterstützen nur RSA). Wir gehen davon aus, dass ECDSA-Websites besser gewartet und bei Problemen schneller reagieren.

TLS 1.2 hat neue Chiffren auf der Grundlage von AEADs hinzugefügt, die diese Probleme vermeiden. Dazu gehören AES_128_GCM, AES_256_GCM oder CHACHA20_POLY1305. Derzeit ist dies nur für ECDSA-basierte Websites erforderlich, wird aber allen Administratoren empfohlen. AEAD-basierte Chiffren verbessern nicht nur die Sicherheit, sondern auch die Leistung. AES-GCM wird auf aktuellen CPUs hardwareseitig unterstützt und ChaCha20-Poly1305 ermöglicht schnelle Softwareimplementierungen. CBC-Verschlüsselungen erfordern dagegen langsame, komplexe Abhilfemaßnahmen und PRNG-Zugriff auf jeden ausgehenden Datensatz. AEAD-basierte Chiffren sind auch eine Voraussetzung für HTTP/2- und False-Start-Optimierungen.

Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler

Nutzergesten aus dem Touch-Scrollen entfernen

Wir haben mehrere Beispiele für schlecht geschriebene oder schädliche Anzeigen gefunden, die die Navigation für Touch-Scrolls entweder bei touchstart- oder bei allen touchend-Ereignissen auslösen. Wenn ein „wheel“-Ereignis kein Pop-up öffnen kann, sollte das auch nicht durch Wischen möglich sein. Dies kann zu Problemen führen, z. B. dass Medien nicht durch Berührung wiedergegeben oder Pop-ups nicht durch Berührung geöffnet werden. In all diesen Fällen werden Pop-ups in Safari bereits stummgeschaltet.

Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler

Alle Abrufe für Scripts mit ungültigen Typ-/Sprachattributen ablehnen

Derzeit ruft der Chrome-Preload-Scanner Elemente in <scripts>-Elementen unabhängig vom Wert des type- oder language-Attributs ab. Das Script wird beim Parsen jedoch nicht ausgeführt. Durch die Einstellung des Abrufs haben der Preloader-Scanner und der Parser dieselbe Semantik und wir initiieren keine Abrufe für Scripts, die wir nicht verwenden. So sollen Daten für Nutzer gespeichert werden, die Websites mit vielen benutzerdefinierten Script-Tags aufrufen, die nachbearbeitet werden (z. B. type="text/template").

Der Anwendungsfall, bei dem ungültige Scripts zum Pingen von Servern verwendet werden, wird durch die sendBeacon API ausreichend abgedeckt.

Durch diese Änderung wird Chrome an Safari angeglichen. Firefox fordert jedoch weiterhin Scripts unabhängig von Typ oder Sprache an.

Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler

MediaStreamTrack.getSources() entfernen

Diese Methode ist nicht mehr Teil der Spezifikation und wird von keinem anderen großen Browser unterstützt. Es wurde durch MediaDevices.enumerateDevices() ersetzt, das Blink seit Version 47 ohne Flags unterstützt und auch von anderen Browsern unterstützt wird. Ein Beispiel dafür ist unten zu sehen. Bei dieser hypothetischen getCameras()-Funktion wird zuerst die Feature-Erkennung verwendet, um enumerateDevices() zu finden und zu verwenden. Wenn die Featureerkennung fehlschlägt, wird in MediaStreamTrack nach getSources() gesucht. Wenn keine API-Unterstützung vorhanden ist, gib das leere cameras-Array zurück.

    function getCameras(camerasCallback) {
     
var cameras = [];
     
if('enumerateDevices' in navigator.mediaDevices) {
         navigator
.mediaDevices.enumerateDevices()
         
.then(function(sources) {
           
return sources.filter(function(source) {
             
return source.kind == 'videoinput'
           
});
         
})
         
.then(function(sources) {
            sources
.forEach(function(source) {
             
if(source.label.indexOf('facing back') >= 0) {
               
// move front facing to the front.
                cameras
.unshift(source);
             
}
             
else {
                cameras
.push(source);
             
}
           
});
            camerasCallback
(cameras);
         
});
     
}
     
else if('getSources' in MediaStreamTrack) {
       
MediaStreamTrack.getSources(function(sources) {

         
for(var i = 0; i < sources.length; i++) {
           
var source = sources[i];
           
if(source.kind === 'video') {

             
if(source.facing === 'environment') {
               
// cameras facing the environment are pushed to the front of the page
                cameras
.unshift(source);
             
}
             
else {
                cameras
.push(source);
             
}
           
}
         
}
          camerasCallback
(cameras);
       
});
     
}
     
else {
       
// We can't pick the correct camera because the API doesn't support it.
        camerasCallback
(cameras);
     
}
   
};

Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler

CSP-Direktive „reflected-xss“ entfernen

Frühe Entwürfe der Content Security Policy Level 2-Spezifikation enthielten eine reflected-xss-Anweisung, die abgesehen von einer anderen Syntax nichts anderes als den X-XSS-Protection-Header bot. Diese Direktive wurde 2015 aus der Spezifikation entfernt, aber nicht bevor sie in Chrome implementiert wurde. Die Unterstützung für diese Direktive wird jetzt entfernt.

Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler

CSP-Richtlinie „referrer“ ersetzen

Mit der CSP-referrer-Richtlinie konnten Websiteinhaber eine Referrer-Richtlinie über einen HTTP-Header festlegen. Diese Funktion wird nicht nur sehr selten verwendet, sondern ist auch nicht mehr Teil einer W3C-Spezifikation.

Websites, für die diese Funktion weiterhin erforderlich ist, sollten <meta name="referrer"> oder den neuen Referrer-Policy-Header verwenden.

Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler

Feld „PaymentAddress.careOf“ entfernen

Die PaymentAddress-Benutzeroberfläche enthält ein Feld vom Typ careOf, das nicht standardmäßig ist und von keinem bekannten Adressstandard unterstützt wird. Das Feld careOf ist ebenfalls nicht erforderlich, da die Felder „Empfänger“ und „Organisation“ alle erforderlichen Anwendungsfälle ausreichend abdecken. Das Hinzufügen von careOf stellt erhebliche Probleme in Bezug auf die Interoperabilität mit bestehenden Schemas und APIs für Postadressen dar. Eine ausführlichere Diskussion finden Sie im Vorschlag zum Entfernen der Spezifikation auf GitHub.

Intent to Remove | Chromium-Fehler

SVGViewElement.viewTarget entfernen

Das SVGViewElement.viewTarget-Attribut ist nicht Teil der SVG2.0-Spezifikation und wird nur selten oder gar nicht verwendet. Dieses Attribut wurde in Chrome 54 eingestellt und ist jetzt entfernt.

Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler