Google Chrome 97 introduit une API clavier controversée

Google Chrome 97 introduit une API clavier controversée,
les applications telles que les applications Web Office de Microsoft ne pouvaient pas utiliser l'API

La nouvelle version de Google Chrome est lancée avec une API Keyboard MAP controversée. L'API ne pouvait pas être utilisée auparavant pour certaines expériences web car elle ne pouvait pas être utilisée à l'intérieur des iframes. Des applications telles que les applications Web Office de Microsoft ne pouvaient pas utiliser l'API pour détecter les pressions de touche sur les dispositions du clavier. Les dispositions de clavier diffèrent selon la région ou la langue. La modification rend la fonctionnalité disponible pour les applications web qui se trouvent dans des iframes.

Voici, ci-dessous, l'explication officielle de la raison pour laquelle cette fonctionnalité a été implémentée : getLayoutMap() utilisé en conjonction avec du code résout le problème de l'identification de la touche réellement pressée sur un clavier avec différentes dispositions, comme les claviers anglais et français, mais comme getLayoutMap() n'est pas disponible dans tous les contextes (ne peut pas être utilisé à l'intérieur d'iframes), les applications Web Office comme Excel, Word, PowerPoint, qui apparaissent comme des expériences intégrées dans Outlook Web, Teams, etc. et qui sont exécutées dans des iframes, ne peuvent pas utiliser cette API.

Pièce jointe 611337

L'ajout de keyboard-map à la liste des attributs autorisés résout ce problème. Cependant, Mozilla, Apple, Brave et d'autres développeurs de navigateurs ont exprimé leurs préoccupations. L'un des principaux arguments avancés par ces sociétés contre l'intégration dans leurs navigateurs est que les sites pourraient utiliser cette fonctionnalité à des fins d'empreintes digitales.

Apple a publié une réponse sur GitHub, déclarant : « comme je l'ai fait remarquer en personne il y a quelque temps, l'API Keyboard Map telle qu'elle est proposée expose une surface d'empreintes digitales à forte entropie. Ceci n'est pas acceptable du point de vue de la vie privée. En conséquence, l'équipe WebKit d'Apple n'est pas intéressée par la mise en œuvre de cette fonctionnalité telle qu'elle est actuellement proposée. »

Brave Software, responsable du navigateur Brave, a déclaré ce qui suit : « Brave hérite de l'implémentation de l'API clavier Chrome qui ne fournit aucune fonctionnalité à l'utilisateur (seuls Chrome et Opera la prennent en charge et, à ma connaissance, aucun site ne l'utilise réellement.) Toutefois, l'API pourrait être utilisée pour la prise d'empreintes digitales. » Voici, ci-dessous, les autres fonctionnalités de Chrome 97 :

Normalisation tardive des nouvelles lignes dans la soumission du formulaire

Avant cette fonctionnalité, les nouvelles lignes dans les entrées de formulaire étaient normalisées au début du processus de soumission du formulaire (pendant la construction de la liste des entrées), avec une normalisation tardive supplémentaire qui se produisait lorsque la charge utile du formulaire était encodée avec l'enctype application/x-www-form-urlencoded.

Avec ce changement, la normalisation précoce est supprimée et la normalisation tardive est étendue à tous les enctypes. Cela résout un problème d'interopérabilité de longue date, où Gecko et WebKit normalisaient les nouvelles lignes tardivement, alors que la spécification ne les normalisait qu'au début, et que Chrome faisait une normalisation précoce ainsi qu'une normalisation tardive pour application/x-www-form-urlencoded.
Méthode HTMLScriptElement.supports(type) fournit un moyen unifié de détecter les nouvelles fonctionnalités qui utilisent des éléments de script.

Motivation

Il n'existe actuellement aucun moyen simple de savoir quels types peuvent être utilisés pour l'attribut type de HTMLScriptElement. Cependant, il existe plusieurs propositions de nouvelles fonctionnalités utilisant l'élément script. Il est possible d’utiliser l'attribut nomodule pour détecter le support du type de module. Mais il n'existe pas de méthode unifiée pour détecter ces nouvelles fonctionnalités.

WebTransport

WebTransport est un framework de protocole qui permet aux clients contraints par le modèle de sécurité du Web de communiquer avec un serveur distant en utilisant un transport multiplexé sécurisé. Actuellement, les développeurs d'applications Web disposent de deux API pour les communications bidirectionnelles avec un serveur distant : WebSockets et RTCDataChannel. Les WebSockets sont basées sur le protocole TCP et présentent donc tous les inconvénients de ce dernier, ce qui en fait une solution peu adaptée aux applications sensibles à la latence (blocage en tête de ligne, absence de prise en charge du transport de données non fiables).

RTCDataChannel est basé sur SCTP, qui ne présente pas ces inconvénients ; cependant, il est conçu pour être utilisé dans un contexte pair-à-pair, ce qui fait que son utilisation dans des configurations client-serveur est assez faible. WebTransport fournit une API client-serveur qui prend en charge le transfert bidirectionnel de données fiables et non fiables, en utilisant des datagrammes de type UDP et des flux annulables.

Source : Chrome

Et vous ?

:fleche: Quel est votre avis sur le sujet ?

:fleche: Quel est votre navigateur préféré ?

Voir aussi :

:fleche: Le service des impôts sud-africain déploie son propre navigateur web uniquement pour réactiver le support de Flash, n'étant plus en mesure de recevoir certaines déclarations fiscales via son portail

:fleche: Microsoft Edge 88 est livré avec de nouvelles fonctionnalités de sécurité, parmi lesquelles un générateur de mot de passe et un outil pour contrôler si vos informations de connexion ont fuité

:fleche: Google Chrome n'affichera plus les indicateurs de sites Web sécurisés, alors que l'entreprise continue ses efforts pour obtenir un Web 100 % HTTPS

:fleche: Après Chrome, Firefox va bloquer les téléchargements « non sécurisés » lancés depuis les pages en HTTPS à partir de Firefox 92, dont la sortie est prévue pour septembre 2021