Sortie de Chrome 91

La société Google a présenté la version 91 de son navigateur web Chrome. En même temps, une version stable du projet open source Chromium, qui est à la base de Chrome, est disponible. Le navigateur Chrome se distingue par l'utilisation des logos de Google, un système d'envoi de notifications en cas de crash, des modules pour la lecture de contenu vidéo protégé (DRM), un système de mise à jour automatique et le transfert des paramètres RLZ lors de la recherche. La prochaine version, Chrome 92, est prévue pour le 20 juillet.

Principales modifications de Chrome 91 :

• Il est désormais possible d'arrêter l'exécution de JavaScript dans un groupe d'onglets réduit. Chrome 85 a introduit la prise en charge des groupes d'onglets, qui peuvent être associés à une couleur spécifique et à une étiquette. En cliquant sur l'étiquette du groupe, les onglets associés se réduisent et une seule étiquette reste (un nouveau clic sur l'étiquette développe le groupe). Dans cette nouvelle version, afin de réduire la charge sur le CPU et d'économiser de l'énergie, l'activité est suspendue dans les onglets réduits, à l'exception de ceux où le son est joué, où l'API Web Locks ou IndexedDB est utilisée, où une connexion à un périphérique USB est établie, ou où un enregistrement vidéo, audio ou de contenu d'écran est en cours. Ce changement sera mis en œuvre progressivement, à commencer par un petit pourcentage d'utilisateurs.
• La prise en charge de la méthode d'accord de clés résistante aux tentatives de cassage par des ordinateurs quantiques a été ajoutée. Les ordinateurs quantiques résolvent de manière radicalement plus rapide le problème de la factorisation d'un nombre naturel en nombres premiers, qui est à la base des algorithmes de cryptographie asymétrique modernes et qui est efficacement insoluble sur des processeurs classiques. Un plugin CECPQ2 (Combined Elliptic-Curve and Post-Quantum 2), combinant le mécanisme classique d'échange de clés X25519 avec le schéma HRSS basé sur l'algorithme NTRU Prime, a été fourni pour une utilisation dans TLSv1.3 et spécialement conçu pour les cryptosystèmes post-quantiques.
• Le support des protocoles TLS 1.0 et TLS 1.1 a été complètement arrêté, ces derniers étant classés par le comité IETF (Internet Engineering Task Force) comme obsolètes. Il n'est plus possible de revenir à TLS 1.0/1.1 en modifiant la politique SSLVersionMin.
• Les assemblages pour la plateforme Linux intègrent le mode « DNS sur HTTPS » (DoH, DNS over HTTPS), qui a été précédemment mis à disposition des utilisateurs de Windows, macOS, ChromeOS et Android. DNS-over-HTTPS sera activé automatiquement pour les utilisateurs dont les paramètres spécifient des fournisseurs de DNS qui prennent en charge cette technologie (pour DNS-over-HTTPS, le même fournisseur utilisé pour DNS sera appliqué). Par exemple, si un utilisateur a configuré DNS 8.8.8.8 dans ses paramètres système, alors dans Chrome, le service DNS-over-HTTPS de Google (« https://dns.google.com/dns-query ») sera activé ; si le DNS est 1.1.1.1, alors le service DNS-over-HTTPS de Cloudflare (« https://cloudflare-dns.com/dns-query ») sera activé, etc.
• Le port 10080, qui est utilisé dans Amanda backup et VMWare vCenter, a été ajouté à la liste des ports réseau interdits. Auparavant, les ports 69, 137, 161, 554, 1719, 1720, 1723, 5060, 5061 et 6566 avaient déjà été bloqués. Pour les ports sur liste noire, l'envoi de requêtes HTTP, HTTPS et FTP est bloqué pour se protéger contre l'attaque de NAT slipstreaming, qui permet d'établir une connexion réseau entre le serveur de l'attaquant et n'importe quel port UDP ou TCP sur le système de l'utilisateur, même en utilisant un plage d'adresses interne (192.168.x.x, 10.x.x.x).
• Il est désormais possible de configurer le démarrage automatique des applications web isolées (PWA — Progressive Web Apps) lors de la connexion de l'utilisateur au système (Windows et macOS). Le démarrage automatique s'configure sur la page chrome://apps. Cette fonctionnalité est actuellement testée sur un petit pourcentage d'utilisateurs et nécessite l'activation du paramètre « chrome://flags/#enable-desktop-pwas-run-on-os-login » pour les autres.
• Dans le cadre de la démarche visant à transformer le navigateur pour adopter une terminologie inclusive, le fichier « master_preferences » a été renommé en « initial_preferences ». Pour maintenir la compatibilité, le support de « master_preferences » sera encore conservé dans le navigateur pendant un certain temps. Auparavant, le navigateur avait déjà abandonné l'utilisation des termes « whitelist », « blacklist » et « native ».
• Dans le mode de protection avancé contre les sites dangereux (Enhanced Safe Browsing), qui active des vérifications supplémentaires pour se protéger contre le phishing, l'activité malveillante et d'autres menaces sur le Web, il est désormais possible d'envoyer des fichiers téléchargés pour une vérification côté Google. De plus, Enhanced Safe Browsing prend en compte les jetons associés au compte Google lors de la détection des tentatives de phishing, ainsi que l'envoi aux serveurs Google des valeurs de l'en-tête Referrer pour vérifier le passage depuis un site malveillant.
• La version pour la plateforme Android a amélioré la présentation des éléments des formulaires web, qui ont été optimisés pour une utilisation sur les écrans tactiles et les systèmes pour les personnes handicapées (la présentation pour les systèmes de bureau a été retravaillée dans Chrome 83). L'objectif de cette refonte était de créer une uniformité dans la présentation des éléments de formulaire et d'éliminer les incohérences de style : auparavant, certains éléments de formulaire étaient conçus selon les éléments d'interface des systèmes d'exploitation, tandis que d'autres suivaient les styles les plus populaires. Cela a causé des différences dans la façon dont les éléments étaient adaptés aux écrans tactiles et aux systèmes pour les personnes handicapées.
• Un sondage sur l'opinion des utilisateurs a été ajouté, affiché lors de l'ouverture des paramètres de Privacy Sandbox (chrome://settings/privacySandbox).
• Lors du lancement de la version Android de Chrome sur des tablettes à grand écran, la demande de la version de bureau du site est assurée, et non la version mobile. Ce comportement peut être modifié via le réglage « chrome://flags/#request-desktop-site-for-tablets ».
• Le code de rendu des tableaux a été refait, ce qui a permis de résoudre des problèmes d'incohérence de comportement dans l'affichage des tableaux entre Chrome et Firefox/Safari.
• Le traitement des certificats serveur de l'autorité de certification espagnole Camerfirma a été arrêté en raison d'incidents répétés depuis 2017, liés à des violations lors de la délivrance de certificats. La prise en charge des certificats clients est maintenue, et le blocage ne s'applique qu'aux certificats utilisés sur les sites pour HTTPS.
• La mise en œuvre du support de la segmentation du réseau pour protéger contre les méthodes de suivi des mouvements des utilisateurs entre les sites, basées sur le stockage d'identifiants dans des zones non destinées au stockage permanent d'informations (« Supercookies »), est poursuivie. Comme les ressources mises en cache sont stockées dans un espace de noms commun, indépendamment du domaine d'origine, un site peut détecter le chargement de ressources d'un autre site en vérifiant la présence de cette ressource dans le cache. La protection repose sur l'application de la segmentation réseau (Network Partitioning), dont l'essentiel consiste à ajouter à des caches partagés un lien supplémentaire entre les enregistrements et un domaine, à partir duquel la page principale a été ouverte, ce qui limite la portée du cache pour les scripts de suivi des mouvements au site actuel (un script dans un iframe ne pourra pas vérifier si une ressource a été chargée à partir d'un autre site).

  Le prix de la segmentation est une réduction de l'efficacité du caching, entraînant une légère augmentation du temps de chargement des pages (maximum de 1,32 %, mais pour 80 % des sites, de 0,09 à 0,75 %). Pour tester le mode de segmentation, il est possible de lancer le navigateur avec l'option « —enable-features=PartitionConnectionsByNetworkIsolationKey, PartitionExpectCTStateByNetworkIsolationKey, PartitionHttpServerPropertiesByNetworkIsolationKey, PartitionNelAndReportingByNetworkIsolationKey, PartitionSSLSessionsByNetworkIsolationKey, SplitHostCacheByNetworkIsolationKey ».

• Une API REST externe VersionHistory (https://versionhistory.googleapis.com/v1/chrome) a été ajoutée, à travers laquelle il est possible d'obtenir des informations sur les versions de Chrome en lien avec les plateformes et les branches, ainsi que sur l'historique des mises à jour du navigateur.
• Dans les iframes chargées à partir de domaines différents de celui de la page de base, l'affichage des dialogues JavaScript alert(), confirm() et prompt() est interdit, protégeant ainsi les utilisateurs contre les tentatives de scripts tiers d'afficher des messages sous prétexte qu'un avis a été fourni par le site principal.
• L'API WebAssembly SIMD a été stabilisée et est proposée par défaut pour utiliser des instructions SIMD vectorielles dans des applications au format WebAssembly. Pour garantir l'indépendance de la plateforme, un nouveau type de 128 bits est proposé, pouvant représenter différents types de données regroupées, ainsi que plusieurs opérations vectorielles de base pour le traitement des données regroupées. Le SIMD permet d'améliorer les performances grâce à la parallélisation du traitement des données et sera utile lors de la compilation de code natif en WebAssembly.
• En mode Origin Trials (fonctionnalités expérimentales nécessitant une activation distincte), plusieurs nouvelles API ont été ajoutées. L'Origin Trial permet aux applications chargées depuis localhost ou 127.0.0.1 d'accéder à l'API spécifiée, ou d'accéder à l'API après enregistrement et obtention d'un jeton spécial, valable pour une durée limitée pour un site spécifique.
  • WebTransport — un protocole et une API JavaScript associée pour l'envoi et la réception de données entre le navigateur et serveur. Un canal de communication est organisé au-dessus de HTTP/3 en utilisant le protocole QUIC comme transport, qui est, à son tour, une surcouche du protocole UDP, prenant en charge le multiplexage de plusieurs connexions et fournissant des méthodes de chiffrement équivalentes à TLS/SSL.

    WebTransport peut être utilisé comme alternative aux mécanismes WebSockets et RTCDataChannel, offrant des fonctionnalités supplémentaires telles que l'organisation de la transmission en plusieurs flux, des flux unidirectionnels, la livraison sans tenir compte de l'ordre d'envoi des paquets (out-of-order), ainsi que des modes de livraison fiables et non fiables. En outre, WebTransport peut être utilisé en remplacement du mécanisme Server Push, dont l'utilisation a été abandonnée par Google dans Chrome.

  • Interface déclarative pour définir des liens vers des applications web indépendantes (PWA), intégrée à l'aide du paramètre capture_links dans le manifeste de l'application web et permettant aux sites d'ouvrir automatiquement une nouvelle fenêtre PWA lors du clic sur un lien d'application ou de passer en mode à fenêtre unique, similaire aux applications mobiles.
  • Ajout de l'API WebXR Plane Detection, fournissant des informations sur les surfaces planes dans un environnement 3D virtuel. Cette API permet d'éviter le traitement complexe des données obtenues via l'appel à MediaDevices.getUserMedia(), en utilisant des implémentations propres d'algorithmes de vision par ordinateur. Rappelons que l'API WebXR permet d'unifier le fonctionnement avec différentes classes d'appareils de réalité virtuelle, des casques 3D de bureau aux solutions basées sur des appareils mobiles.
• Mise en œuvre du support des WebSockets au-dessus de HTTP/2 (RFC 8441), qui ne fonctionne que pour les requêtes sécurisées vers WebSockets et uniquement si une connexion HTTP/2 avec le serveur a déjà été établie, où le support de l'extension « WebSockets over HTTP/2 » est annoncé.
• Les limitations de précision des valeurs de temporisateur fournies par l'appel à performance.now() sont unifiées pour toutes les plateformes supportées et adaptées en tenant compte de l'éventuelle isolation des gestionnaires dans des processus distincts. Par exemple, sur les systèmes de bureau, la précision lors du traitement dans des contextes non isolés est réduite de 5 à 100 microsecondes.
• Les assemblages pour systèmes de bureau intègrent la fonctionnalité de lecture de fichiers depuis le presse-papiers (l'écriture de fichiers dans le presse-papiers reste néanmoins interdite). async function onPaste(e) { let file = e.clipboardData.files[0]; let contents = await file.text(); }
• En CSS, la règle @counter-style a été mise en place, permettant de définir un style personnalisé pour les compteurs et les étiquettes dans les listes numérotées.
• En CSS, les pseudo-classes « :host() » et « :host-context() » ont été ajoutées avec la possibilité de transmettre des valeurs uniques de sélecteurs composés (<compound-selector>) en plus des listes de sélecteurs (<compound-selector-list>).
• L'interface GravitySensor a été ajoutée pour déterminer les données volumétriques (sur trois axes de coordonnées) provenant du capteur de gravité.
• L'API File System Access permet désormais de définir des recommandations pour le choix du nom de fichier et du répertoire, proposées dans la boîte de dialogue de création ou d'ouverture de fichier.
• Des iframes chargés depuis d'autres domaines sont désormais autorisés à accéder à l'API WebOTP avec la permission de l'utilisateur. WebOTP permet de lire les codes de vérification à usage unique envoyés par SMS.
• Le partage des identifiants est autorisé pour les sites liés par le biais du mécanisme DAL (Digital Asset Links), permettant d'associer des applications Android à des sites pour faciliter la connexion.
• Les workers de service permettent désormais l'utilisation de modules JavaScript. En spécifiant le type 'module' lors de l'appel du constructeur, les scripts indiqués seront chargés sous forme de modules et disponibles pour importation dans le contexte du worker. La prise en charge des modules simplifie le partage de code sur les pages web et dans les workers de service.
• En JavaScript, il est désormais possible de vérifier l'existence de champs privés dans un objet en utilisant la syntaxe « #foo in obj ». class A { static test(obj) { console.log(#foo in obj); } #foo = 0; } A.test(new A()); // true A.test({}); // false
• En JavaScript, l'utilisation du mot-clé await est par défaut autorisée au niveau supérieur dans les modules, ce qui permet d'intégrer plus facilement les appels asynchrones dans le processus de chargement des modules et d'éviter d'enfermer dans une « fonction async ». Par exemple, au lieu de (async function() { await Promise.resolve(console.log('test')); }()); on peut maintenant écrire await Promise.resolve(console.log('test'));
• Dans le moteur JavaScript V8, l'efficacité du cache des templates a été améliorée, ce qui a permis d'augmenter la vitesse de passage du test Speedometer2-FlightJS de 4,5%.
• Une grande série d'améliorations a été apportée aux outils pour développeurs web. Un nouveau mode d'inspection de la mémoire (Memory inspector) a été ajouté, offrant des moyens d'explorer les données ArrayBuffer et la mémoire Wasm.

  Dans le panneau Performance, un indicateur de performance global a été ajouté, permettant d'évaluer si le site nécessite une optimisation ou non.

  

  Lors de l'aperçu des images dans le panneau Elements et dans le panneau d'analyse des requêtes réseau, des informations sur les proportions de l'image, les paramètres d'affichage et la taille du fichier sont fournies.

  

  Dans le panneau d'inspection réseau, il est désormais possible de modifier les valeurs d'en-tête Content-Encoding acceptées.

  

  Dans le panneau de styles, une fonction de prévisualisation rapide de la valeur calculée est désormais disponible lors de la navigation dans les paramètres CSS en sélectionnant 'View computed value' dans le menu contextuel.

  

En plus des nouvelles fonctionnalités et des corrections de bogues, la nouvelle version corrige 32 vulnérabilités. Beaucoup de vulnérabilités ont été identifiées grâce à des tests automatisés avec les outils AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer et AFL. Aucun 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 la version actuelle, Google a versé 21 récompenses totalisant 92 000 dollars (une récompense de 20 000 $, une récompense de 15 000 $, quatre récompenses de 7 500 $, trois récompenses de 5 000 $, trois récompenses de 3 000 $, deux récompenses de 1 000 $ et deux récompenses de 500 $). Le montant de 5 des récompenses n'a pas encore été déterminé.

Source : opennet.ru