Google emits Chrome 94 with 'Idle Detection' API to detect user inactivity, despite opposition

Mozilla, Apple register dismay as worries surface over privacy, potential crypto mining behind user's back

Google has released Chrome 94 for desktop and Android, complete with an "Idle Detection" API to detect user inactivity, despite privacy concerns expressed by Mozilla and Apple.

New and changed features in Chrome 94 are listed here and include the removal of the AppCache feature, described as a "security and stability liability", and something which has "imposed a tax on all of Chrome's significant architectural efforts."

There is also a new VirtualKeyboard API with more control over its shape and an event fired when it covers page content; more efficient low-level access to media encoders and decoders; and a new JavaScript Self Profiling API which enables developers to collect JavaScript performance profiles from end users.

"By providing an API to manipulate a sampling profiler, applications can gather rich execution data for aggregation and analysis with minimal overhead," say the docs on the W3C Community Group.

The JS self-profiling API has enthusiastic support from Microsoft, Elastic and Dropbox, recorded on GitHub.

The IdleDetection feature is more contentious. The feature is designed for multi-user applications such as meetings, chat, and online games. It notifies the web application when a user is idle, using signals such as lack of use of mouse and keyboard, the screen locking, or the user switching away from the screen where the application is running.

These events occur outside the browser, rather than being reserved for usage of the browser itself.

"Applications which facilitate collaboration require more global signals about whether the user is idle than are provided by existing mechanisms that only consider a user's interaction with the application's own tab," say the release notes.

Support for the API was expressed by developers from Slack and Google Chat, among others.

Mozilla web standards lead Tantek Çelik said on GitHub: "I consider the Idle Detection API too tempting of an opportunity for surveillance capitalism motivated websites to invade an aspect of the user’s physical privacy, keep longterm records of physical user behaviors, discerning daily rhythms (e.g. lunchtime), and using that for proactive psychological manipulation (e.g. hunger, emotion, choice [1][2][3]). In addition, such coarse patterns could be used by websites to surreptiously max-out local compute resources for proof-of-work computations, wasting electricity (cost to user, increasing carbon footprint) without the user’s consent or perhaps even awareness."

Google's Reilly Grant, one of the proposal's owners on the Chromium team, asked for feedback on the WebKit mailing list, WebKit being the browser engine used by Apple for Safari.

Apple's Ryosuke Niwa responded that: "Our concerns are not limited to fingerprinting. There is an obvious privacy concern that this API lets a website observe whether a person is near the device or not. This could be used, for example, to start mining bitcoins when the user is not around or start deploying security exploits, etc."

Grant responded that there is work being done to "define the semantics for throttling the work that sites are allowed to do in the background," to combat the crypto mining menace, and that the API would benefit the user by not showing notifications on inactive devices. "[U]sers want to receive notifications on only the device they are currently using," Grant said.

But Niwa replied that "none of the use cases presented either here or elsewhere are compelling, and none of the privacy or security mitigations you've presented here and I found elsewhere are adequate."

'Tentative deliverable'

Google has nevertheless now implemented the API, after two origin trials in previous versions of Chrome. Its status with the W3C, the body which defines web standards, is as a "tentative deliverable," which means it is some way off being an agreed recommendation.

The Idle Detection API is subject to user permission, which can be found in Chrome 94 settings. The user can specify whether or not sites are allowed to ask "to know when you're actively using device". A concern with such settings though is that sites may try to coerce the user by blocking certain content unless the permission is granted.

Google is also planning to improve memory security in Chrome, possibly by rewriting some components in Rust. According to a post yesterday, "more than 70 per cent of our severe security bugs are memory safety problems."

The team is simultaneously exploring making C++ (the language with which Chrome is written) safer with compile-time and runtime checks, and also use of Rust which is inherently a more memory-safe language.

In a separate post, the Chromium team said that "the hardest part of this is imagining a safe way to pass types between Rust and C++," which is why the Rust proposal remains a "background investigation." ®

Source