Sortie de Chrome 80

La société Google présentée la sortie du navigateur web Chrome 80. En même temps disponible version stable du projet open source Chromium, qui sert de base à Chrome. Le navigateur Chrome se distingue par l'utilisation des logos Google, la présence d'un système d'envoi de notifications en cas de crash, la possibilité de télécharger le module Flash sur demande, des modules pour la lecture de contenu vidéo protégé (DRM), un système de mise à jour automatique et la transmission lors des recherches des paramètres RLZ. La prochaine version de Chrome 81 est prévue pour le 17 mars.

Principales modifications dans Chrome 80:

• Pour un petit pourcentage d'utilisateurs, une fonctionnalité de regroupement des onglets est proposée, permettant de regrouper plusieurs onglets similaires en groupes visuellement distincts. À chaque groupe, on peut attacher une couleur et un nom propres. Les utilisateurs non inclus dans le premier lot d'activation peuvent activer le support du regroupement via l'option « chrome://flags/#tab-groups ».
  
• Le support de la fonction Scroll-To-Text, qui permet de créer des liens vers des mots ou des phrases spécifiques, sans mention explicite dans le document des balises par le biais de la balise « a name » ou de la propriété « id ». La syntaxe de ces liens devrait être validée comme norme web, qui est encore en phase brouillon. Le masque de transition (effectuant essentiellement une recherche avec défilement) se sépare de l'ancre classique par le signe « :~: ». Par exemple, en ouvrant le lien « https://opennet.ru/52312/#:~:text=Chromе », la page se déplacera vers la position avec la première mention du mot « Chromе » et ce mot sera mis en surbrillance.
• Appliqué une restriction plus stricte concernant le transfert de Cookies entre sites, interdisant le traitement des Cookies tiers lors des requêtes non HTTPS, qui sont émis lors de l'accès à des sites autres que le domaine de la page actuelle. Ces Cookies sont utilisés pour suivre les mouvements de l'utilisateur entre les sites dans le code des réseaux publicitaires, des widgets de réseaux sociaux et des systèmes d'analyse web. Rappelons que la gestion du transfert de Cookies utilise l'attribut SameSite indiqué dans l'en-tête Set-Cookie, qui est désormais par défaut réglé sur « SameSite=Lax », limitant l'envoi de Cookies pour les sous-requêtes intersites, telles que la demande d'image ou le chargement de contenu via iframe depuis un autre site. Les sites peuvent remplacer le mode SameSite par défaut en précisant la valeur SameSite=None lors de l'établissement des Cookies. Cependant, la valeur SameSite=None pour les Cookies ne peut être définie qu'en mode Secure (pour les connexions via HTTPS). Le changement commencera par des étapes s'appliquer le 17 février, d'abord pour un petit pourcentage d'utilisateurs, puis en élargissant progressivement la portée.
• Ajouté protection contre les notifications intrusives liées à la confirmation des permissions. Étant donné que de telles activités, par exemple, le spam avec des demandes de notifications push, interrompent le travail de l'utilisateur et détournent l'attention vers les actions dans les dialogues de confirmation, dans Chrome 80, au lieu d'une boîte de dialogue distincte, une infobulle peut désormais s'afficher dans la barre d'adresse avec un avertissement sur le blocage de la demande de permission, qui se réduit ensuite en un indicateur avec une cloche barrée. En cliquant sur l'indicateur, il est possible d'accepter ou de refuser la permission demandée à tout moment. Le nouveau mode sera activé automatiquement de manière sélective pour les utilisateurs qui avaient précédemment tendance à bloquer ce type de demandes, ainsi que pour les sites où un taux élevé de refus de demandes est constaté. Une option spéciale a été ajoutée aux paramètres pour activer le nouveau mode pour toutes les demandes (chrome://flags/#quiet-notification-prompts).
  
• Interdit l'affichage de fenêtres contextuelles (en appelant la méthode window.open()) et l'envoi de requêtes synchrones XMLHttpRequest dans les gestionnaires d'événements de fermeture ou de masquage de page (unload, beforeunload, pagehide et visibilitychange);
• Une protection initiale proposée de charger du contenu multimédia mixte (lorsque des ressources sont chargées via le protocole http sur une page HTTPS). Sur les pages ouvertes en HTTPS, les liens «http://» seront désormais automatiquement remplacés par «https://» dans les blocs liés à la lecture de fichiers audio et vidéo. Si une ressource audio ou vidéo n'est pas disponible sur https, son chargement sera bloqué (il est possible de marquer le blocage manuellement via le menu accessible via l'icône du cadenas dans la barre d'adresse).

  Les images continueront à se charger sans changement (le remplacement automatique sera appliqué dans Chrome 81), mais pour le remplacement en https ou le blocage des images, les développeurs de sites disposent des propriétés CSP upgrade-insecure-requests et block-all-mixed-content. Pour les scripts et les iframe, le blocage du contenu mixte a déjà été mis en œuvre auparavant.

• Le processus de désactivation du support FTP a commencé. Par défaut, le support FTP reste pour l'instant en place, mais un expériment sera réalisé, dans lequel pour un certain pourcentage d'utilisateurs, le support FTP sera désactivé (pour revenir, il faudra lancer le navigateur avec l'option «—enable-ftp»). Rappelons qu'auparavant, l'affichage dans la fenêtre du navigateur du contenu des ressources chargées via le protocole «ftp://» (par exemple, l'affichage des documents HTML et des fichiers README a été interrompu), l'utilisation de FTP pour le chargement de sous-ressources à partir de documents a été interdite et le support du proxy pour FTP a cessé. Néanmoins, il était encore possible de charger des fichiers via des liens directs et d'afficher le contenu des répertoires.
• Ajouté
  la possibilité d'utiliser des images SVG vectorielles comme icône de site (favicon).
• Dans les paramètres, la possibilité de désactiver sélectivement certains types de données transmises lors de la synchronisation entre les navigateurs a été ajoutée.
• Pour les utilisateurs d'entreprise administrés de manière centralisée, une règle a été ajoutée BlockExternalExtensions, permettant d'interdire l'installation d'extensions externes sur l'appareil.
• Mise en œuvre de la possibilité vérification instantanée de toute la chaîne de propriétés ou d'appels en JavaScript. Par exemple, lors de l'accès à «db.user.name.length», il était auparavant nécessaire de vérifier étape par étape la définition de toutes les parties composées, par exemple via «if (db && db.user && db.user.name)». Désormais, grâce à l'opération «?.», vous pouvez accéder à la valeur «db?.user?.name?.length» sans vérifications préalables, et cet accès ne déclenchera pas d'erreur. En cas de problème (si un élément est traité comme null ou undefined), la sortie sera «undefined».
• Un nouvel opérateur logique de fusion «??«, qui renvoie l'opérande de droite si l'opérande de gauche a la valeur NULL ou undefined, et vice versa. Par exemple, «const foo = bar ?? ‘chaîne par défaut'» si bar est égal à null, renverra la chaîne ou la valeur de bar dans le cas contraire, y compris lorsque bar est égal à 0 et ‘ ‘, contrairement à l'opérateur «||».
• Dans le mode Origin Trials (fonctionnalités expérimentales nécessitant une activation) un API de Content Indexing a été proposé. Le trial d'origine implique la possibilité de travailler avec cette API à partir d'applications chargées depuis localhost ou 127.0.0.1, ou après enregistrement et obtention d'un jeton spécial, qui est valide un temps limité pour un site spécifique. L'API Content Indexing, fournit des métadonnées sur le contenu qui a été précédemment mis en cache par des applications web fonctionnant en mode Progressive Web Apps (PWA). L'application peut sauvegarder divers types de données dans le navigateur, y compris des images, des vidéos et des articles, et en cas de perte de connexion réseau, les utiliser via l'API Cache Storage et IndexedDB. L'API Content Indexing permet d'ajouter, de trouver et de supprimer de telles ressources. Dans le navigateur, cette API est déjà utilisée pour l'énumération des pages et des données multimédias disponibles à visualiser hors ligne.
  
• L'interface de programmation a été stabilisée et est maintenant distribuée en dehors des Origin Trials Contact Picker, permettant à l'utilisateur de sélectionner des enregistrements dans son carnet d'adresses et de transmettre certaines informations sur ceux-ci au site. Lors de la requête, une liste de propriétés à récupérer est définie. Ces propriétés sont clairement affichées à l'utilisateur, qui décide ensuite si elles doivent être transmises ou non. L'API peut être utilisée, par exemple, dans un client web de messagerie pour choisir les destinataires d'un e-mail envoyé, dans une application web avec fonction VoIP pour initier un appel vers un numéro spécifique ou dans un réseau social pour rechercher des amis déjà enregistrés. Dans le cadre des Origin Trials, certaines nouvelles propriétés du sélecteur de contacts ont été proposées : en plus des informations précédemment disponibles comme le nom complet, l'email et le numéro de téléphone, la possibilité de transmettre une adresse postale et une image a été ajoutée.
• Dans les Web Workers a été proposé une nouvelle méthode de chargement de modules ECMAScript, permettant de se passer de la fonction importScripts(), qui bloque le fonctionnement du worker pendant le traitement du script importé et l'exécute dans le contexte global. La nouvelle méthode implique la création de modules spéciaux pour les Web Workers, qui prennent en charge les mécanismes d'importation standard de JavaScript et peuvent être chargés dynamiquement, sans bloquer l'exécution du worker. Pour le chargement des modules, un nouveau type de ressource a été prévu dans le constructeur Worker — ‘module’ :

  const worker = new Worker(‘worker.js’, {
  type: ‘module’
  });

• Mise en œuvre de une fonctionnalité intégrée de traitement en JavaScript pour les flux compressés, ne nécessitant pas de bibliothèques externes. Pour la compression et la décompression, des API ont été ajoutées CompressionStream et DecompressionStream. La compression utilisant les algorithmes gzip et deflate est supportée.

  const compressionReadableStream
  = inputReadableStream.pipeThrough(new CompressionStream(‘gzip’));

• Une propriété CSS «line-break: anywhere«, permettant des ruptures au niveau de tout caractère typographique, y compris des ruptures à proximité de signes de ponctuation, des espaces prédéfinis (<pre>) et au milieu des mots. Une autre propriété CSS «overflow-wrap: anywhere» a également été ajoutée, permettant de rompre des séquences de caractères non séparables à tout moment, si aucune position adéquate pour la rupture n'a pu être trouvée dans la ligne.
• Pour le contexte multimédia, traité de manière chiffrée, le support de la méthode MediaCapabilities.decodingInfo(), fournissant des informations sur les capacités du navigateur liées au décodage de contenu protégé (par exemple, la méthode spécifiée peut être utilisée pour choisir des scénarios de décodage de haute qualité ou économisant de l'énergie, en tenant compte de la bande passante disponible et de la taille de l'écran).
• Méthode ajoutée HTMLVideoElement.getVideoPlaybackQuality(), permettant d'obtenir des informations sur la performance de la lecture vidéo pour ajuster le débit binaire, la résolution et d'autres paramètres vidéo.
• Dans l'API Payment Handler, qui facilite l'intégration avec les systèmes de paiement existants, la possibilité a été ajoutée de délégation du traitement des adresses et des informations de contact à un gestionnaire de paiement externe (l'application du système de paiement peut disposer d'informations plus précises que le navigateur).
• Ajout du support de l'en-tête HTTP Sec-Fetch-Dest, permettant d'envoyer des métadonnées supplémentaires sur le type de contenu lié à la demande (par exemple, pour une demande via une balise img, le type 'image' est spécifié, pour les polices — 'font', pour les scripts — 'script', pour les styles — 'style', etc.). Sur la base du type spécifié, le serveur peut prendre des mesures pour se protéger contre certains types d'attaques (par exemple, il est peu probable qu'un lien vers un gestionnaire pour effectuer un transfert d'argent soit défini via une balise img, donc ces demandes n'ont pas besoin d'être traitées).
• Dans le moteur JavaScript V8 une optimisation a été réalisée du stockage des pointeurs dans le tas. Au lieu de stocker une valeur complète de 64 bits, seul les bits inférieurs uniques du pointeur sont conservés. Une telle optimisation a permis de réduire la consommation de mémoire dans le tas de 40 %, en contrepartie d'une diminution des performances de 3 à 8 %.
  
  
• Changements dans les outils pour les développeurs web :
  • Dans la console web, il est désormais possible de redéfinir les expressions let et class.
    
  • Les outils de débogage WebAssembly ont été améliorés. Ajout du support DWARF pour le débogage étape par étape, la définition de points d'arrêt et l'analyse des traces de pile dans le code source sur lequel l'application WebAssembly est écrite.
    
  • Le panneau d'analyse de l'activité réseau a été amélioré. Ajout de la possibilité de visualiser la chaîne d'appels de scripts associée à l'initiation de la demande.
    

    De nouvelles colonnes Path et URL ont été ajoutées, affichant le chemin absolu et l'URL complète pour chaque ressource réseau. La requête sélectionnée est mise en surbrillance dans le graphique récapitulatif.

    
  • Un option a été ajoutée dans l'onglet Network Conditions pour modifier le paramètre User-Agent.
    
  • Une nouvelle interface pour la configuration du panneau d'audit a été proposée.
    
  • Dans l'onglet Coverage un choix est maintenant offert pour la collecte des données de couverture pour chaque fonction ou bloc de code (statistiques plus détaillées, mais nécessitant plus de ressources).
    
• L'action du manifeste AppCache (technologie pour organiser le fonctionnement des applications web en mode hors ligne) est limitée au répertoire actuel du site (si le manifeste a été chargé depuis www.example.com/foo/bar/, la possibilité de redéfinir l'URL ne sera valable que dans /foo/bar/). Dans Chrome 82, le support d'AppCache devrait être complètement supprimé. Cela est justifié par le désir de supprimer l'un des vecteurs pour les attaques liées au script intersite. Au lieu d'AppCache, l'utilisation de l'API Cache.
• La prise en charge des propriétés -moz-column-* a été interrompue, et il convient d'utiliser les propriétés standard sans préfixe. le support de l'API WebVR 1.1 est obsolète, remplaçable par l'API WebXR Device, permettant d'accéder aux composants pour créer des réalités virtuelles et augmentées, et unifier le travail avec différentes classes d'appareils, des casques de réalité virtuelle stationnaires aux solutions mobiles.
• Les gestionnaires de protocoles, connectés via les méthodes registerProtocolHandler() et unregisterProtocolHandler(), ne peuvent maintenant fonctionner que dans un contexte sécurisé (accès via HTTPS).

En plus des nouveautés et des corrections de bogues, la nouvelle version corrige 56 vulnérabilités. De nombreuses vulnérabilités ont été identifiées grâce à des tests automatisés réalisés avec des outils AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer et AFL. Aucune problème critique permettant de contourner tous les niveaux de protection du navigateur et d'exécuter du code en dehors de l'environnement sandbox n'a été détecté. Dans le cadre du programme de récompenses pour la découverte de vulnérabilités pour cette version, Google a versé 37 primes d'un total de 48 000 dollars (une prime de 10 000 dollars, trois primes de 5 000 dollars, trois primes de 3 000 dollars, quatre primes de 2 000 dollars, trois primes de 1 000 dollars et six primes de 500 dollars). Le montant de 17 primes n'est pas encore déterminé.

Source : opennet.ru