par Martin Brinkmann le 22 septembre 2021 dans Google Chrome – 8 commentaires
Google Chrome 94 est sorti et avec le navigateur vient une nouvelle fonctionnalité controversée : l'API Idle Detection. Comme son nom l'indique, il peut être mis en œuvre par des sites pour savoir si un utilisateur est inactif. Idle signifie que l'utilisateur n'a pas interagi avec l'appareil ou un matériel spécifique, tel que le clavier ou la souris, ou via certains événements système, tels que le lancement d'un économiseur d'écran ou un statut verrouillé.
Des exemples de cas d'utilisation incluent l'utilisation de l'API pour savoir si les contacts dans le chat ou sur les sites de réseaux sociaux sont accessibles à ce moment-là, le redémarrage automatique des applications de kiosque si aucune interaction de l'utilisateur n'est remarquée pendant une période ou des « applications qui nécessitent des calculs coûteux » qui limitent ces aux moments d'interaction avec l'utilisateur. La dernière itération de l'API nécessite une autorisation explicite de l'utilisateur avant que les sites puissent l'utiliser.
< p>Google a implémenté la fonctionnalité dans Chrome 94, que la société a publié cette semaine. Mozilla et Apple s'opposent à l'intégration de l'API de détection d'inactivité et ne l'implémenteront pas dans Firefox et Safari.
Mozilla a des “problèmes de surveillance et de contrôle des utilisateurs” à propos de l'API, car elle ” peut être utilisé pour surveiller les modèles d'utilisation d'un utilisateur et les manipuler en conséquence”.
Comme il est actuellement spécifié, je considère que l'API de détection d'inactivité est une opportunité trop tentante pour les sites Web motivés par le capitalisme de surveillance pour envahir un aspect de la vie privée physique de l'utilisateur, conserver des enregistrements à long terme des comportements physiques des utilisateurs, discerner les rythmes quotidiens (par exemple, l'heure du déjeuner) et utiliser que pour la manipulation psychologique proactive (par exemple la faim, l'émotion, le choix [1][2][3]). En outre, de tels modèles grossiers pourraient être utilisés par les sites Web pour maximiser subrepticement les ressources de calcul locales pour les calculs de preuve de travail, gaspillant de l'électricité (coût pour l'utilisateur, augmentation de l'empreinte carbone) sans le consentement de l'utilisateur ou peut-être même sa sensibilisation.
Mozilla a publié un rejet formel de la proposition. Dans ce document, l'organisation propose d'abandonner les demandes pour lesquelles un seul implémenteur a manifesté de l'intérêt, indiquant que la situation pourrait risquer d'évoluer vers une “spécification d'implémentation unique”.
Nous demandons que les spécifications qui ont montré l'intérêt d'un seul implémenteur soient abandonnées, sinon nous risquons une spécification d'implémentation unique, qui ne servira jamais que de documentation (c'est-à-dire pas un véritable standard ouvert), car nous savons que les standards basés sur la monoculture finissent par devenir de facto, sur la base des détails, des bogues, des interprétations d'une implémentation spécifique, et non de ce qui est écrit dans une spécification.
Apple a publié sa réponse officielle sur la liste de diffusion Webkit. L'équipe WebKit de l'entreprise ne voit pas de cas d'utilisation « assez solides » pour la mise en œuvre de l'API.
Je vais arrêter de répondre à ce fil à ce stade car aucun des cas d'utilisation présentés ici. ou ailleurs sont convaincants, et aucune des mesures d'atténuation de la confidentialité ou de la sécurité que vous avez présentées ici et que j'ai trouvées ailleurs n'est adéquate. Cependant, ne pas répondre à ce fil ou à un futur fil sur ce sujet ne signifie pas que nous reconsidérerions notre position. À moins qu'un nouveau développement important ne soit apporté à l'un ou l'autre des problèmes que nous avons soulevés, notre position restera de nous opposer à l'ajout de cette API, sauf indication contraire, que nous continuions à le dire en public ou non.
Les navigateurs basés sur Chrome prendront éventuellement en charge la nouvelle API, à moins qu'elle ne soit supprimée manuellement par l'équipe de développement ou désactivée.