Critique de l'inclusion de l'API Idle Detection dans Chrome 94. Expérimentations avec Rust dans Chrome

L'activation par défaut de l'API Idle Detection dans Chrome 94 a entraîné une vague de critiques, avec des références aux objections des développeurs de Firefox et de WebKit/Safari.

L'API Idle Detection permet aux sites de déterminer le temps pendant lequel l'utilisateur est inactif, c'est-à-dire qu'il n'interagit pas avec le clavier/souris ou qu'il travaille sur un autre écran. L'API permet également de savoir si un économiseur d'écran est activé ou non. La notification d'inactivité se fait par l'envoi d'une alerte après avoir atteint un seuil d'inactivité, la valeur minimale étant fixée à 1 minute.

Il est important de noter que l'utilisation de l'API Idle Detection nécessite une autorisation explicite de l'utilisateur, c'est-à-dire que si l'application tente de déterminer l'inactivité pour la première fois, une fenêtre sera affichée pour demander l'autorisation ou bloquer l'opération. Pour désactiver complètement l'API Idle Detection, une option spéciale est prévue dans les paramètres « Confidentialité et sécurité » (« chrome://settings/content/idleDetection »).

Parmi les domaines d'application, on cite les applications de chat, les réseaux sociaux et les communications qui peuvent modifier le statut de l'utilisateur en fonction de sa présence devant l'ordinateur ou différer l'affichage des notifications de nouveaux messages jusqu'à ce que l'utilisateur soit présent. L'API peut également être utilisée dans les applications de kiosque pour revenir à l'écran d'accueil après un certain temps d'inactivité ou pour désactiver des opérations interactives gourmandes en ressources, telles que le redessin de graphiques complexes en continu, lorsque l'utilisateur n'est pas devant l'ordinateur.

La position des opposants à l'activation de l'API Idle Detection repose sur le fait que des informations sur la présence ou l'absence d'un utilisateur devant son ordinateur peuvent être considérées comme sensibles. En plus de ses utilisations bénéfiques, cette API pourrait également être détournée à des fins malveillantes, par exemple, pour exploiter des vulnérabilités lorsque l'utilisateur est absent ou pour dissimuler des activités malveillantes évidentes, telles que le minage. Avec cette API, il est également possible de collecter des données sur les habitudes de comportement des utilisateurs et leur rythme de travail quotidien. Par exemple, il peut être déterminé quand un utilisateur a tendance à partir en pause déjeuner ou à quitter son bureau. Dans le cadre de la demande obligatoire de confirmation des droits, ces préoccupations sont considérées par Google comme peu significatives.

Il convient également de noter la remarque des développeurs de Chrome concernant la promotion de nouvelles techniques de sécurité mémoire. Selon Google, 70 % des problèmes de sécurité rencontrés dans Chrome sont dus à des erreurs liées à la mémoire, comme l'accès à un tampon après que la mémoire associée a été libérée (use-after-free). Trois stratégies principales sont définies pour lutter contre ces erreurs : le renforcement des vérifications au moment de la compilation, le blocage des erreurs à l'exécution et l'utilisation d'un langage qui garantit une gestion sécurisée de la mémoire.

Des expérimentations ont été lancées pour ajouter la possibilité de développer des composants en langage Rust dans la base de code de Chromium. Pour l'instant, le code Rust n'est pas inclus dans les versions destinées aux utilisateurs et vise principalement à tester la possibilité de développer certaines parties du navigateur en Rust et leur intégration avec les autres parties écrites en C++. Parallèlement, un projet est en cours pour le code en C++ afin d'appliquer le type MiraclePtr au lieu des pointeurs bruts, afin d’empêcher l'exploitation des vulnérabilités causées par l'accès à des blocs de mémoire déjà libérés, tout en proposant de nouvelles méthodes de détection d'erreurs au moment de la compilation.

De plus, Google commence un test pour évaluer les possibles dysfonctionnements des sites web après que le navigateur atteindra une version à trois chiffres au lieu de deux. En particulier, dans les versions de test de Chrome 96, un paramètre « chrome://flags#force-major-version-to-100 » a été introduit, par lequel la version 100 (Chrome/100.0.4650.4) commence à être affichée dans l'en-tête User-Agent. En août, une expérimentation similaire a eu lieu dans Firefox, mettant en évidence des problèmes de traitement des versions à trois chiffres sur certains sites.

Source : opennet.ru