La société Google a présenté la sortie du navigateur web Chrome 94. En parallèle, une version stable du projet open source Chromium, qui sert de base à Chrome, est également disponible. Le navigateur Chrome se distingue par l'utilisation des logos de Google, la présence d'un système d'envoi de notifications en cas de crash, de modules pour la lecture de contenu vidéo protégé (DRM), d'un système de mise à jour automatique et de la transmission de paramètres RLZ lors de la recherche. La prochaine version de Chrome 95 est prévue pour le 19 octobre.
À partir de la version Chrome 94, le développement est passé à un nouveau cycle de préparation des versions. De nouvelles versions significatives seront désormais publiées toutes les 4 semaines, et non toutes les 6 semaines, ce qui permettra d'accélérer la livraison de nouvelles fonctionnalités aux utilisateurs. Il est noté que l'optimisation du processus de préparation des versions et l'amélioration du système de test permettent de générer des versions plus fréquentes sans compromettre la qualité. Pour les entreprises et ceux qui ont besoin de plus de temps pour mettre à jour, une édition Extended Stable sera publiée séparément toutes les 8 semaines, permettant de passer à de nouvelles versions fonctionnelles non pas toutes les 4 semaines, mais toutes les 8 semaines.
Principales modifications de Chrome 94 :
- Un mode HTTPS-First a été ajouté, qui rappelle le mode HTTPS Only précédemment apparu dans Firefox. Si le mode est activé dans les paramètres, lors de la tentative d'ouverture d'une ressource sans chiffrement par HTTP, le navigateur essaiera d'abord d'accéder au site par HTTPS et, si cette tentative échoue, l'utilisateur recevra un avertissement indiquant l'absence de prise en charge de HTTPS et sera invité à ouvrir le site sans chiffrement. À l'avenir, Google envisage d'activer HTTPS-First par défaut pour tous les utilisateurs, de restreindre l'accès à certaines fonctionnalités de la plateforme web pour les pages ouvertes par HTTP, et d'ajouter des avertissements supplémentaires informant les utilisateurs des menaces associées à l'accès à des sites non sécurisés. Le mode peut être activé dans la section des paramètres « Confidentialité et sécurité » > « Sécurité » > « Avancé ».

- Pour les pages ouvertes sans HTTPS, l'envoi de requêtes (chargement de ressources) aux URLs locales (par exemple, « http://router.local » et localhost) et aux plages d'adresses internes (127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8, etc.) est interdit. Une exception n'est faite que pour les pages chargées depuis serveurs, ayant des IP internes. Par exemple, une page chargée depuis de serveurs 1.2.3.4 pourra accéder à une ressource hébergée sur l'IP 192.168.0.1 ou l'IP 127.0.0.1, tandis qu'une page chargée depuis le serveur 192.168.1.1 aura cette capacité. Ce changement introduit un niveau de protection supplémentaire contre l'exploitation des vulnérabilités des gestionnaires qui reçoivent des requêtes sur les IP locales, et permettra également de se protéger contre des attaques de type « DNS rebinding ».
- Une fonctionnalité « Sharing Hub » a été ajoutée, permettant de partager rapidement un lien vers la page actuelle avec d'autres utilisateurs. Il est possible de générer un code QR avec l'URL, de sauvegarder la page, d'envoyer le lien vers un autre appareil lié au compte utilisateur, et de transférer le lien vers des sites tiers tels que Facebook, WhatsApp, Twitter et VK. Cette fonction n'est pas encore accessible à tous les utilisateurs. Pour forcer l'activation du bouton « Share » dans le menu et la barre d'adresse, il est possible d'utiliser les réglages « chrome://flags/#sharing-hub-desktop-app-menu » et « chrome://flags/#sharing-hub-desktop-omnibox ».

- Une restructuration a été effectuée dans l'interface de configuration du navigateur. Chaque section des paramètres est désormais affichée sur une page distincte, plutôt que sur une page commune.

- La prise en charge de la mise à jour dynamique des journaux de certificats émis et révoqués (Certificate Transparency) a été réalisée, ceux-ci seront désormais mis à jour sans dépendre de la mise à jour du navigateur.
- Une page de service « chrome://whats-new » a été ajoutée, présentant un aperçu des changements visibles pour l'utilisateur dans la nouvelle version. Cette page s'affiche automatiquement immédiatement après la mise à jour ou est accessible via le bouton « Quoi de neuf » (What’s New) dans le menu Aide (Help). Actuellement, la page mentionne la recherche par onglets, la possibilité de séparer les profils et la fonction de changement de couleur de fond, qui ne sont pas spécifiques à Chrome 94 et ont été introduites dans des versions précédentes. L'affichage de la page n'est pas encore activé pour tous les utilisateurs : pour gérer son activation, il est possible d'utiliser les réglages « chrome://flags#chrome-whats-new-ui » et « chrome://flags#chrome-whats-new-in-main-menu-new-badge ».

- L'accès à l'API WebSQL est déclaré obsolète pour le contenu chargé à partir de sites tiers (par exemple via un iframe). Dans Chrome 94, une alerte sera affichée en cas d'accès à WebSQL depuis des scripts externes, mais à partir de Chrome 97, ces accès seront bloqués. Il est prévu à l'avenir de cesser progressivement tout support de WebSQL, quelle que soit son utilisation contextuelle. Le gestionnaire WebSQL est basé sur le code SQLite et pourrait avoir été utilisé par des attaquants pour exploiter des vulnérabilités dans SQLite.
- Pour des raisons de sécurité et pour prévenir les activités malveillantes, l'utilisation du protocole obsolète MK (URL : MK), autrefois utilisé dans Internet Explorer et permettant aux applications web d'extraire des informations à partir de fichiers compressés, a commencé à être bloquée.
- La synchronisation avec les anciennes versions de Chrome (Chrome 48 et antérieures) n'est plus prise en charge.
- Le champ de l'en-tête HTTP Permissions-Policy, destiné à activer certaines fonctionnalités et à contrôler l'accès à l'API, a été mis à jour pour inclure le drapeau « display-capture », permettant de gérer l'utilisation de l'API Screen Capture sur la page (par défaut, la possibilité de capturer le contenu de l'écran à partir d'iframes externes est bloquée).
- 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.
- L'API WebGPU a été ajoutée, remplaçant l'API WebGL et fournissant des moyens d'effectuer des opérations sur le GPU, telles que le rendu et les calculs. Conceptuellement, WebGPU est proche des API Vulkan, Metal et Direct3D 12. WebGPU diffère de WebGL à peu près de la même manière que l'API graphique Vulkan diffère d'OpenGL, mais il ne repose pas sur une API graphique spécifique et représente une couche universelle utilisant les mêmes primitives de bas niveau que celles d'Vulkan, Metal et Direct3D 12.
WebGPU fournit aux applications JavaScript des moyens de contrôle bas niveau sur l'organisation, le traitement et la transmission des commandes au GPU, tout en permettant de gérer les ressources associées, la mémoire, les tampons, les objets de texture et les shaders graphiques compilés. Cette approche permet d'obtenir de meilleures performances pour les applications graphiques grâce à la réduction des frais généraux et à l'optimisation de l'utilisation du GPU. L'API permet également la création de projets 3D complexes pour le Web, fonctionnant aussi bien que des programmes autonomes, mais sans être liés à des plateformes spécifiques.
- Pour les applications PWA autonomes, il est possible de s'enregistrer comme gestionnaires d'URL. Par exemple, l'application music.example.com peut s'enregistrer comme gestionnaire d'URL https://*.music.example.com, et tous les liens externes provenant d'autres applications, comme des messageries ou des clients de messagerie, ouvriront cette application PWA plutôt qu'un nouvel onglet dans le navigateur.
- La prise en charge d'un nouveau code de réponse HTTP — 103 — a été mise en œuvre, qui peut être utilisé pour l'envoi anticipé des en-têtes. Le code 103 permet d'informer le client sur le contenu de certains en-têtes HTTP immédiatement après la demande, sans attendre que le serveur exécute toutes les opérations liées à la demande et commence à renvoyer le contenu. De cette manière, il est possible de fournir des indications sur les éléments liés à la page à rendre, qui peuvent être préchargés (par exemple, des liens vers les fichiers CSS et JavaScript utilisés sur la page). Une fois informé de ces ressources, le navigateur commencera à les charger sans attendre la fin de l'envoi de la page principale, ce qui permet de réduire le temps total de traitement de la demande.
- L'API WebGPU a été ajoutée, remplaçant l'API WebGL et fournissant des moyens d'effectuer des opérations sur le GPU, telles que le rendu et les calculs. Conceptuellement, WebGPU est proche des API Vulkan, Metal et Direct3D 12. WebGPU diffère de WebGL à peu près de la même manière que l'API graphique Vulkan diffère d'OpenGL, mais il ne repose pas sur une API graphique spécifique et représente une couche universelle utilisant les mêmes primitives de bas niveau que celles d'Vulkan, Metal et Direct3D 12.
- L'API WebCodecs a été ajouté pour manipuler des flux multimédias à un niveau bas, complétant les API de haut niveau telles que HTMLMediaElement, Media Source Extensions, WebAudio, MediaRecorder et WebRTC. Le nouvel API pourrait s'avérer utile dans des domaines tels que le streaming de jeux, l'application d'effets côté client, le transcodage de flux et la prise en charge de conteneurs multimédias non standards. Au lieu de mettre en œuvre des codecs distincts en JavaScript ou WebAssembly, l'API WebCodecs permet d'accéder à des composants hautement performants intégrés dans le navigateur. En particulier, l'API WebCodecs fournit des décodeurs et des encodeurs audio et vidéo, des décodeurs d'images et des fonctions pour travailler avec des images individuelles vidéo à un niveau bas.
- L'API Insertable Streams a été stabilisée, permettant de manipuler des flux multimédias bruts (raw) transmis via l'API MediaStreamTrack, tels que les données de la caméra et du microphone, le résultat de la capture d'écran ou les données intermédiaires du décodage par un codec. Pour représenter les images brutes, il utilise les interfaces WebCodec, après quoi un flux est créé, similaire à celui que génère l'API WebRTC Insertable Streams sur la base de RTCPeerConnections. De manière pratique, le nouvel API permet de mettre en œuvre des fonctionnalités telles que l'application de méthodes d'apprentissage automatique pour identifier ou annoter des objets en temps réel, ou pour ajouter des effets tels que la suppression de fond, avant le codage ou après le décodage par le codec.
- La méthode scheduler.postTask() a été stabilisée, permettant de gérer la planification de l'exécution de tâches (appels de retour JavaScript) avec différents niveaux de priorité. Trois niveaux de priorité sont fournis : 1 - exécution en priorité, même si cela pourrait bloquer les opérations utilisateur ; 2 - modifications visibles pour l'utilisateur autorisées ; 3 - exécution en arrière-plan. Pour modifier la priorité et annuler des tâches, l'objet TaskController peut être utilisé.
- Stabilisé et maintenant déployé en dehors des Origin Trials, l'API Idle Detection permet de détecter l'inactivité d'un utilisateur. L'API permet de déterminer le moment où l'utilisateur n'interagit pas avec le clavier / la souris, où l'économiseur d'écran est actif, où l'écran est verrouillé ou lorsque le travail est effectué sur un autre moniteur. L'application est informée de l'inactivité en envoyant une notification après avoir atteint un seuil d'inactivité prédéfini.
- Le processus de gestion des couleurs dans les objets CanvasRenderingContext2D et ImageData ainsi que l'utilisation de l'espace colorimétrique sRGB a été formalisé. Il est désormais possible de créer des objets CanvasRenderingContext2D et ImageData dans des espaces colorimétriques différents de sRGB, comme Display P3, pour tirer parti des capacités avancées des moniteurs modernes.
- L'API VirtualKeyboard a ajouté des méthodes et des propriétés pour contrôler l'affichage et la dissimulation du clavier virtuel, ainsi que pour obtenir des informations sur la taille du clavier virtuel affiché.
- En JavaScript, pour les classes, il est désormais possible d'utiliser des blocs statiques d'initialisation pour regrouper le code exécuté une fois lors du traitement de la classe : class C { // Le bloc sera exécuté lors du traitement de la classe elle-même static { console.log('Bloc statique de C'); }}
- Dans les propriétés CSS flex-basis et flex, des mots-clés tels que content, min-content, max-content et fit-content ont été intégrés pour un contrôle plus flexible de la taille de la zone principale de Flexbox.
- La propriété CSS scrollbar-gutter a été ajoutée pour gérer la réservation d'espace à l'écran pour la barre de défilement. Par exemple, lorsque le défilement du contenu n'est pas nécessaire, il est possible d'élargir la sortie et d'occuper l'espace de la barre de défilement.
- Une API Self Profiling a été ajoutée avec l'implémentation d'un système de profilage permettant de mesurer le temps d'exécution de JavaScript côté client pour le débogage des problèmes de performance dans le code JavaScript, sans recourir à des manipulations manuelles dans l'interface pour les développeurs web.
- Après la suppression du plugin Flash, il a été décidé de renvoyer des valeurs vides dans les propriétés navigator.plugins et navigator.mimeTypes, mais il s'est avéré que certaines applications les utilisaient pour vérifier la présence de plugins pour l'affichage de fichiers PDF. Étant donné que Chrome dispose d'un visualiseur PDF intégré, désormais, les propriétés navigator.plugins et navigator.mimeTypes renverront une liste fixe de plugins standard et de types MIME pour l'affichage des PDF : « PDF Viewer, Chrome PDF Viewer, Chromium PDF Viewer, Microsoft Edge PDF Viewer et WebKit built-in PDF ».
- Des améliorations ont été apportées aux outils pour les développeurs web. Les appareils Nest Hub et Nest Hub Max ont été ajoutés à la liste de simulation des écrans. Une option a été ajoutée à l'interface d'inspection de l'activité réseau pour inverser les filtres (par exemple, en appliquant le filtre « status-code: 404 », vous pouvez rapidement voir toutes les autres requêtes), ainsi qu'une possibilité de visualiser les valeurs de l'en-tête Set-Cookie (pour évaluer la présence de valeurs incorrectes, supprimées lors de la normalisation). Le panneau latéral de la console web a été déclaré obsolète et sera supprimé dans l'une des prochaines versions. Une fonctionnalité expérimentale de masquage des problèmes a été ajoutée dans l'onglet Issues. Une option de sélection de la langue de l'interface a été ajoutée dans les paramètres.

En plus des nouveautés et de la correction de bogues, la nouvelle version corrige 19 vulnérabilités. Beaucoup de ces vulnérabilités ont été identifiées grâce à des tests automatisés utilisant 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 sur le système en dehors de l'environnement sandbox n'a été détecté. Dans le cadre du programme de récompense pour la découverte de vulnérabilités, la société Google a versé 17 primes d'un montant total de 56 500 USD pour cette version (une prime de 15 000 USD, deux primes de 10 000 USD, une prime de 7 500 USD, quatre primes de 3 000 USD, et deux primes de 1 000 USD). Le montant de 7 primes n'est pas encore défini.
Source : opennet.ru





