Dans presque toutes les versions de Chrome, nous constatons un grand nombre de mises à jour et d'améliorations apportées au produit, à ses performances et aux fonctionnalités de la plate-forme Web. Cet article décrit les fonctionnalités obsolètes et supprimées dans Chrome 56, qui est en version bêta depuis le 8 décembre. Cette liste est susceptible d'être modifiée à tout moment.
Abandon de la prise en charge des certificats SHA-1
L'algorithme de hachage cryptographique SHA-1 a d'abord montré des signes de faiblesse il y a plus de 11 ans, et des recherches récentes indiquent la possibilité imminente d'attaques pouvant avoir un impact direct sur l'intégrité de l'infrastructure à clé publique (PKI) Web.
Pour protéger les utilisateurs contre de telles attaques, Chrome n'est plus compatible avec les certificats SHA-1 à partir de Chrome 56, dont la version stable est disponible depuis janvier 2017. Si vous accédez à un site utilisant un tel certificat, un avertissement interstitiel s'affiche. Pour en savoir plus, consultez le blog de sécurité Chrome.
Intent to Remove | Chromestatus Tracker | Bug Chromium
Suppression des algorithmes de chiffrement ECDSA en mode CBC dans TLS
La construction en mode CBC de TLS est défectueuse, ce qui la rend fragile et très difficile à implémenter de manière sécurisée. Bien que les algorithmes de chiffrement en mode CBC soient encore largement utilisés avec RSA, ils sont pratiquement inexistants avec ECDSA. D'autres navigateurs sont toujours compatibles avec ces algorithmes de chiffrement. Nous estimons que le risque est faible. De plus, ECDSA dans TLS est utilisé par peu d'organisations et généralement avec une configuration plus complexe (certains clients plus anciens ne prennent en charge que RSA). Nous nous attendons donc à ce que les sites ECDSA soient mieux entretenus et plus réactifs en cas de problème.
TLS 1.2 a ajouté de nouveaux algorithmes de chiffrement basés sur des algorithmes AEAD, ce qui évite ces problèmes, en particulier AES_128_GCM, AES_256_GCM ou CHACHA20_POLY1305. Bien que nous ne l'exigions que pour les sites basés sur ECDSA pour le moment, nous le recommandons à tous les administrateurs. Les algorithmes de chiffrement basés sur AEAD améliorent non seulement la sécurité, mais aussi les performances. AES-GCM est compatible avec le matériel sur les processeurs récents, et ChaCha20-Poly1305 accepte les implémentations logicielles rapides. En revanche, les algorithmes de chiffrement CBC nécessitent des mesures d'atténuation complexes et lentes, ainsi qu'un accès à un générateur de nombres pseudo-aléatoires sur chaque enregistrement sortant. Les algorithmes de chiffrement basés sur AEAD sont également une condition préalable à l'optimisation de HTTP/2 et du faux démarrage.
Projet de suppression | Outil de suivi de l'état de Chrome | Bug Chromium
Supprimer les gestes utilisateur du défilement tactile
Nous avons vu plusieurs exemples d'annonces mal écrites ou malveillantes qui déclenchent la navigation pour le défilement tactile sur touchstart ou tous les événements touchend. Si un événement de "roue" ne peut pas ouvrir de pop-up, le défilement tactile ne doit pas non plus. Cela peut entraîner des problèmes dans certains scénarios, par exemple, si les contenus multimédias ne sont pas lus lorsque l'utilisateur appuie sur l'écran ou si les pop-ups ne s'ouvrent pas lorsque l'utilisateur appuie sur l'écran. Safari ne parvient déjà pas à ouvrir les pop-ups de manière silencieuse dans tous ces scénarios.
Intent to Remove | Chromestatus Tracker | Bug Chromium
Interdire toutes les récupérations pour les scripts dont les attributs de type/langue sont non valides
Actuellement, l'outil d'analyse de préchargement de Chrome extrait les éléments des éléments <scripts>, quelle que soit la valeur de l'attribut type ou language, mais le script ne sera pas exécuté lors de l'analyse. En abandonnant la récupération, le scanner de préchargement et l'analyseur auront la même sémantique, et nous n'initierons pas de récupérations pour les scripts que nous n'utiliserons pas. Cette option permet d'économiser des données pour les utilisateurs qui accèdent à des sites comportant de nombreuses balises de script personnalisées qui sont post-traitées (comme type="text/template", par exemple).
Le cas d'utilisation consistant à utiliser des scripts non valides pour envoyer des requêtes ping aux serveurs est bien couvert par l'API sendBeacon.
Ce changement aligne Chrome sur Safari, bien que Firefox demande toujours des scripts, quel que soit leur type ou leur langue.
Projet de suppression | Outil de suivi de l'état de Chrome | Bug Chromium
Suppression de MediaStreamTrack.getSources()
Cette méthode ne fait plus partie de la spécification et n'est compatible avec aucun autre navigateur majeur. Il a été remplacé par MediaDevices.enumerateDevices(), qui est compatible avec Blink sans indicateur depuis la version 47 et qui est également compatible avec d'autres navigateurs. Vous trouverez un exemple ci-dessous. Cette fonction getCameras() hypothétique utilise d'abord la détection de caractéristiques pour rechercher et utiliser enumerateDevices(). Si la détection de fonctionnalités échoue, elle recherche getSources() dans MediaStreamTrack. Enfin, si aucune API n'est compatible, renvoyez le tableau cameras vide.
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);
}
};
Intent to Remove | Chromestatus Tracker | Bug Chromium
Suppression de la directive CSP réfléchie-xss
Les premières versions de la spécification Content Security Policy Level 2 contenaient une directive reflected-xss qui n'offrait rien de plus que l'en-tête X-XSS-Protection, à l'exception d'une syntaxe différente. Cette directive a été supprimée de la spécification en 2015, mais pas avant d'avoir été implémentée dans Chrome.
Cette directive ne sera plus acceptée.
Intent to Remove | Chromestatus Tracker | Bug Chromium
Remplacer la directive "referrer" du CSP
La directive CSP referrer permettait aux propriétaires de sites de définir une règle sur les URL de provenance à partir d'un en-tête HTTP. Non seulement cette fonctionnalité est très peu utilisée, mais elle ne fait plus partie d'aucune spécification W3C.
Les sites qui ont toujours besoin de cette fonctionnalité doivent utiliser <meta name="referrer"> ou le nouvel en-tête Referrer-Policy.
Intent to Remove | Chromestatus Tracker | Bug Chromium
Suppression du champ PaymentAddress.careOf
L'interface PaymentAddress comporte un champ careOf non standard (aucune norme d'adresse connue ne le prend en charge). Le champ careOf est également inutile. Les champs "Destinataire" et "Organisation" prennent en charge tous les cas d'utilisation nécessaires. L'ajout de careOf pose des problèmes importants en termes d'interopérabilité avec les API et les schémas d'adresse postale existants. Pour en savoir plus, consultez la proposition de suppression de la spécification sur GitHub.
Intention de suppression | Bug Chromium
Suppression de SVGViewElement.viewTarget
L'attribut SVGViewElement.viewTarget ne fait pas partie de la spécification SVG2.0, et son utilisation est faible ou inexistante. Abandonné dans Chrome 54, cet attribut a été supprimé.