The default enabling of the Idle Detection API in Chrome 94 has led to a wave of criticism citing objections from Firefox and WebKit/Safari developers.
The Idle Detection API allows websites to determine when a user is inactive, i.e., not interacting with the keyboard/mouse or working on another monitor. The API also allows knowing whether a screensaver is running on the system. Notification of inactivity is done by sending an alert after a specified inactivity threshold is reached, with a minimum value set at 1 minute.
It is important to note that the usage of the Idle Detection API requires explicit user permission, meaning that if an application attempts to determine inactivity for the first time, the user will be shown a prompt to grant permission or block the operation. There is a specific option for completely disabling the Idle Detection API in the 'Privacy and Security' settings ('chrome://settings/content/idleDetection').
Potential use cases include chat applications, social networks, and communication tools that can change a user's status based on their presence at the computer or delay notifications of new messages until the user returns. The API can also be used in kiosk applications to return to the home screen after a certain period of inactivity or to disable resource-intensive interactive operations, such as redrawing complex constantly updated graphs, when the user is not at the computer.
Opponents of enabling the Idle Detection API argue that information about whether a user is at their computer can be considered confidential. Besides useful applications, this API may also be exploited for malicious purposes, such as attempting to take advantage of vulnerabilities during a user's absence or hiding conspicuous malicious activity, such as mining. The API can also gather information about user behavior patterns and their daily work rhythm. For instance, it could reveal when a user typically goes for lunch or leaves their workstation. Given the mandatory requirement for confirmation of granting permissions, these concerns are perceived by Google as negligible.
Additionally, it is worth noting a developer's message from Chrome regarding the promotion of new techniques for ensuring secure memory handling. According to Google, 70% of security issues in Chrome arise from memory handling errors, such as accessing a buffer after its associated memory has been freed (use-after-free). Three main strategies for combating such errors have been identified: strengthening checks at compile time, blocking errors during execution, and employing languages that ensure safe memory handling.
Reports indicate the beginning of experiments to add the capability of developing components in the Rust language to the Chromium codebase. Rust code is not yet included in user-distributed builds and is primarily aimed at testing the possibility of developing certain parts of the browser in Rust and integrating them with other components written in C++. Simultaneously, the C++ code continues to evolve with a project using the MiraclePtr type instead of raw pointers to mitigate vulnerabilities caused by accessing already freed memory blocks, while also proposing new methods for error detection at compile time.
Moreover, Google is starting an experiment to test potential website disruptions after browsers reach a version that uses three digits instead of two. Specifically, in the test releases of Chrome 96, there is a setting "chrome://flags#force-major-version-to-100" which, when set, results in the User-Agent header reporting version 100 (Chrome/100.0.4650.4). In August, a similar experiment was conducted in Firefox, which revealed issues with handling three-digit versions on some websites.
Source: opennet.ru
