Sortie de Chrome 120

La sociĂ©tĂ© Google a publiĂ© la version du navigateur web Chrome 120. En mĂȘme temps, une version stable du projet libre Chromium, qui sert de base Ă  Chrome, est disponible. Le navigateur Chrome se distingue de Chromium par l'utilisation des logos de Google, la prĂ©sence d'un systĂšme d'envoi de notifications en cas de crash, des modules pour la reproduction de contenus vidĂ©o protĂ©gĂ©s contre la copie (DRM), un systĂšme de mise Ă  jour automatique, la dĂ©sactivation permanente du mode Sandbox, la fourniture de clĂ©s pour l'API Google et la transmission de paramĂštres RLZ lors des recherches. Pour ceux qui ont besoin de plus de temps pour mettre Ă  jour, une branche Extended Stable est maintenue, accompagnĂ©e de 8 semaines. La prochaine version de Chrome 121 est prĂ©vue pour le 23 janvier.

Les principales modifications de Chrome 120 :

  • Un essai a commencĂ© pour dĂ©sactiver le support des cookies tiers, dĂ©finis lors de la consultation de sites autres que de domaine la page actuelle. Ces cookies sont utilisĂ©s pour suivre les mouvements des utilisateurs entre les sites dans le code des rĂ©seaux publicitaires, des widgets de rĂ©seaux sociaux et des systĂšmes d'analyse web. En janvier 2024, les cookies tiers seront dĂ©sactivĂ©s pour 1 % des utilisateurs du navigateur. Ces changements s'inscrivent dans le cadre de l'initiative Privacy Sandbox, visant Ă  trouver un compromis entre le besoin des utilisateurs de prĂ©server leur vie privĂ©e et le dĂ©sir des rĂ©seaux publicitaires et des sites de suivre les prĂ©fĂ©rences des visiteurs.

    Au lieu des cookies de suivi, il est proposé d'utiliser les API suivantes :

    • FedCM (Federated Credential Management), qui permet de crĂ©er des services d'identification unifiĂ©s, garantissant la confidentialitĂ© et fonctionnant sans cookies tiers.
    • Private State Tokens, qui permet de diffĂ©rencier diffĂ©rents utilisateurs sans utiliser d'identifiants intersites et de transmettre des informations d'authentification d'un contexte Ă  un autre.
    • Topics (critĂšres), qui permet de dĂ©terminer des catĂ©gories d'intĂ©rĂȘts des utilisateurs, pouvant ĂȘtre utilisĂ©es pour identifier des groupes d'utilisateurs ayant des intĂ©rĂȘts similaires sans identifier des utilisateurs individuels via des cookies de suivi. Les intĂ©rĂȘts sont calculĂ©s sur la base de l'activitĂ© de l'utilisateur dans le navigateur et sont stockĂ©s sur l'appareil de l'utilisateur. GrĂące Ă  l'API Topics, le rĂ©seau publicitaire peut obtenir des informations gĂ©nĂ©rales sur certains intĂ©rĂȘts sans avoir accĂšs Ă  des informations sur l'activitĂ© spĂ©cifique de l'utilisateur.
    • Public visĂ©e, solution pour le reciblage et l'Ă©valuation de son propre public (travail avec les utilisateurs qui ont dĂ©jĂ  visitĂ© le site auparavant).
    • Rapport d'attribution, permet d'Ă©valuer des indicateurs de performance publicitaire tels que les clics et les conversions (achat sur le site aprĂšs clic).
    • API d'accĂšs au stockage, peut ĂȘtre utilisĂ©e pour demander Ă  l'utilisateur l'autorisation d'accĂ©der au stockage des cookies, si par dĂ©faut les cookies tiers sont bloquĂ©s.
  • ConformĂ©ment aux exigences de la loi DMA (Digital Markets Act) adoptĂ©e en Union europĂ©enne, certains utilisateurs verront une boĂźte de dialogue pour choisir le moteur de recherche par dĂ©faut, dont les fonctionnalitĂ©s correspondent aux paramĂštres chrome://settings/search. Dans Chrome 120, la boĂźte de dialogue sera affichĂ©e Ă  1 % des utilisateurs, et lors de la publication de Chrome 122, elle sera Ă©tendue Ă  100 %.
  • Le processus de fin de support du codec vidĂ©o Theora a commencĂ©. À cette phase initiale, Theora est dĂ©sactivĂ© pour 1 % des utilisateurs, mais il est prĂ©vu qu'il soit dĂ©sactivĂ© pour tous les utilisateurs d'ici le 16 janvier. Dans la phase de transition, un paramĂštre pour restaurer le codec est disponible Ă  l'adresse « chrome://flags/#theora-video-codec ». Comme raison de cette fin de support, on mentionne des craintes que l'implĂ©mentation de Theora, qui possĂšde une logique de parsing binaire et de dĂ©codage des flux assez complexe, puisse contenir des vulnĂ©rabilitĂ©s similaires aux rĂ©centes failles critiques du codec VP8.
  • La prĂ©sentation du catalogue Chrome Web Store a Ă©tĂ© repensĂ©e pour simplifier la recherche et la gestion des extensions. De nouvelles catĂ©gories d'extensions ont Ă©tĂ© ajoutĂ©es (par exemple, une catĂ©gorie pour les extensions basĂ©es sur l'apprentissage machine et une section « sĂ©lection de l'Ă©diteur »). Un moyen de revenir Ă  l'ancienne conception a Ă©tĂ© ajoutĂ© dans le menu » ⋼ ».
    Sortie de Chrome 120
  • Les fonctionnalitĂ©s de l'interface « VĂ©rification de la sĂ©curitĂ© » (Safety check) ont Ă©tĂ© Ă©tendues, fournissant un rĂ©sumĂ© des problĂšmes potentiels de sĂ©curitĂ©, tels que l'utilisation de mots de passe compromis, l'Ă©tat de vĂ©rification des sites malveillants (Safe Browsing), la prĂ©sence de mises Ă  jour non installĂ©es et la dĂ©tection des extensions malveillantes. Dans la nouvelle version, un mode proactif a Ă©tĂ© proposĂ©, effectuant rĂ©guliĂšrement des vĂ©rifications de sĂ©curitĂ© liĂ©es au navigateur et informant l'utilisateur en cas de problĂšmes dĂ©tectĂ©s. Des options ont Ă©tĂ© ajoutĂ©es dans les paramĂštres pour contrĂŽler les actions en mode proactif.
    Sortie de Chrome 120
  • Un tableau de bord adaptatif a Ă©tĂ© mis en Ɠuvre, changeant en fonction de la taille de la fenĂȘtre.
  • Dans le gestionnaire de mots de passe, le partage d'accĂšs Ă  des mots de passe individuels pour les membres du groupe Google Family Group, configurĂ© via le compte Google, est dĂ©sormais autorisĂ©. Un seul mot de passe peut ĂȘtre partagĂ© Ă  la fois, aprĂšs quoi le mot de passe partagĂ© ne pourra plus ĂȘtre mis Ă  jour ou rĂ©voquĂ© par l'expĂ©diteur.
  • L'interaction avec les imprimantes a Ă©tĂ© transfĂ©rĂ©e dans un processus de service distinct, ce qui a permis d'amĂ©liorer la stabilitĂ© du navigateur et de rendre l'interface d'aperçu avant impression plus rĂ©active.
  • TLS intĂšgre une mise en Ɠuvre du mĂ©canisme d'encapsulation de clĂ©s (KEM, Key Encapsulation Mechanism), utilisant l'algorithme hybride X25519-Kyber768, rĂ©sistant aux attaques sur les ordinateurs quantiques. La combinaison du mĂ©canisme d'Ă©change de clĂ©s X25519, basĂ© sur des courbes elliptiques, actuellement utilisĂ© dans TLS, avec l'algorithme Kyber-768, qui utilise des mĂ©thodes cryptographiques basĂ©es sur la rĂ©solution de problĂšmes en thĂ©orie des rĂ©seaux, peut maintenant ĂȘtre utilisĂ©e pour crĂ©er des clĂ©s de session appliquĂ©es au chiffrement des donnĂ©es Ă  l'intĂ©rieur des connexions TLS, sans diffĂ©rence de temps de rĂ©solution entre ordinateurs classiques et quantiques.
  • Le service de suppression automatique des demandes de confirmation d'autorisation (Permission Suggestions Service) prend dĂ©sormais en compte l'URL de la page demandant des autorisations (sur serveurs Des hachages des URL demandant des autorisations seront transmis Ă  Google).
  • Le support de la plateforme Android 7.0 "Nougat" a Ă©tĂ© arrĂȘtĂ© dans la version Android.
  • Un framework avec la mise en Ɠuvre du concept de requĂȘtes de fermeture a Ă©tĂ© ajoutĂ©, permettant Ă  l'utilisateur de demander la fermeture de dialogues modaux et contextuels en appuyant sur la touche Échap ou en utilisant un geste Ă  l'Ă©cran ou le bouton "Retour" sur les smartphones. Le support des requĂȘtes de fermeture a Ă©tĂ© ajoutĂ© pour les dialogues créés Ă  l'aide de l'Ă©lĂ©ment ou de la propriĂ©tĂ© "popover". Une API CloseWatcher a Ă©galement Ă©tĂ© ajoutĂ©e, permettant aux dĂ©veloppeurs d'applications de suivre les requĂȘtes de fermeture et de rĂ©agir Ă  leur arrivĂ©e (par exemple, un gestionnaire peut ĂȘtre créé pour le bouton "retour" sur un smartphone Android).
  • Le support de l'attribut "name" a Ă©tĂ© ajoutĂ© Ă  l'Ă©lĂ©ment
    , permettant de créer des groupes en définissant une série d'éléments
    avec un nom commun.
  • L'API Media Session a ajoutĂ© l'Ă©vĂ©nement « enterpictureinpicture », permettant au site d'enregistrer un gestionnaire qui est appelĂ© lorsque le contenu est ouvert en mode « image dans l'image ».
  • La syntaxe des blocs CSS imbriquĂ©s a Ă©tĂ© simplifiĂ©e – les rĂšgles CSS imbriquĂ©es peuvent maintenant commencer par n'importe quel Ă©lĂ©ment, sans avoir besoin d'indiquer le symbole de l'esperluette avant la rĂšgle imbriquĂ©e ou d'utiliser la fonction is(). dl { dt { /* style pour dl dt */ } dd { /* style pour dl dd */ } }
  • La propriĂ©tĂ© CSS « background-clip » a ajoutĂ© le support du paramĂštre « text » pour afficher l'arriĂšre-plan sĂ©lectionnĂ© uniquement dans la zone limitĂ©e par les caractĂšres du texte. Par exemple, spĂ©cifier « background: linear-gradient(60deg, red, yellow, red, yellow, red); background-clip: text; color: rgba(0, 0, 0, 0.2) » affichera :
    Sortie de Chrome 120
  • Un media query « scripting » a Ă©tĂ© ajoutĂ© en CSS, qui peut ĂȘtre utilisĂ© pour dĂ©terminer la possibilitĂ© d'exĂ©cution de scripts, par exemple en JavaScript, sur la page actuelle.
  • Le pseudoclasse CSS « :dir() » a Ă©tĂ© ajoutĂ©, permettant de sĂ©lectionner des Ă©lĂ©ments en fonction de l'orientation du texte (par exemple, « :dir(ltr) » inclura les Ă©lĂ©ments dans lesquels le texte est affichĂ© de gauche Ă  droite).
  • Des fonctions exponentielles pow(), sqrt(), hypot(), log() et exp() ont Ă©tĂ© ajoutĂ©es en CSS.
  • Le CSS a ajoutĂ© le support des propriĂ©tĂ©s mask, mask-image, mask-repeat, mask-position, mask-clip, mask-origin, mask-size, mask-composite et mask-mode pour masquer un Ă©lĂ©ment en superposant une image sur des points spĂ©cifiques.
  • Dans l'API FontFaceSet, la mĂ©thode check() a Ă©tĂ© ajoutĂ©e, permettant de vĂ©rifier si le texte peut ĂȘtre affichĂ© avec les polices choisies sans utiliser les polices dont le chargement n'est pas encore terminĂ© dans FontFaceSet.
  • L'API WebGPU a ajoutĂ© la possibilitĂ© d'utiliser dans les shaders un type Ă  virgule flottante de 16 bits f16.
  • Dans l'API Media Capabilities, le champ decodingInfo() a Ă©tĂ© enrichi des champs hdrMetadataType, colorGamut et transferFunction pour dĂ©terminer le support HDR.
  • L'API MediaStreamTrack a ajoutĂ© la possibilitĂ© d'obtenir des informations sur les compteurs des images vidĂ©o reçues et perdues.
  • Il est dĂ©sormais possible de transmettre un objet ArrayBuffer dans les constructeurs VideoFrame, AudioData, EncodedVideoChunk, EncodedAudioChunk et ImageDecoder pour une utilisation directe du tableau d'octets sans crĂ©er de copie.
  • ConformĂ©ment Ă  la spĂ©cification modifiĂ©e pour renforcer la protection contre les attaques XSS et amĂ©liorer la portabilitĂ© entre les navigateurs, le support de l'URL « data: » dans SVGUseElement a Ă©tĂ© interrompu, car elle n'Ă©tait alors pas prise en charge par le moteur WebKit.
  • Une prise en charge expĂ©rimentale (origin trial) de l'en-tĂȘte HTTP « Priority » a Ă©tĂ© ajoutĂ©e, permettant de transmettre des informations sur la prioritĂ© de traitement de la demande (RFC 9218) lors de la premiĂšre demande de ressource.
  • Des amĂ©liorations ont Ă©tĂ© apportĂ©es aux outils pour les dĂ©veloppeurs web. Dans le dĂ©bogueur, l'ignorance des scripts situĂ©s dans les rĂ©pertoires « /node_modules/ » et « /bower_components/ » avec les modules Node.js est activĂ©e par dĂ©faut. En mode de dĂ©bogage Ă  distance, un commutateur a Ă©tĂ© mis en place pour choisir entre la souris et l'Ă©cran tactile. Le dĂ©bogage des animations a Ă©tĂ© amĂ©liorĂ©. Dans le panneau Elements, un commutateur « media » a Ă©tĂ© ajoutĂ© pour dĂ©boguer les Ă©lĂ©ments

En plus des nouveautés et des corrections de bogues, la nouvelle version a corrigé 10 vulnérabilités. De nombreuses vulnérabilités ont été détecté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 dans le systÚme en dehors de l'environnement sandbox n'a été révélé. Dans le cadre du programme de récompenses pour la découverte de vulnérabilités, Google a attribué 13 récompenses d'un total de 15 000 dollars américains pour cette version (une récompense de 10 000 dollars, une de 2 000 dollars et trois de 1 000 dollars).

Source : opennet.ru

Acheter un hĂ©bergement fiable pour les sites avec protection DDoS, serveurs VPS VDS đŸ”„ Acheter un hĂ©bergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster