The default inclusion of the Idle Detection API in Chrome 94 led to a wave of criticism with links to objections from the developers of Firefox and WebKit/Safari.
The Idle Detection API allows sites to detect when a user is inactive, i.e. does not interact with the keyboard/mouse or is working on a different monitor. The API also lets you know if a screensaver is running on the system or not. Informing about inactivity is carried out by sending a notification after reaching the specified threshold of inactivity, the minimum value of which is set to 1 minute.
It is important to note that the use of the Idle Detection API requires the explicit granting of user permissions, i.e. if the application attempts to detect inactivity for the first time, the user will be presented with a window prompting them to grant permissions or block the operation. To completely disable the Idle Detection API, a special option is provided in the "Privacy and Security" settings section ("chrome://settings/content/idleDetection").
Applications include chat, social networking, and communications applications that can change a user's status based on their presence at the computer, or delay notifications of new messages until the user arrives. The API can also be used in kiosk applications to return to the home screen after a period of inactivity, or to disable resource-intensive interactive operations such as redrawing complex continuously updated charts when the user is not at the computer.
The position of opponents of enabling the Idle Detection API is that information about whether the user is at the computer or not can be considered confidential. In addition to useful uses, this API can also be used for non-good purposes, such as trying to exploit vulnerabilities while the user is away, or to hide conspicuous malicious activity, such as mining. Using the API in question, information about user behavior patterns and the daily rhythm of his work can also be collected. For example, you can find out when the user usually goes to lunch or leaves the workplace. In the context of a mandatory authorization request, these concerns are considered by Google to be immaterial.
Additionally, we can note a note from Chrome developers about the promotion of new techniques for ensuring safe work with memory. According to Google, 70% of security issues in Chrome are caused by memory bugs, such as accessing a buffer after it has been freed (use-after-free). Three main strategies for dealing with such errors are identified: strengthening compile-time checks, blocking run-time errors, and using a memory-safe language.
It is reported that experiments have begun to add the ability to develop components in the Rust language to the Chromium codebase. The Rust code is not yet included in user-supplied assemblies and is mainly aimed at testing the possibility of developing individual parts of the browser in Rust and integrating them with the rest of the parts written in C ++. In parallel, for C++ code, the project continues to develop on the use of the MiraclePtr type instead of raw pointers to block the possibility of exploiting vulnerabilities caused by accessing already freed memory blocks, and new methods for detecting errors at the compilation stage are also proposed.
In addition, Google is starting an experiment to test the possible disruption of sites after the browser reaches a version consisting of three digits instead of two. In particular, in the test releases of Chrome 96, the setting "chrome://flags#force-major-version-to-100" appeared, when specified, version 100 (Chrome/100.0.4650.4) is displayed in the User-Agent header. In August, a similar experiment was carried out in Firefox, which revealed problems with the processing of three-digit versions on some sites.
Source: opennet.ru