Mozilla affirme que la nouvelle fonctionnalité "Idle Detection" de Chrome permet la surveillance
Mozilla affirme que la nouvelle fonctionnalité "Idle Detection" de Chrome permet la surveillance
et Apple soutient qu'elle pose un problème de confidentialité évident
Google a publié ce lundi Chrome 94 pour les ordinateurs de bureau et Android. Comme c'est toujours le cas avec une nouvelle version du navigateur, il y a de quoi être enthousiaste. Cependant, il y a aussi des éléments qui suscitent le scepticisme, notamment l'API "Idle Detection" pour détecter l'inactivité de l'utilisateur. Cette fonctionnalité est conçue pour les applications multiutilisateurs telles que les réunions, les chats et les jeux en ligne. Mozilla et Apple ont critiqué la fonctionnalité, estimant qu'elle permet de surveiller les utilisateurs et pose un véritable problème concernant la protection de la vie privée.
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.
« En fournissant une API pour manipuler un profileur d'échantillonnage, les applications peuvent recueillir des données d'exécution riches pour l'agrégation et l'analyse avec une surcharge minimale », indiquent les documents sur le groupe communautaire du W3C. L'API JS Self Profiling bénéficie toutefois du soutien enthousiaste de Microsoft, d'Elastic et de Dropbox. En sus, Chrome 94 introduit l'API controversée "Idle Detection". 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. Google prévoit également d'améliorer la sécurité de la mémoire dans Chrome, peut-être en réécrivant certains composants en Rust. Selon un billet publié lundi par l'entreprise, "plus de 70 % des bogues de sécurité graves sont des problèmes de sécurité de la mémoire".
L'équipe explore simultanément la possibilité de rendre le C++ (qui est le langage avec lequel Chrome est écrit) plus sûr grâce à des contrôles à la compilation et à l'exécution, ainsi que l'utilisation de Rust qui est par nature un langage plus sûr pour la mémoire. Dans un autre billet, l'équipe de Chromium a déclaré que "le plus difficile est d'imaginer un moyen sûr de passer les types entre Rust et C++", ce qui explique pourquoi la proposition Rust reste une "enquête de fond".
Sources : Google (1, 2), Discussion sur l'API Idle Detection (1, 2), Reilly Grant de Google, Ryosuke Niwa d'Apple, Tantek Çelik de Mozilla
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi
Répondre avec citation
Partager