L'API de détection d'inactivité dans Chrome 94 a déclenché une vague de critiques

Au lancement de Chrome version 94 se fait l'inclusion par défaut de l'API de détection d'inactivité, qui a suscité une vague de critiques avec des liens vers des objections de la part des développeurs de Firefox et WebKit/Safari.

L'API de détection d'inactivité permet aux sites de détecter quand un utilisateur est inactif, c'est-à-dire qu'il n'interagit pas avec le clavier/la souris ou fonctionne sur un autre moniteur. L'API vous permet également de savoir si l'économiseur d'écran est en cours d'exécution sur le système ou non. La notification d'inactivité se fait en envoyant une notification après avoir atteint un seuil d'inactivité prédéterminé, dont la valeur minimale est fixée à 1 minute.

Il est important de garder à l'esprit qu' l'utilisation de l'API de détection d'inactivité nécessite l'octroi explicite des informations d'identification de l'utilisateurC'est-à-dire que si l'application essaie de déterminer le fait d'inactivité pour la première fois, une fenêtre s'affichera à l'utilisateur avec une proposition d'accorder des autorisations ou de bloquer l'opération.

Applications de chat, les réseaux sociaux et les communications sont appelés applications, qui peut modifier le statut de l'utilisateur en fonction de sa présence sur l'ordinateur ou reporter l'affichage des notifications de nouveaux messages jusqu'à l'arrivée de l'utilisateur.

L'API peut également être utilisée dans d'autres applications pour revenir à l'écran d'origine après une période d'inactivité spécifique, ou pour désactiver les opérations interactives gourmandes en ressources, telles que le redessinage de graphiques complexes qui sont constamment mis à jour lorsque l'utilisateur n'est pas à l'écran. ordinateur.

La position de ceux qui s'opposent à l'activation de l'API détection inactive cela se résume au fait que les informations indiquant si l'utilisateur est sur l'ordinateur ou non peuvent être considérées comme confidentielles. En plus d'utilisations utiles, cette API peut également être utilisée à des fins non judicieuses, par exemple, pour tenter d'exploiter des vulnérabilités lorsque l'utilisateur est absent ou pour masquer une activité malveillante visible, telle que l'exploitation minière.

En utilisant l'API en question, des informations sur les modèles de comportement peuvent également être collectées de l'utilisateur et le rythme quotidien de son travail. Par exemple, vous pouvez savoir quand un utilisateur va habituellement déjeuner ou quitte son lieu de travail. Dans le cadre d'une demande de confirmation d'autorisation obligatoire, Google considère ces préoccupations comme non pertinentes.

Pour désactiver complètement l'API de détection d'inactivité, une option spéciale est fournie dans la section « Confidentialité et sécurité » des paramètres (« chrome : // settings / content / idleDetection »).

En outre, nous devons tenir compte d'une note des développeurs de Chrome sur l'avancement de nouvelles techniques pour assurer une gestion sûre de la mémoire. Selon Google, 70 % des problèmes de sécurité dans Chrome sont causés par des erreurs de mémoire, telles que l'utilisation après un accès gratuit à un tampon. Trois stratégies principales pour traiter de telles erreurs sont identifiées : resserrer les contrôles au moment de la compilation, bloquer les erreurs d'exécution et utiliser un langage sûr pour la mémoire.

Il est rapporté que les expériences ont commencé à 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 compilations fournies aux utilisateurs et son objectif principal est de tester la possibilité de développer des parties individuelles du navigateur en Rust et de les intégrer au reste des parties écrites en C++.

En parallèle, pour le code C++, le projet continue de se développer en utilisant le type MiraclePtr au lieu de pointeurs bruts pour bloquer la possibilité d'exploiter les vulnérabilités causées par l'accès à des blocs de mémoire déjà libérés, et de nouvelles méthodes sont proposées pour détecter les erreurs dans l'étape compilation.

En outre, Google lance une expérience pour tester une éventuelle panne du site après que le navigateur ait atteint une version à trois chiffres au lieu de deux.

En particulier, le paramètre "chrome : // flags # force-major-version-to-100" est apparu dans les versions d'essai de Chrome 96, lorsqu'il est spécifié dans l'en-tête User-Agent, la version 100 (Chrome / 100.0.4650.4. XNUMX) sera affiché. En août, une expérimentation similaire a été menée dans Firefox, qui a révélé des problèmes de gestion des versions à trois chiffres sur certains sites.


Un commentaire, laissez le vôtre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.

  1.   juro dit

    Salut. Merci beaucoup pour cet itinéraire chrome://settings/content/idleDetection, c'est la clé du noyau, là vous le désactivez ou le laissez activé, mais si ce n'est pas par cet itinéraire, pour le trouver vous les voyez et vous les voulez, c'est super caché.

    Salutations.

    chrome://settings/content/idleDetection