L'activation par d\u00e9faut de l'API Idle Detection dans Chrome 94 a entra\u00een\u00e9 une vague de critiques, avec des r\u00e9f\u00e9rences aux objections des d\u00e9veloppeurs de Firefox et de WebKit\/Safari. <\/p>\n
L'API Idle Detection permet aux sites de d\u00e9terminer le temps pendant lequel l'utilisateur est inactif, c'est-\u00e0-dire qu'il n'interagit pas avec le clavier\/souris ou qu'il travaille sur un autre \u00e9cran. L'API permet \u00e9galement de savoir si un \u00e9conomiseur d'\u00e9cran est activ\u00e9 ou non. La notification d'inactivit\u00e9 se fait par l'envoi d'une alerte apr\u00e8s avoir atteint un seuil d'inactivit\u00e9, la valeur minimale \u00e9tant fix\u00e9e \u00e0 1 minute. <\/p>\n
Il est important de noter que l'utilisation de l'API Idle Detection n\u00e9cessite une autorisation explicite de l'utilisateur, c'est-\u00e0-dire que si l'application tente pour la premi\u00e8re fois de d\u00e9tecter l'inactivit\u00e9, une fen\u00eatre s'affichera pour demander \u00e0 l'utilisateur de donner les autorisations ou de bloquer l'op\u00e9ration. Pour d\u00e9sactiver compl\u00e8tement l'API Idle Detection, une option sp\u00e9ciale est pr\u00e9vue dans la section des param\u00e8tres \u00ab Confidentialit\u00e9 et s\u00e9curit\u00e9 \u00bb ( \u00ab chrome:\/\/settings\/content\/idleDetection \u00bb ). <\/p>\n
Parmi les domaines d'application, on cite les applications de chat, les r\u00e9seaux sociaux et les communications qui peuvent modifier le statut de l'utilisateur en fonction de sa pr\u00e9sence devant l'ordinateur ou diff\u00e9rer l'affichage des notifications de nouveaux messages jusqu'\u00e0 ce que l'utilisateur soit pr\u00e9sent. L'API peut \u00e9galement \u00eatre utilis\u00e9e dans les applications de kiosque pour revenir \u00e0 l'\u00e9cran d'accueil apr\u00e8s un certain temps d'inactivit\u00e9 ou pour d\u00e9sactiver des op\u00e9rations interactives gourmandes en ressources, telles que le redessin de graphiques complexes en continu, lorsque l'utilisateur n'est pas devant l'ordinateur. <\/p>\n
La position des opposants \u00e0 l'activation de l'API Idle Detection repose sur le fait que des informations sur la pr\u00e9sence ou l'absence d'un utilisateur devant son ordinateur peuvent \u00eatre consid\u00e9r\u00e9es comme sensibles. En plus de ses utilisations b\u00e9n\u00e9fiques, cette API pourrait \u00e9galement \u00eatre d\u00e9tourn\u00e9e \u00e0 des fins malveillantes, par exemple, pour exploiter des vuln\u00e9rabilit\u00e9s lorsque l'utilisateur est absent ou pour dissimuler des activit\u00e9s malveillantes \u00e9videntes, telles que le minage. Avec cette API, il est \u00e9galement possible de collecter des donn\u00e9es sur les habitudes de comportement des utilisateurs et leur rythme de travail quotidien. Par exemple, il peut \u00eatre d\u00e9termin\u00e9 quand un utilisateur a tendance \u00e0 partir en pause d\u00e9jeuner ou \u00e0 quitter son bureau. Dans le cadre de la demande obligatoire de confirmation des droits, ces pr\u00e9occupations sont consid\u00e9r\u00e9es par Google comme peu significatives. <\/p>\n
Il convient \u00e9galement de noter la remarque des d\u00e9veloppeurs de Chrome concernant la promotion de nouvelles techniques de s\u00e9curit\u00e9 m\u00e9moire. Selon Google, 70 % des probl\u00e8mes de s\u00e9curit\u00e9 rencontr\u00e9s dans Chrome sont dus \u00e0 des erreurs li\u00e9es \u00e0 la m\u00e9moire, comme l'acc\u00e8s \u00e0 un tampon apr\u00e8s que la m\u00e9moire associ\u00e9e a \u00e9t\u00e9 lib\u00e9r\u00e9e (use-after-free). Trois strat\u00e9gies principales sont d\u00e9finies pour lutter contre ces erreurs : le renforcement des v\u00e9rifications au moment de la compilation, le blocage des erreurs \u00e0 l'ex\u00e9cution et l'utilisation d'un langage qui garantit une gestion s\u00e9curis\u00e9e de la m\u00e9moire. <\/p>\n
Des exp\u00e9rimentations ont \u00e9t\u00e9 lanc\u00e9es pour ajouter la possibilit\u00e9 de d\u00e9velopper 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\u00e9es aux utilisateurs et vise principalement \u00e0 tester la possibilit\u00e9 de d\u00e9velopper certaines parties du navigateur en Rust et leur int\u00e9gration avec les autres parties \u00e9crites en C++. Parall\u00e8lement, un projet est en cours pour le code en C++ afin d'appliquer le type MiraclePtr au lieu des pointeurs bruts, afin d\u2019emp\u00eacher l'exploitation des vuln\u00e9rabilit\u00e9s caus\u00e9es par l'acc\u00e8s \u00e0 des blocs de m\u00e9moire d\u00e9j\u00e0 lib\u00e9r\u00e9s, tout en proposant de nouvelles m\u00e9thodes de d\u00e9tection d'erreurs au moment de la compilation. <\/p>\n