Version de Chrome 84

La société Google présentée la sortie du navigateur web Chrome 84. 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 85 est prévue pour le 25 août.

Principales modifications dans Chrome 84:

• Le support le support des protocoles TLS 1.0 et TLS 1.1. Pour accéder aux sites via un canal sécurisé, le serveur doit prendre en charge au moins TLS 1.2 ; sinon, le navigateur affichera désormais une erreur. Selon Google, environ 0,5 % des chargements de pages web continuent d'utiliser des versions obsolètes de TLS. La désactivation a été faite conformément à les recommandations IETF (Internet Engineering Task Force). La raison du retrait de TLS 1.0/1.1 est l'absence de support pour les chiffrements modernes (comme ECDHE et AEAD) et la nécessité de supporter d'anciens chiffrements, dont la fiabilité est remise en question à l'étape actuelle du développement informatique (par exemple, il est nécessaire de supporter TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, et pour l'intégrité et l'authentification, MD5 et SHA-1 sont utilisés). La configuration permettant de réactiver TLS 1.0/1.1 sera maintenue jusqu'en janvier 2021.
• Le blocage est assuré téléchargement non sécurisé (sans chiffrement) des fichiers exécutables et ajouté des avertissements lors du téléchargement non sécurisé d'archives. À l'avenir, il est prévu de cesser progressivement le support du téléchargement de fichiers sans chiffrement. Le blocage a été mis en place car le téléchargement de fichiers sans chiffrement peut être utilisé pour mener des actions malveillantes en modifiant le contenu lors d'attaques MITM.
• Ajouté le support initial de l'identifiant Client Hints, développé comme alternative à l'en-tête User-Agent. Le mécanisme Client Hints propose en remplacement de User-Agent une série d'en-têtes « Sec-CH-UA-* », permettant d'organiser la livraison sélective des données sur des paramètres spécifiques du navigateur et du système (version, plateforme, etc.) uniquement après une demande du serveur. L'utilisateur a la possibilité de définir quels paramètres sont acceptables à divulguer et de fournir sélectivement ces informations aux propriétaires de sites. Lors de l'utilisation de Client Hints, l'identifiant n'est pas transmis par défaut sans demande explicite, rendant impossible la réalisation d'une identification passive (par défaut, seul le nom du navigateur est indiqué). Le fonctionnement pour de l'unification du User-Agent est reporté jusqu'à l'année prochaine.
• Poursuivie l'activation
  de restrictions plus strictes sur le partage de cookies entre sites, qui a été annulée annulée en raison de la COVID-19. Les requêtes non-HTTPS ne peuvent pas traiter les cookies tiers définis lors de l'accès à des sites autres que le domaine de la page actuelle. Ces cookies sont utilisés pour suivre les déplacements 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 de la transmission des cookies est contrôlée par l'attribut SameSite spécifié dans l'en-tête Set-Cookie, qui sera par défaut défini sur « SameSite=Lax », limitant l'envoi de cookies pour les sous-requêtes inter-sites, telles que les requêtes d'images ou le chargement de contenu via un iframe d'un autre site. Les sites peuvent remplacer le mode SameSite par défaut en définissant explicitement la valeur SameSite=None lors de l'établissement des cookies. De plus, la valeur SameSite=None pour les cookies ne peut être définie que dans le mode sécurisé (ce qui s'applique aux connexions via HTTPS). Ce changement sera appliqué progressivement, d'abord pour un petit pourcentage d'utilisateurs, puis en élargissant graduellement la portée.

• Ajout d'une implémentation expérimentale d'un bloqueur de publicités gourmandes en ressources, qui peut être activé via le paramètre « chrome://flags/#enable-heavy-ad-intervention ». Le bloqueur permet de désactiver automatiquement les blocs publicitaires iframe après avoir dépassé des seuils de trafic et de charge CPU. Le blocage sera déclenché si le temps CPU total dépassé dans le thread principal est supérieur à 60 secondes ou 15 secondes dans un intervalle de 30 secondes (utilise 50 % de ressources pendant plus de 30 secondes), ainsi que lorsque plus de 4 Mo de données sont chargés sur le réseau.

  Le blocage ne s'activera que si, avant de dépasser les limites, l'utilisateur n'a pas interagi avec le bloc publicitaire (par exemple, n'a pas cliqué dessus), ce qui, compte tenu de la restriction sur le trafic, permettra de bloquer la lecture automatique de vidéos volumineuses dans la publicité sans activation explicite par l'utilisateur. Les mesures proposées protégeront les utilisateurs de la publicité avec une mise en œuvre de code inefficace ou une activité parasitaire intentionnelle (par exemple, celle utilisant le minage). Selon les statistiques de Google, la publicité répondant aux critères de blocage représente seulement 0,30 % de tous les blocs publicitaires, mais ces insertions publicitaires consomment 28 % des ressources CPU et 27 % du trafic total de la publicité.

• Un travail a été effectué pour réduire la consommation de CPU lorsque la fenêtre du navigateur ne se trouve pas dans le champ de vision de l'utilisateur. Chrome vérifie maintenant si la fenêtre du navigateur est masquée par d'autres fenêtres et exclut le rendu des pixels dans les zones de recouvrement. L'activation de cette nouvelle fonctionnalité se fera progressivement : pour certains utilisateurs, l'optimisation sera incluse dans Chrome 84, tandis que pour d'autres, ce sera dans Chrome 85.
• Activée par défaut protection contre notifications intrusives, telles que le spam des demandes de notifications push. Étant donné que ces demandes interrompent le travail de l'utilisateur et détournent son attention vers les actions dans les dialogues de confirmation, un indicateur dans la barre d'adresse affichera un message d'information sans nécessiter d'action de la part de l'utilisateur, avertissant du blocage de la demande d'autorisation, qui se rétracte automatiquement en une icône représentant une cloche barrée. En cliquant sur l'indicateur, il sera possible d'activer ou de refuser l'autorisation demandée à tout moment.
  
• Il est maintenant possible de mémoriser le choix de l'utilisateur lors de l'ouverture des gestionnaires de protocoles externes — l'utilisateur peut choisir « toujours autoriser pour ce site » pour un gestionnaire spécifique et le navigateur mémorisera cette décision liée au site actuel.
• Une protection contre le changement des paramètres de l'utilisateur sans son consentement explicite a été ajoutée. Si une extension modifie le moteur de recherche par défaut proposé ou la page affichée pour un nouvel onglet, le navigateur affichera désormais une boîte de dialogue demandant à confirmer l'opération spécifiée ou à annuler le changement.
• Poursuite de la mise en place de la protection contre le téléchargement de contenu multimédia mixte (lorsque des ressources sont chargées via le protocole http:// sur une page HTTPS). Sur les pages ouvertes via HTTPS, les liens « http:// » seront maintenant remplacés automatiquement par « https:// » dans les blocs liés au téléchargement d'images (auparavant, les scripts et les iframes étaient remplacés, l'auto-remplacement des ressources audio et vidéo est prévu dans la prochaine version). Si une image n'est pas disponible via https, son téléchargement sera bloqué (il est possible de signaler le blocage manuellement via le menu accessible par le symbole de cadenas dans la barre d'adresse).
• Support ajouté pour l'API Web OTP (développé comme SMS Receiver API), permettant d'organiser l'entrée sur une page web d'un mot de passe à usage unique, après réception d'un message SMS contenant un code de confirmation, livré sur le smartphone Android de l'utilisateur, sur lequel le navigateur est lancé. La confirmation par SMS, par exemple, peut être utilisée pour vérifier le numéro de téléphone indiqué par l'utilisateur lors de l'inscription. Auparavant, l'utilisateur devait ouvrir l'application SMS, copier le code dans le presse-papiers, revenir au navigateur et coller ce code, alors que la nouvelle API permet d'automatiser ce processus et de le réduire à une seule touche.
• API étendue Animations Web
  pour contrôler la lecture de l'animation web. La nouvelle version ajoute un support pour les opérations de composition, permettant de contrôler comment les effets sont combinés et fournissant de nouveaux gestionnaires appelés lors d'événements de remplacement de contenu. L'API Animations Web prend également désormais en charge Promise pour définir la séquence de présentation de l'animation et un meilleur contrôle sur la façon dont l'animation interagit avec d'autres fonctionnalités de l'application.
• 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.
  • API Stockage des cookies pour accéder aux cookies HTTP depuis le Service Worker, agissant comme une alternative asynchrone à l'utilisation de document.cookie.
  • API Détection de l'inactivité pour détecter l'inactivité de l'utilisateur, permettant de déterminer le moment où l'utilisateur n'interagit pas avec le clavier/souris, où l'économiseur d'écran est activé, où l'écran est verrouillé ou où le travail est effectué sur un autre moniteur. L'application est informée de l'inactivité par l'envoi d'une notification après avoir atteint un seuil d'inactivité défini.
  • Mode Isolation d'origine, permettant au développeur d'utiliser une isolation complète du traitement des contenus dans un processus distinct lié à l'origine (origin — domaine+port+protocole), et non au site, au prix de la cessation de prise en charge de certaines fonctionnalités obsolètes, telles que l'exécution synchrone de scripts utilisant document.domain, et l'appel postMessage() pour envoyer des messages aux instances de WebAssembly.Module. En d'autres termes, l'Isolation d'origine permet d'organiser la séparation par différents processus basée sur le domaine de la ressource, et non sur le site avec toutes les inclusions externes sur les pages.
  • API WebAssembly SIMD pour l'utilisation des instructions SIMD vectorielles dans les applications au format WebAssembly. Pour garantir l'indépendance de la plateforme, un nouveau type de 128 bits est proposé, capable de représenter différents types de données empaquetées, ainsi que plusieurs opérations de base sur les vecteurs pour le traitement des données empaquetées. SIMD permet d'améliorer la performance grâce au parallélisme dans le traitement des données et sera utile lors de la compilation de code natif en WebAssembly. Pour activer le support de SIMD, vous pouvez utiliser le paramètre « chrome://flags/#enable-webassembly-simd ».
• Stabilisé et désormais distribué en dehors des Origin Trials
  API Content Indexing, fournissant des métadonnées sur le contenu qui avait été précédemment mis en cache par des applications web fonctionnant en mode Progressive Web Apps (PWA). L'application peut stocker sur le navigateur diverses données, y compris des images, des vidéos et des articles, et lorsqu'il n'y a plus de connexion réseau, elle peut les utiliser via les API Cache Storage et IndexedDB. L'API Content Indexing permet d'ajouter, de trouver et de supprimer ces types de ressources. Dans le navigateur, cette API est déjà utilisée pour l'énumération des pages et des données multimédias accessibles hors ligne.
• Une version stabilisée de l'API Verrouillage d'écran basé sur le mécanisme Promise, offrant une méthode plus sécurisée pour gérer la désactivation de la mise en veille automatique de l'écran et le passage des appareils en modes d'économie d'énergie.
• Dans la version pour la plateforme Android ajouté supporte les raccourcis d'applications, permettant d'offrir un accès rapide aux actions typiques requises dans l'application. Pour créer des raccourcis, il suffit d'ajouter des éléments dans le manifeste de l'application web au format PWA (Progressive Web Apps).
  
• Pour les Web Workers, l'utilisation de l'API ReportingObserver, qui permet de définir un gestionnaire pour générer un rapport lorsqu'on accède à des fonctionnalités obsolètes. Le rapport généré à la demande de l'utilisateur peut être sauvegardé, envoyé à un serveur ou traité par un script JavaScript.
• Mise à jour de l'API Resize Observer, permettant de connecter un gestionnaire qui recevra des notifications sur la modification de la taille des éléments spécifiés sur la page. Dans ResizeObserverEntry, trois nouvelles propriétés ont été ajoutées : contentBoxSize, borderBoxSize et devicePixelContentBoxSize pour obtenir des informations plus détaillées, délivrées sous forme de tableau d'objets ResizeObserverSize.
• Ajouté le mot-clé «revert» pour réinitialiser le style d'un élément à sa valeur par défaut.
• Élimination du préfixe CSS des propriétés « -webkit-appearance » et « -webkit-ruby-position », qui sont désormais accessibles comme «appearance» et «ruby-position«.
• En JavaScript réalisée prise en charge de la marquage des méthodes et des propriétés d'une classe comme privées, après quoi l'accès à celles-ci ne sera ouvert qu'à l'intérieur de la classe (auparavant, seules les champs pouvaient être privés). Pour marquer les méthodes et propriétés comme privées, il faut indiquer un signe « # » avant le nom du champ.
• En JavaScript ajouté la prise en charge références faibles (weak reference) aux objets JavaScript, permettant de conserver une référence à un objet sans empêcher la suppression de l'objet associé par le ramasse-miettes. La prise en charge des finalisateurs a également été ajoutée, permettant de définir un gestionnaire qui sera appelé après l'exécution du ramasse-miettes pour l'objet spécifié.
• Le lancement d'applications sur WebAssembly a été accéléré grâce à la mise en œuvre dans le compilateur initial (baseline) Liftoff instructions atomiques et opérations groupées sur la mémoire. Les outils de débogage pour WebAssembly ont été améliorés, augmentant considérablement les performances de débogage lors de l'utilisation de points d'arrêt (auparavant, un interpréteur était utilisé pour le débogage, et maintenant le compilateur Liftoff).
• Dans les outils pour les développeurs web pphttps://developers.google.com/web/updates/2020/05/devtools, le panneau d'analyse de performance a été mis à jour]] avec des informations générales sur la métrique TBT (Total Blocking Time), indiquant combien de temps une page semble accessible, mais n'est en réalité pas accessible (c'est-à-dire que la page est déjà rendue, mais que l'exécution du thread principal est encore bloquée, ce qui empêche toute saisie). Une nouvelle section Experience a été ajoutée pour analyser la métrique CLS (Cumulative Layout Shift), reflétant la stabilité visuelle du contenu. Dans le panneau d'inspection des styles CSS, un aperçu des images spécifiées via la propriété « background-image » a été réalisé.

En plus des nouveautés et des corrections de bogues, la nouvelle version corrige 38 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. Un problème (CVE-2020-6510, débordement de tampon dans le gestionnaire des opérations en arrière-plan fetch) est marqué comme critique, c'est-à-dire qu'il permet de contourner tous les niveaux de protection du navigateur et d'exécuter du code sur le système en dehors de l'environnement sandbox. Dans le cadre du programme de récompense pour la découverte de vulnérabilités pour cette version, Google a versé 26 primes d'une valeur totale de 21500 dollars américains (deux primes de 5000 $, deux primes de 3000 $, une prime de 2000 $, deux primes de 1000 $ et trois primes de 500 $). Le montant de 16 récompenses reste à déterminer.

Source : opennet.ru