Dans presque chaque version de Chrome, nous constatons un grand nombre de mises à jour et d'améliorations du produit, de ses performances et des fonctionnalités de la plate-forme Web. Cet article décrit les abandons et les suppressions dans Chrome 56, qui est en version bêta depuis le 8 décembre. Cette liste est susceptible d'être modifiée à tout moment.
Supprimer la compatibilité avec les certificats SHA-1
L'algorithme de hachage cryptographique SHA-1 a montré des signes de faiblesse il y a plus de 11 ans, et des recherches récentes indiquent qu'il est possible d'attaquer directement l'intégrité de l'infrastructure à clé publique (PKI) du Web.
Pour protéger les utilisateurs contre de telles attaques, Chrome ne prend plus en charge les certificats SHA-1 à partir de Chrome 56, dont la version stable est en janvier 2017. Lorsque vous consultez un site à l'aide d'un tel certificat, un avertissement interstitiel s'affiche. Pour en savoir plus, consultez le blog sur la sécurité de Chrome.
Intention de suppression | Outil de suivi Chromestatus | Bug Chromium
Supprimer les algorithmes de chiffrement ECDSA en mode CBC dans TLS
La construction de TLS en mode CBC est défectueuse, ce qui le rend fragile et très difficile à mettre en œuvre 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, mais nous pensons 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 n'acceptent que RSA). Par conséquent, nous nous attendons à ce que les sites ECDSA soient mieux gérés et plus réactifs en cas de problème.
TLS 1.2 a ajouté de nouveaux algorithmes de chiffrement basés sur les AEAD, ce qui permet d'éviter ces problèmes, en particulier AES_128_GCM, AES_256_GCM ou CHACHA20_POLY1305. Bien que nous ne l'ayons obligatoire pour le moment que pour les sites basés sur ECDSA, nous la recommandons à tous les administrateurs. Les chiffrements basés sur AEAD améliorent non seulement la sécurité, mais aussi les performances. AES-GCM offre une compatibilité matérielle sur les processeurs récents, tandis que ChaCha20-Poly1305 accepte les implémentations logicielles rapides. En revanche, les algorithmes de chiffrement CBC nécessitent des stratégies d'atténuation des risques complexes lents et un accès au PRNG sur chaque enregistrement sortant. Les algorithmes de chiffrement basés sur AEAD constituent également une condition préalable à l'optimisation du protocole HTTP/2 et du faux démarrage.
Intention de suppression | Outil de suivi Chromestatus | Bug Chromium
Supprimer les gestes de l'utilisateur du défilement tactile
Nous avons vu plusieurs exemples d'annonces mal rédigées ou malveillantes qui déclenchent la navigation lors des défilements tactiles sur touchstart ou tous les événements touchend. Si un événement "roue" ne peut pas ouvrir de pop-up, le défilement tactile ne devrait pas non plus s'appliquer. Cela peut perturber certains scénarios, tels que l'impossibilité de lire un contenu multimédia ou des pop-ups qui ne s'ouvrent pas lorsque l'utilisateur appuie sur l'écran. Safari ne parvient déjà pas à ouvrir les pop-ups en mode silencieux dans tous ces scénarios.
Intention de suppression | Outil de suivi Chromestatus | Bug Chromium
Interdire toutes les récupérations pour les scripts dont les attributs de type/langue ne sont pas valides
Actuellement, l'analyseur de préchargement de Chrome récupère les éléments dans les éléments <scripts>, quelle que soit la valeur de l'attribut type ou language, bien que le script ne soit pas exécuté lors de l'analyse. Si vous abandonnez la récupération, l'analyseur de préchargement et l'analyseur auront la même sémantique, et nous n'exécuterons pas de récupérations pour les scripts que nous n'utiliserons pas. Cela permet d'enregistrer des données pour les utilisateurs qui accèdent à des sites contenant de nombreux tags de script personnalisés post-traités (comme type="text/template", par exemple).
Le cas d'utilisation de scripts non valides pour pinguer les serveurs est correctement couvert par l'API sendBeacon.
Cette modification aligne Chrome avec Safari, bien que Firefox demande toujours des scripts, quels que soient leur type ou leur langue.
Intention de suppression | Outil de suivi Chromestatus | 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 important. Elle a été remplacée 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 trouver et utiliser enumerateDevices(). Si la détection des fonctionnalités échoue, elle recherche getSources() dans MediaStreamTrack. Enfin, en l'absence de compatibilité d'API d'une quelconque sorte, 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);
}
};
Intention de suppression | Outil de suivi Chromestatus | Bug Chromium
Suppression de la directive CSP reflété-xss
Les premières versions de la spécification Content Security Policy (niveau 2 de la Content Security Policy) contenaient une directive reflected-xss qui ne proposait rien de plus que l'en-tête X-XSS-Protection, hormis une syntaxe différente. Cette directive a été supprimée de la spécification en 2015, mais pas avant son implémentation dans Chrome.
La prise en charge de cette directive est en cours de suppression.
Intention de suppression | Outil de suivi Chromestatus | Bug Chromium
Remplacer la directive CSP "referrer"
La directive CSP referrer permettait aux propriétaires de sites de définir une règle d'URL de provenance à partir d'un en-tête HTTP. Cette fonctionnalité est non seulement très peu utilisée, mais elle ne fait plus partie des spécifications W3C.
Les sites qui ont toujours besoin de cette fonctionnalité doivent utiliser <meta name="referrer"> ou le nouvel en-tête Referrer-Policy.
Intention de suppression | Outil de suivi Chromestatus | Bug Chromium
Supprimer le 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, car les champs "Destinataire" et "Organisation" prennent suffisamment 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'adresses postales existants. Pour en savoir plus, consultez la proposition de suppression de spécifications sur GitHub.
Intention de suppression | Bug Chromium
Supprimer SVGViewElement.viewTarget
L'attribut SVGViewElement.viewTarget ne fait pas partie de la spécification SVG2.0 et son utilisation est faible ou inexistante. Cet attribut était obsolète dans Chrome 54 et a été supprimé.
Intention de suppression | Outil de suivi Chromestatus | Bug Chromium