L'inclusion par défaut de l'API de détection d'inactivité dans Chrome 94 a suscité une vague de critiques, citant les objections des développeurs de Firefox et WebKit/Safari.
L'API Idle Detection permet aux sites de détecter le moment où un utilisateur est inactif, c'est-à-dire N'interagit pas avec le clavier/la souris et n'effectue pas de travail sur un autre moniteur. L'API vous permet également de savoir si un économiseur d'écran est exécuté ou non sur le système. L'information sur l'inactivité s'effectue par l'envoi d'une notification après avoir atteint un seuil d'inactivité spécifié dont la valeur minimale est fixée à 1 minute.
Il est important de noter que l'utilisation de l'API Idle Detection nécessite l'octroi explicite d'autorisations utilisateur, c'est-à-dire Si l'application tente de détecter une inactivité pour la première fois, l'utilisateur se verra présenter une fenêtre lui demandant s'il doit accorder des autorisations ou bloquer l'opération. Pour désactiver complètement l'API de détection d'inactivité, une option spéciale (« chrome://settings/content/idleDetection ») est fournie dans la section des paramètres « Confidentialité et sécurité ».
Les domaines d'application comprennent les applications de chat, de réseaux sociaux et de communication qui peuvent modifier le statut de l'utilisateur en fonction de sa présence devant l'ordinateur ou retarder la notification des nouveaux messages jusqu'à l'arrivée de l'utilisateur. L'API peut également être utilisée dans les applications kiosque pour revenir à l'écran d'origine après une période d'inactivité ou pour désactiver des opérations interactives gourmandes en ressources, telles que le redessin de graphiques complexes et constamment mis à jour, lorsque l'utilisateur n'est pas devant l'ordinateur.
La position des opposants à l'activation de l'API de détection d'inactivité est que les informations indiquant si l'utilisateur est ou non devant l'ordinateur peuvent être considérées comme confidentielles. En plus des applications utiles, cette API peut également être utilisée à des fins malveillantes, par exemple pour tenter d'exploiter des vulnérabilités pendant l'absence de l'utilisateur ou pour masquer des activités malveillantes visibles, telles que l'exploitation minière. Grâce à l'API en question, des informations sur les modèles de comportement des utilisateurs et le rythme quotidien de leur travail peuvent également être collectées. Par exemple, vous pouvez savoir quand l'utilisateur va habituellement déjeuner ou quitte son lieu de travail. Dans le cadre d’une demande obligatoire de justificatif d’autorisation, ces préoccupations sont perçues par Google comme insignifiantes.
De plus, vous pouvez noter la note des développeurs de Chrome concernant la promotion de nouvelles techniques permettant de garantir un fonctionnement sûr avec la mémoire. Selon Google, 70 % des problèmes de sécurité dans Chrome sont causés par des erreurs de mémoire, comme l'utilisation d'un tampon après avoir libéré la mémoire qui lui est associée (use-after-free). Trois stratégies principales pour traiter de telles erreurs sont identifiées : renforcer les contrôles au stade de la compilation, bloquer les erreurs au moment de l'exécution et utiliser un langage sécurisé en mémoire.
Il est rapporté que des expériences ont commencé pour ajouter la possibilité de développer des composants dans le langage Rust à la base de code Chromium. Le code Rust n'est pas encore inclus dans les builds livrés aux utilisateurs et vise principalement à tester la possibilité de développer des parties individuelles du navigateur en Rust et leur intégration avec d'autres parties écrites en C++. En parallèle, pour le code C++, un projet continue de se développer pour utiliser le type MiraclePtr à la place des pointeurs bruts pour bloquer la possibilité d'exploiter les vulnérabilités causées par l'accès à des blocs mémoire déjà libérés, et de nouvelles méthodes de détection d'erreurs au stade de la compilation sont également proposées.
De plus, Google lance une expérience pour tester l'éventuelle perturbation des sites une fois que le navigateur atteint une version composée de trois chiffres au lieu de deux. En particulier, dans les versions de test de Chrome 96, le paramètre « chrome://flags#force-major-version-to-100 » est apparu, lorsqu'il est spécifié dans l'en-tête User-Agent, version 100 (Chrome/100.0.4650.4). commence à s’afficher. En août, une expérience similaire a été menée dans Firefox, qui a révélé des problèmes de traitement des versions à trois chiffres sur certains sites.
Source: opennet.ru