Chrome 94's Idle Detection API can be abused according to Mozilla and Apple

Google Chrome 94 is out and with the browser comes a new controversial feature: the Idle Detection API. As the name suggests, it can be implemented by sites to find out if a user is idle. Idle meaning that the user has not interacted with the device or specific hardware, such as the keyboard or the mouse, or through certain system events, such as the launching of a screensaver or locked status.

Example use cases include using the API to know if contacts in chat or on social networking sites are reachable at the time, automatic restarting of kiosk applications if no user interaction is noticed for a period, or "apps that require expensive calculations" that limit these to moments with user interaction. The latest iteration of the API requires explicit permission from the user before sites can utilize it.

Google implemented the functionality in Chrome 94, which the company released this week. Mozilla and Apple object to the integration of the Idle Detection API, and won't implement it in Firefox and Safari.

Mozilla has "user-surveillance and user-control concerns" about the API, as it "can be used for monitoring a user's usage patterns, and manipulating them accordingly".

As it is currently specified, 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.

Mozilla published a formal rejection to the proposal. In it, the organization proposes to drop requests that only one implementer has shown interest in, stating that the situation could risk evolving into a "single-implementation spec".

We request that specs be dropped that have shown interest from only one implementer, otherwise we are at risk of a single-implementation spec, which will only ever serve as documentation (i.e. not an actual open standard), as we know that monoculture based standards end-up becoming de facto, based on the one specific implementation’s details, bugs, interpretations, and not what is written in a specification.

Apple published its official response on the Webkit mailing list. The company's WebKit team does not see "strong enough" use cases for implementing the API.

I'm going to stop responding to this thread at this point because 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. However, not responding to this thread or future thread about this topic does not mean we'd reconsider our position. Unless a significant new development is being made in either one of the issues we've raised, our position will remain to object to the addition of this API unless otherwise stated regardless of whether we continue to say so in public or not.

Chromium-based browsers will support the new API eventually, unless it is removed manually by the development team or disabled.

Advertisement