Google a publié Chrome 94 pour ordinateur de bureau et Android, avec une API Idle Detection pour détecter l'inactivité des utilisateurs, malgré les problèmes de confidentialité exprimés par Mozilla et Apple.Les nouveautés et les modifications de Chrome 94 comprennent, entre autres, la suppression de la fonction AppCache, décrite comme une « responsabilité en matière de sécurité et de stabilité ». Il y a également une nouvelle API VirtualKeyboard avec plus de contrôle sur sa forme et un événement déclenché lorsqu'il couvre le contenu de la page ; un accès de bas niveau plus efficace aux encodeurs et décodeurs de médias ; et une nouvelle API JavaScript Self Profiling qui permet aux développeurs de recueillir des profils de performance JavaScript auprès des utilisateurs finaux. Mais cette dernière fonctionnalité suscite la controverse.
API JavaScript Self Profiling
Cette API ajoute un profileur d'échantillonnage Web pour mesurer le temps d'exécution JavaScript du client. La collecte de profils JS auprès d'utilisateurs réels peut aider les développeurs à déboguer les performances observées lentes sans avoir besoin d'une instrumentation manuelle invasive.
Pour indiquer ce qui l'a motivé à proposer cette API, Google explique qu'actuellement, il est difficile pour les développeurs Web de comprendre comment leurs applications fonctionnent dans la grande variété de conditions rencontrées sur les appareils des utilisateurs réels. Une API native d'auto-profilage pour le code JS permettrait également aux développeurs Web de trouver efficacement des points chauds dans leur code JS pendant les chargements de page et les interactions utilisateur, d'attribuer des budgets CPU à des fonctionnalités JS individuelles implémentées sur la page, de trouver des travaux inutiles effectués sur le client et de trouver le code JS de faible priorité s'exécutant en arrière-plan qui gaspille de l'énergie de l'appareil.
L'API d'auto-profilage JavaScript bénéficie du support enthousiaste de Microsoft, Elastic et Dropbox, publié sur GitHub.
WebGPU
L'API WebGPU est le successeur des API graphiques WebGL et WebGL 2 pour le Web. Elle fournit des fonctionnalités modernes telles que le «*calcul GPU*», ainsi qu'un accès moins élevé au matériel GPU et des performances meilleures et plus prévisibles. Il s'agit d'une amélioration par rapport aux interfaces WebGL existantes, qui ont été conçues pour dessiner des images mais qui ne pouvaient être adaptées à d'autres types de calculs qu'au prix d'un effort considérable. WebGPU expose les capacités graphiques modernes, notamment Direct3D 12, Metal et Vulkan, pour effectuer des opérations de rendu et de calcul sur un GPU. WebGPU est développé par le groupe communautaire « GPU for the Web » W3C.
Google indique que WebGPU est une API Web proposée pour permettre aux pages Web d'utiliser le GPU (Graphics Processing Unit) du système pour effectuer des calculs et dessiner des images complexes qui peuvent être présentées à l'intérieur de la page. Cet objectif est similaire à la famille d'API WebGL, mais WebGPU permet d'accéder à des fonctionnalités plus avancées des GPU. Alors que WebGL sert principalement à dessiner des images mais peut être réutilisé (avec beaucoup d'efforts) pour effectuer d'autres types de calculs, WebGPU offre une prise en charge de premier ordre pour effectuer des calculs généraux sur le GPU.
Cette fonctionnalité figure parmi les Origin Trial, un moyen de tester une fonctionnalité de plateforme Web nouvelle ou expérimentale, dans Chrome 94, avec l'espoir d'être livrée dans Chrome 99. Selon Google, les avantages de WebGPU par rapport aux technologies précédentes sont les suivants :
- séparation de la gestion des ressources, de la préparation du travail et de la soumission au GPU ;
- des états de pipeline qui fonctionnent de manière similaire aux API du système d'exploitation ;
- des groupes de liaison qui permettent aux pilotes graphiques d'effectuer les préparations nécessaires avant le rendu
Idle Detection
Cette fonctionnalité est conçue pour les applications multiutilisateurs telles que les réunions, les chats et les jeux en ligne. Elle notifie l'application Web lorsqu'un utilisateur est inactif, en utilisant des signaux tels que l'absence d'utilisation de la souris et du clavier, le verrouillage de l'écran ou le fait que l'utilisateur s'éloigne de l'écran.
Ces événements se produisent en dehors du navigateur, plutôt que d'être réservés à l'utilisation du navigateur lui-même. En gros, les sites Web peuvent demander à Chrome de signaler qu'un utilisateur dont une page Web est ouverte est inactif sur son appareil. Il ne s'agit pas seulement de votre utilisation de Chrome ou d'un site Web particulier : si vous vous êtes éloigné de votre ordinateur et n'utilisez aucune application, Chrome peut indiquer au site Web que vous n'utilisez pas activement votre ordinateur. Les fournisseurs d'applications de chat, notamment les développeurs de Slack et de Google Chat, ont exprimé leur soutien à l'API.
« Les applications qui facilitent la collaboration ont besoin de signaux plus globaux pour savoir si l'utilisateur est inactif que ceux fournis par les mécanismes existants qui ne prennent en compte que l'interaction de l'utilisateur avec le propre onglet de l'application », indiquent les notes de publication de Google. Pour les développeurs comme Slack, tout ce qui peut leur fournir davantage d'informations sur la façon dont les utilisateurs interagissent avec leurs applications est positif. La fonctionnalité est activée par défaut dans Chrome 94 et concernant les inquiétudes en matière de sécurité, Google a déclaré avoir pris quelques précautions.
À l'instar de l'utilisation de votre webcam ou de votre microphone, une invite vous demandera la permission avant d'utiliser vos données d'inactivité sur un site Web particulier. Cependant, l'API a son lot d'opposants, dont le fabricant de navigateurs Mozilla. Les gens derrière Firefox disent qu'elle crée une "opportunité pour le capitalisme de surveillance". Le responsable des normes Web de Mozilla, Tantek Çelik, a commenté sur GitHub, en disant : « Je considère que l'API Idle Detection est une opportunité trop tentante pour les sites Web motivés par le capitalisme de surveillance d'envahir un aspect de la vie privée physique de l'utilisateur… »
« ...De conserver des enregistrements à long terme des comportements physiques de l'utilisateur, de discerner les rythmes quotidiens (par exemple l'heure du déjeuner) et d'utiliser cela pour une manipulation psychologique proactive (par exemple la faim, l'émotion, le choix). En outre, ces schémas grossiers pourraient être utilisés par des sites Web pour maximiser subrepticement les ressources informatiques locales pour des calculs de preuve de travail, gaspillant l'électricité (coût pour l'utilisateur, augmentation de l'empreinte carbone) sans le consentement de l'utilisateur ou peut-être même sans qu'il en ait conscience ».
« Je propose donc de qualifier cette API de nuisible, et d'encourager une incubation plus poussée, peut-être en reconsidérant des approches alternatives plus simples et moins invasives pour résoudre les cas d'utilisation motivants ». Par ailleurs, Reilly Grant, ingénieur chez Google et l'un des auteurs de la proposition au sein de l'équipe Chromium, a demandé un retour d'information sur la liste de diffusion WebKit, le moteur de rendu Web utilisé par le navigateur Safari d'Apple. Ryosuke Niwa d'Apple a répondu à la demande de commentaires de Grant en déclarant : « Nos préoccupations ne se limitent pas aux empreintes digitales ».
« Le fait que cette API permette à un site Web d'observer si une personne se trouve ou non à proximité de l'appareil pose un problème évident de confidentialité. Cela pourrait être utilisé, par exemple, pour commencer à miner des bitcoins lorsque l'utilisateur n'est pas là, commencer à déployer des exploits de sécurité, etc. ». Grant répond qu'un travail est en cours pour définir la sémantique pour étrangler le travail que les sites sont autorisés à faire en arrière-plan, afin de lutter contre la menace du minage de cryptomonnaies, et que l'API profiterait à l'utilisateur en n'affichant pas de notifications sur les appareils inactifs.
« Les utilisateurs veulent recevoir des notifications uniquement sur l'appareil qu'ils utilisent actuellement », a déclaré Grant. Mais Ryosuke a répliqué en ces termes : « Cela ne semble pas être un cas d'utilisation assez fort pour cette API. Pour commencer, il n'y a aucune garantie que l'utilisateur ne reviendra pas immédiatement sur l'appareil. De plus, qui est censé savoir, dans le cadre d'un tel service, quel autre appareil l'utilisateur pourrait utiliser à un moment donné ? Nous n'allons absolument pas laisser un site Web connaître tous les appareils qu'un utilisateur donné peut utiliser à un moment donné ».
« C'est une violation très grave de la vie privée de cet utilisateur. Il me semble qu'il est préférable de laisser aux systèmes d'exploitation et aux navigateurs Web sous-jacents le soin de gérer un tel mécanisme de suppression et de distribution ». Il faut noter que Google a néanmoins maintenant mis en œuvre l'API, après deux essais d'origine dans les versions précédentes de Chrome. Son statut auprès du W3C, l'organisme qui définit les normes du Web, est celui d'un "livrable provisoire", ce qui signifie qu'il est loin d'être une recommandation approuvée. L'API Idle Detection est soumise à l'autorisation de l'utilisateur.
L'option se trouve dans les paramètres de Chrome 94. L'utilisateur peut préciser si les sites sont autorisés ou non à demander "à savoir quand vous utilisez activement le périphérique". Ce type de paramètres pose toutefois un problème : les sites peuvent tenter de contraindre l'utilisateur en bloquant certains contenus si l'autorisation n'est pas accordée.
Origin Trials qui ne sont plus en phase de tests et sont activés par défaut
Gestion des couleurs de Canvas
Cette mise à jour officialise le fait que l'espace couleur par défaut des objets CanvasRenderingContext2D et des objets ImageData est sRGB. Cela clarifie le fait que l'interface CanvasRenderingContext2D est entièrement gérée par les couleurs (que toutes les entrées sont converties dans l'espace couleur du canevas). Il s'agissait auparavant de conventions qui n'étaient pas clairement spécifiées. Cette mise à jour apporte les modifications suivantes :
- ajout de paramètres permettant de spécifier un espace couleur non RVB lors de la création d'un objet CanvasRenderingContext2D ou d'un objet ImageData.
- ajout de la prise en charge de l'espace couleur Display P3 pour ces paramètres.
Le contenu affiché par CanvasRenderingContext2D est actuellement limité à l'espace couleur sRGB, ce qui est inférieur aux capacités des écrans et des caméras modernes. Cette fonctionnalité permet de créer un objet CanvasRenderingContext2D qui est dans l'espace couleur Display P3. Cela permet également de lever plusieurs points d'ambiguïté sur le comportement des couleurs de CanvasRenderingContext2D.
L'API VirtualKeyboard
L'interface VirtualKeyboard possède des méthodes et des propriétés permettant de contrôler l'affichage ou le masquage d'un clavier virtuel. Elle déclenche également des événements avec la taille du clavier virtuel lorsqu'il occulte le contenu de la page. Le clavier virtuel est le clavier à l'écran utilisé pour la saisie dans des scénarios où un clavier matériel peut ne pas être disponible.
Contrairement à un clavier matériel, un clavier virtuel peut adapter sa forme pour l'optimiser en fonction de la saisie attendue. Les développeurs ont le contrôle de la forme affichée du clavier virtuel grâce à l'attribut inputmode, mais ont un contrôle limité sur le moment où le clavier virtuel est affiché ou masqué.
Source : note de version
Voir aussi
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 Chrome 94 va ajouter le mode HTTPS-First et Google prévoit de remplacer l'icône de cadenas affichée lorsqu'un site se charge via HTTPS. L'éditeur estime qu'il prête à confusion Google Chrome 92 est livré avec une détection de phishing « jusqu'à 50 fois plus rapide » grâce à des améliorations apportées à sa technologie de traitement d'image 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 
