1 pièce(s) jointe(s)
Chrome 80 est disponible avec un contenu mixte mis à jour automatiquement en HTTPS et autres nouveautés
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
Google a publié Chrome 79 il y a quelques jours 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. Hier, Google a annoncé sur son blogue que la version bêta de Chrome 80 est déjà disponible avant la publication de la version stable en 2020. Chrome 80 arrive avec une nouvelle API nommée Content Indexing. Les compressions Gzip et deflate supportent maintenant JavaScript, les flux audio et vidéo passent automatiquement en HTTPS si un site le permet et l'on note l’arrivée des Modules Workers.
Chrome 80 n’introduit pas de nouvelles fonctionnalités phares pour les utilisateurs simples. Par contre, du côté des développeurs, il apporte un certain nombre de nouvelles fonctions. Voici ci-dessous un aperçu de ce que Google a prévu pour Chrome 80.
L'API d’indexation de contenu
L’API d’indexation de contenu permet aux applications Web de connaître les ressources déjà en cache. Autrement dit, l’API d’indexation de contenu fournit des métadonnées sur le contenu que votre application Web a déjà mis en cache. Plus précisément, elle stocke les URL des documents HTML qui affichent les médias stockés. Elle vous permet d'ajouter, de lister et de supprimer des ressources. Selon l’équipe de développement de Chrome, les navigateurs peuvent utiliser les informations de l'index pour afficher une liste de contenu hors ligne.
L'API d'indexation de contenu est en cours d'essai dans une version d'origine de Chrome 80 à Chrome 82. Pour avoir plus de détails sur l'API, vous pouvez consulter les informations à son sujet sur le blogue pour les développeurs Chrome.
Les modules Workers
Les Web Workers sont disponibles dans la plupart des navigateurs depuis plus de dix ans. Par conséquent, la méthode pour importer des modules dans un worker, importScripts(), n'est plus à la pointe de la technologie depuis un certain temps. Elle bloque l'exécution du worker pendant qu'elle récupère et évalue le script importé. Elle exécute aussi les scripts dans le cadre global, ce qui peut conduire à des collisions de noms et aux problèmes associés. Google résout ce problème dans Chrome 80 en introduisant les « Modules Workers ».
Dans Chrome 80, le constructeur Worker supporte maintenant une option de type avec la valeur « module » qui modifie le chargement et l'exécution du script pour correspondre à <script type="module">. Les Modules Workers prennent en charge les importations JavaScript standard et l'importation dynamique pour le chargement paresseux sans bloquer l'exécution des Workers.
Mise à jour automatique du contenu mixte
Chrome met désormais à jour automatiquement le contenu vidéo et audio des sites Web HTTPS à partir de HTTP. En d’autres termes, Chrome 80 met à jour automatiquement le contenu HTTP des sites HTTPS en réécrivant les URL en HTTPS sans revenir au HTTP lorsque le contenu sécurisé n'est pas disponible. Dans cette version de Chrome, seuls les contenus audio et vidéo sont ainsi pris en charge.
L’API Contact Picker
L'API Contact Picker est un nouveau sélecteur à la demande pour Chrome sur Android qui 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. Il permet aux utilisateurs de partager uniquement ce qu'ils veulent, quand ils le veulent, et facilite l'accès et la connexion avec leurs amis et leur famille.
Décodage de supports cryptés
Les capacités de MediaCapabilities.decodingInfo() sont maintenant aussi disponibles pour les médias cryptés. La méthode decodingInfo() (disponible dans plusieurs navigateurs) permet aux sites Web d'obtenir plus d'informations sur les capacités de décodage du client. Cela permet une sélection plus éclairée des flux de média pour l'utilisateur, permettant des scénarios tels que le décodage fluide et efficace d'une vidéo pour la bande passante et la taille d'écran disponibles. La version bêta de Chrome 80 propose aussi d’autres modifications comme :
- la prise en charge de JavaScript pour Gzip et le dégonflement de la compression à l'aide de Streams ;
- le support des favicons basées sur SVG. « Enfin ! », diront les développeurs. ;
- le support des fragments d'URL de texte pour mettre en évidence du texte sur une page et faire défiler le texte vers ce fragment de texte via l'URL ;
- la dépréciation continue du support FTP avec maintenant seulement l'affichage des répertoires et le téléchargement des ressources ;
- etc.
Certains ajouts sont un peu plus proches des utilisateurs tout de même, comme le support de WebVR 1.1, qui permet la prise en charge de casques comme Oculus Rift et Google Cardboard.
Source : Chrome
Et vous ?
:fleche: Que pensez-vous des nouveautés de la version bêta de Chrome 80 ?
Voir aussi
:fleche: 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
:fleche: 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
:fleche: Chrome 78 est désormais disponible en bêta et apporte l'accès au système de fichiers natif, l'API SMS Receiver et bien d'autres
:fleche: Google annonce qu'il rendra le support FTP dans Chrome obsolète et procédera à sa suppression définitive à partir de Chrome 82 qui sera disponible en 2020
4 pièce(s) jointe(s)
Chrome 80 est disponible avec un contenu mixte mis à jour automatiquement en HTTPS, des changements de cookies
Chrome 80 est disponible avec un contenu mixte mis à jour automatiquement en HTTPS, des modifications de cookies, une API de sélection de contacts
Et bien d’autres changements
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 ?
:fleche: Qu’en pensez-vous ?
:fleche: Quelles sont les fonctionnalités qui retiennent votre attention ?
Lire aussi
:fleche: 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
:fleche: 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
:fleche: 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
:fleche: 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
