Wiki · Concept · Last reviewed June 25, 2026

Idle Detection API

The Idle Detection API lets selected web pages observe coarse user idle and screen-lock state, creating a browser boundary for agents, labor metrics, and presence surveillance.

Category: Concept Updated: June 25, 2026 Tags: browser security, presence, privacy, agents, labor

Definition

The Idle Detection API is a web-platform capability for observing a user's coarse presence state. MDN describes it as a way to detect whether a user is active or idle, and whether the screen is locked or unlocked, without polling from page script. The core interface is IdleDetector.

MDN marks the API as limited availability, experimental, and secure-context only, with support in dedicated web workers. Chrome's developer documentation frames it as a way for applications to react to inactivity, such as chat availability, kiosk reset behavior, reducing expensive computation, and updating a progressive web app when the user is not actively using it.

Mechanism

A page requests permission with IdleDetector.requestPermission(). MDN says this resolves to "granted" or "denied", and that transient user activation is required. After permission, the page creates an IdleDetector, listens for change events, and calls start() with a threshold and optional AbortSignal. The userState attribute reports active or idle; screenState reports locked or unlocked.

The WICG draft defines a policy-controlled feature named idle-detection, with a default allowlist of self. Same-origin frames can use the feature by default, cross-origin frames need explicit delegation, and a site can disable it through a Permissions Policy header. The draft also restricts the reported threshold to at least 60 seconds, reducing the risk that idle transitions reveal fine-grained behavior such as typing cadence.

Chrome's documentation adds two practical boundaries. First, the API uses a dedicated idle-detection permission and must run in a top-level secure context. Second, ordinary page-level idle libraries can only observe activity inside their own content area; this API can detect broader device or screen idleness, such as the user moving to another tab or locking the computer.

Agent Context

For AI Browsers and Computer Use, idle detection is a presence boundary. An assistant could defer a disruptive message until the user returns, pause a browser automation run when the screen locks, move a meeting summary to another device, or stop an expensive workflow when the person is away. These are legitimate coordination uses, especially when the signal is local, coarse, and visible.

The same signal can become a labor metric. A workplace agent, proctoring tool, support widget, or productivity dashboard could treat idle state as evidence of attention, effort, cheating, or availability. The WICG draft explicitly discusses behavior tracking and user coercion risks. A permission prompt is not enough if refusal blocks work, school, benefits, or access to a required service.

Governance Use

A governance review should treat idle state as behavioral telemetry. Record the origin, secure-context state, top-level or delegated frame status, Permissions Policy state, permission prompt, user activation path, threshold, reported userState and screenState, event timestamps, retention period, downstream recipients, model access, and whether the signal affected ranking, pay, discipline, proctoring, or automated decisions.

Organizations should separate convenience presence from surveillance presence. Chat status, kiosk reset, and local notification timing are not the same as productivity scoring. If an agent uses idle state to decide whether to act, postpone, escalate, or notify another person, the decision should be recorded as part of the agent's audit trail.

Limits

Idle detection is deliberately coarse. It does not prove attention, intent, productivity, absence, impairment, sleep, dishonesty, or consent. A person may be reading without input, using assistive technology, caring for another person, working on paper, watching a long-running process, or blocked by a broken tool. The WICG draft also notes accessibility concerns and says assistive-technology interactions should count toward activity.

Safer use keeps thresholds coarse, avoids secondary scoring, offers meaningful refusal where possible, keeps processing local, deletes event logs quickly, and explains who sees idle state. If idle telemetry is used in employment, education, benefits, security, or health contexts, it should be treated as consequential behavioral data, not as harmless status plumbing.

Review Record

Source Discipline

Claims about the model, permission, minimum threshold, Permissions Policy, behavior-tracking risk, coercion risk, and accessibility concerns should cite the WICG draft. Claims about secure contexts, dedicated-worker availability, IdleDetector, userState, screenState, start(), and requestPermission() should cite MDN. Claims about Chrome's implementation guidance and use cases should cite Chrome's developer documentation.

Spiralist Reading

Spiralism reads idle detection as the bureaucratization of absence. The browser does not hear words or see faces; it records a gap in interaction and turns that gap into a usable signal. The humane boundary is to keep the gap small, local, reversible, and nonpunitive. A pause should remain a human interval before it becomes evidence.

Sources

Return to Wiki