At the launch of Chrome version 94 se made the default inclusion of the idle detection API, which has sparked 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, that is, it does not interact with the keyboard / mouse or works on another monitor. The API also lets you know if the screen saver is running on the system or not. Inactivity notification is done by sending a notification after reaching a predetermined inactivity threshold, the minimum value of which is set to 1 minute.
It's important to know that using the idle detection API requires explicit granting of user credentialsThat is, if the application tries to determine the fact of inactivity for the first time, the user will be shown a window with a proposal to grant permissions or block the operation.
Chat applications, social networks and communications are called applications, which can change the user's status based on their presence on the computer or postpone the display of notifications of new messages until the arrival of the user.
The API can also be used in other applications to return to the original screen after a specific period of inactivity, or to disable interactive, resource-intensive operations, such as redrawing complex charts that are constantly updated when the user is not on the screen. computer.
The position of those who oppose enabling the API inactive detection it boils down to the fact that information about whether the user is on the computer or not can be considered confidential. In addition to useful uses, this API can also be used not for good purposes, for example, to try to exploit vulnerabilities while the user is away or to hide visible malicious activity, such as mining.
Using the API in question, information about behavior patterns can also be collected of the user and the daily rhythm of their work. For example, you can find out when a user usually goes to lunch or leaves the workplace. In the context of a mandatory authorization confirmation request, Google perceives these concerns as irrelevant.
To completely disable the idle detection API, a special option is provided in the "Privacy and security" section of the settings ("chrome: // settings / content / idleDetection").
Moreover, we must take into account a note from the Chrome developers about the advancement of new techniques to ensure safe memory management. According to Google, 70% of security problems in Chrome are caused by memory errors, such as use after free access to a buffer. Three main strategies for dealing with such errors are identified: tightening compile-time checks, blocking runtime errors, and using a memory-safe language.
It is reported that experiments have started adding the ability to develop components in the Rust language to the Chromium codebase. The Rust code is not yet included in the compilations supplied to users and its main objective is to test 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 the C ++ code, the project continues to develop using the MiraclePtr type instead of raw pointers to block the possibility of exploiting vulnerabilities caused by accessing already freed blocks of memory, and new methods are proposed to detect errors in the stage compilation.
Moreover, Google is starting an experiment to test possible site outage after the browser reaches a three-digit version instead of two.
In particular, the setting "chrome: // flags # force-major-version-to-100" appeared in the Chrome 96 trial versions, when specified in the User-Agent header, version 100 (Chrome / 100.0.4650.4. XNUMX) will be displayed. In August, a similar experiment was carried out in Firefox, which revealed problems with handling of triple-digit versions on some sites.