Google a publié mardi Chrome 80, la dernière version de son navigateur Web phare pour les utilisateurs de Windows, Mac, Linux, Android et iOS. La précédente version, Chrome 79, avait été publiée en décembre avec de nombreuses fonctionnalités, comme la prise en charge intégrée de l'outil Password Checkup, ainsi des corrections de bogues. Cette dernière mise à jour, annoncée en fin d’année dernière, corrige également plusieurs problèmes de sécurité et apporte de nouvelles fonctionnalités telles que la mise à jour automatique du contenu mixte en HTTPS, la modification des cookies SameSite, une interface utilisateur plus silencieuse pour les notifications et davantage de fonctionnalités pour les développeurs.Chrome 80 renforce donc la sécurité du navigateur le plus populaire et commence à réprimer les cookies intersites. À l’endroit des développeurs, qui doivent se tenir informés de tout ce qui est disponible dans le navigateur, Google a annoncé plusieurs fonctionnalités telles que la compression des flux, une amélioration du CSS, le décodage des supports chiffrés et bien d’autres fonctionnalités.
Voici quelques changements que Google a publiés avec Chrome 80 :
Mise à jour automatique des contenus mixtes
Le HTTPS est une version plus sécurisée du protocole HTTP utilisé sur Internet pour connecter les utilisateurs aux sites Web. Les connexions sécurisées sont largement considérées comme une mesure nécessaire pour réduire le risque que les utilisateurs soient vulnérables à l'injection de contenu (qui peut entraîner des écoutes, des attaques de type "man-in-the-middle" et d'autres modifications de données).
Google continue à inciter les développeurs à abandonner le HTTP afin de faire passer le Web au HTTPS. Il a présenté en octobre son plan concernant la façon dont Chrome étiquette les sites HTTP et HTTPS. En décembre dernier, Chrome 79 a introduit un paramètre permettant de débloquer les scripts mixtes, les iframes et autres types de contenu que le navigateur bloque par défaut, que les utilisateurs peuvent activer à partir de l’icône de verrouillage sur les pages HTTPS.
Selon l’annonce de mardi, lorsque le contenu sécurisé n'est pas disponible, Chrome 80 met automatiquement à niveau les ressources audio et vidéo mixtes des sites HTTPS en réécrivant les URL en HTTPS sans revenir au HTTP. Et si elles ne se chargent pas sur HTTPS, Chrome les bloque par défaut, à l’exception des images mixtes qui sont toujours autorisées à se charger, mais Chrome marquera la page comme "non sécurisée" dans l'omnibox.
Dans Chrome 81, qui sera lancé à partir du mois d'avril, Google dit que les images mixtes seront automatiquement mises à niveau en HTTPS. Si elles ne se chargent pas en HTTPS, Chrome les bloquera par défaut. L'objectif ultime de Google étant de garantir que les pages HTTPS dans son navigateur Chrome, utilisé par plus d'un milliard d'utilisateurs, ne puissent charger que des sous-ressources HTTPS sécurisées.
Modification des cookies SameSite
L'attribut SameSite a été introduit en mai 2016 avec Chrome 51 pour permettre aux sites de déclarer si les cookies doivent être limités au contexte d’un même site, espérant que cela atténuerait les contrefaçons de requêtes intersites.
Chrome 80 vient avec un nouveau système de classification des cookies sécurisé par défaut, qui traitera les cookies qui n'ont pas de valeur SameSite déclarée comme des cookies SameSite=Lax – seuls les cookies ayant la valeur SameSite=None ; Secure seront disponibles dans des contextes tiers, et encore faut-il qu’ils qu'ils soient accessibles à partir de connexions sécurisées (Secure). Dorénavant, Chrome 80 supprimera les comportements rétrocompatibles dans les cas suivants :
Premièrement, l'attribut SameSite dont la valeur par défaut est "None" sera désactivé. En effet, SameSite est désormais défini par défaut sur Lax, ce qui signifie que vos cookies ne sont accessibles qu'à d'autres sites à partir de navigations de haut niveau. Tel que mis en œuvre à l'origine dans Chrome, l'attribut SameSite a pour valeur par défaut "None", ce qui correspond essentiellement au statu quo du Web. Deuxièmement, la valeur "None" n'est plus autorisée dans les contextes peu sûrs, Chrome exige à partir de la version 80 que lorsque l'attribut SameSite est défini sur "None", l'attribut Secure doit également être présent. L'attribut Secure exige que le cookie attaché ne puisse être transmis que par un protocole sécurisé tel que HTTPS.
Google commencera la mise en œuvre du nouveau système de classification des cookies dans Chrome 80 dans deux semaines « avec une petite population d'utilisateurs, qui augmentera progressivement au fil du temps ». Le chronogramme exact des mises à jour sera disponible sur la page des mises à jour de SameSite, d’après la société.
Système de notifications plus silencieuses
À partir de Chrome 80, Google tente de rendre moins ennuyeuses les demandes d'autorisation non sollicitées. Chrome 80 affichera désormais parfois une interface de notification de permission plus silencieuse. Les utilisateurs du navigateur peuvent choisir volontairement la nouvelle interface dans Paramètres => Paramètres du site => Notifications. Google dit qu’elle sera également activée automatiquement sous deux conditions : pour les utilisateurs qui bloquent généralement les demandes d'autorisation de notification et sur les sites où le taux d'acceptation est très faible.
Il faut noter que l'interface utilisateur "plus silencieuse" est disponible à la fois sur les ordinateurs de bureau et les téléphones portables. Google prévoit également d'activer, dans le courant de l'année, des mesures supplémentaires pour lutter contre les « sites Web abusifs qui utilisent les notifications web à des fins publicitaires, malveillantes ou trompeuses ».
Google veut que les développeurs suivent les meilleures pratiques en demandant l'autorisation de notification aux utilisateurs. La société indique à sujet :
« Les sites Web qui demandent aux utilisateurs de s'inscrire pour recevoir des notifications Web dès leur arrivée ont souvent un taux d'acceptation très faible. Nous recommandons plutôt aux sites Web d'attendre que les utilisateurs comprennent le contexte et voient l'intérêt de recevoir des notifications avant de demander l'autorisation. Certains sites Web affichent une préinterrogation dans la zone de contenu avant de déclencher l'invite de permission native. Cette approche n'est pas non plus recommandée si elle interrompt le parcours de l'utilisateur : les sites qui demandent l'autorisation à des moments pertinents du point de vue du contexte bénéficient d'un taux de rebond plus faible et de taux de conversion plus élevés ».
API de sélection de contacts et API d'indexation de contenu
L'API de sélection de contacts permet aux utilisateurs de sélectionner des entrées dans leur liste de contacts et de partager des détails limités des entrées sélectionnées avec un site Web. Elle a été testée pour la première fois lorsque Google a lancé "Origin Trials", qui permet aux utilisateurs d'essayer de nouvelles fonctionnalités. Chrome 80 propose désormais l'API Contact Picker, mettant ainsi fin au premier essai d'origine. Actuellement, seuls le nom, l'adresse électronique et le numéro de téléphone du contact sont disponibles via ContactsManager.getProperties(). Mais Chrome 80 a lancé un nouvel essai dans le cadre de "Origin Trials", qui ajoute des fonctionnalités à l'API. Le nouveau "Origin Trial" ajoute l'adresse postale ("adresse") et l'image ("icône") de l'utilisateur à l’API.
L'API d'indexation du contenu, qui fournit des métadonnées sur le contenu que votre application Web a déjà mis en cache, est un autre essai d’origine lancé dans Chrome 80 par Google. Elle stocke les URL des documents HTML qui affichent les médias stockés, et vous permet d'ajouter, de lister et de supprimer des ressources. Alors que les applications Web progressives (PWA) peuvent stocker des contenus tels que des images, des vidéos, des articles et autres pour un accès hors ligne en utilisant l'API de stockage en cache ou l’indexéeDB, ce contenu n'est pas détectable. Il l'est désormais et peut même être utilisé si le réseau n'est pas disponible, d’après Google.
Correctifs de sécurité
Chrome 80 vient avec 56 correctifs de problèmes de sécurité découverts par des chercheurs externes. En voici quelques-uns :
- [5 000 $] [1034394] High CVE-2020-6381 : débordement d'entier en JavaScript. Signalé par le Centre national de cybersécurité du Royaume-Uni (NCSC) le 2019-12-09
- [2000 $] [1031909] High CVE-2020-6382 : type Confusion en JavaScript. Signalé par Soyeon Park et Wen Xu de la SSLab, Gatech le 2019-12-08
- [500 $] [1020745] High CVE-2019-18197 : multiples vulnérabilités dans le XML. Signalé par l'équipe de réponse aux incidents de sécurité des BlackBerry le 2019-11-01
- [500 $] [1042700] High CVE-2019-19926 : implémentation inappropriée dans SQLite. Rapporté par Richard Lorenz, SAP le 2020-01-16
Fonctionnalités pour développeurs
Dans Chrome 80, Google introduit les modules ECMAScript dans Web Workers, un outil permettant au contenu web d'exécuter des scripts dans des tâches d'arrière-plan. Les Module Workers prennent en charge les importations JavaScript standard et l'importation dynamique pour le lazy-loading sans bloquer l'exécution de Worker. Ceci est utile, car importScripts() exécute les scripts dans le cadre global, ce qui peut entraîner des collisions de noms et les problèmes associés, et il bloque l'exécution de Worker pendant qu'il récupère et évalue le script importé.
Chrome 80 apporte également une mise à jour du moteur JavaScript V8. La version 8.0 comprend la compression des pointeurs, l'optimisation des éléments intégrés d'ordre supérieur et des fonctionnalités JavaScript comme optional chaining et nullish coalescing. Chrome 80 apporte de nombreuses autres fonctionnalités pour les développeurs telles que la compression des flux et une amélioration du CSS, et bien d’autres nouveautés que vous pourrez consulter dans la note de version de Google.
Source : Google
Et vous ?
Qu’en pensez-vous ? Quelles sont les fonctionnalités qui retiennent votre attention ?Lire aussi
Google annonce la disponibilité de la version bêta de Chrome 80, avec l'API d'indexation de contenu, les modules Workers et bien d'autres Chrome 79 est disponible avec le gel des onglets, le blocage par défaut des « subresources » non sécurisées HTTP sur les pages HTTPS, et d'autres fonctionnalités Google annonce que Chrome va bloquer par défaut les « subresources » non sécurisées HTTP sur les pages HTTPS, cette mesure sera implémentée à partir de la version 79 et parachevée avec la version 81 Les grands FAI américains ne sont pas emballés par les projets de Google concernant le chiffrement DNS, voici pourquoi ils s'opposent à la mise en place du protocole DoH sur Chrome