A website usually knows whether you are interacting with its own page. The Idle Detection API can reveal something broader: whether you have recently interacted with the device at all, and whether the screen is locked. That makes useful presence features possible, but it also turns a quiet part of daily behaviour into data.
The signal is coarse. A site does not receive your keystrokes or a list of other applications. Still, active, idle, locked, and unlocked transitions can reveal routines. Idle Detection API privacy is less about a secret detail and more about the pattern created over time.
What Idle Detection API privacy covers
The MDN overview of the Idle Detection API describes two state signals. The user state is active or idle, based on whether the person has interacted with the device within a threshold. The screen state is locked or unlocked.
A supporting browser restricts the feature to secure contexts and requires the idle-detection permission. The site chooses a threshold, but the specification sets a minimum of 60 seconds. That prevents a page from using rapid idle transitions as a fine-grained proxy for typing.
The API reports states, not the cause behind them. An active transition does not say which key was pressed. An idle transition does not prove that someone left the room. A person might be reading, watching, using an assistive device, or working away from the keyboard.
Why websites want this signal
Presence-aware communication tools are the clearest use. A chat application can mark someone away after a period of device inactivity or direct a notification to a phone when the desktop is locked. A collaborative dashboard can avoid assigning an urgent task to a person who appears unavailable.
Other uses are less convincing. A content site rarely needs system-wide activity. An online shop does not need to know when your screen locks. If the feature is unrelated to the service you came for, denying it should not stop the core page from working.
The permission prompt is therefore an invitation to ask about purpose. What will the site change when you are idle? Will it store the events? Are they shared with an analytics provider? A trustworthy product should answer those questions in plain language.
The privacy risk is in timing
The Idle Detection API specification describes behaviour tracking as a central concern. Repeated transitions can help a site build a profile of when and for how long someone typically uses their device. The signal may suggest work hours, breaks, sleep patterns, or periods away.
Timing can also become a correlation channel. If several sites report nearly identical active and idle transitions to the same tracking server, that server may infer that the sessions belong to one person. The specification reduces this risk by requiring permission and limiting ordinary access to top-level and same-origin contexts.
These safeguards lower exposure; they do not make the signal harmless. Permission is most appropriate for a service whose benefit is obvious and whose treatment of presence data you accept.
Idle does not mean absent
Software should not turn an idle state into a confident conclusion about a person. Someone reading a long article may generate no keyboard or mouse input. A user with a physical or cognitive disability may interact on a different rhythm. A locked screen may indicate a brief privacy habit rather than the end of a work session.
Good products use idle detection as a hint. They avoid punitive decisions, invasive productivity scoring, or claims about attention. They also ensure that assistive-technology interaction counts appropriately toward an active state.
This distinction matters for users and developers alike. The API describes device interaction, not intention, concentration, availability, or character.
Before allowing idle detection
Match the permission to the feature
Presence in a messaging tool can be a reasonable use. Presence in an unrelated article, game, or storefront deserves scrutiny. If the explanation is vague, deny the request and see whether the service still works.
Ask how long the data lasts
Real-time state can be useful without becoming a permanent history. Look for a privacy policy or help page that explains retention and sharing. The difference between using a transition locally and storing months of presence events is substantial.
Review remembered access
A browser may remember your decision for the origin. Periodically review site permissions and remove idle detection from tools you no longer use. Our browser permissions guide offers a broader routine for keeping old grants from becoming invisible.
Do not confuse private mode with invisibility
The specification recommends that private-browsing contexts not allow the capability. Even where a browser handles the feature differently, private browsing does not hide your activity from sites you actively use. Read our private browsing explainer for the limits of that boundary.
How sites can use the API responsibly
Ask only when a user turns on a feature that genuinely needs presence. Explain the benefit before triggering the browser prompt. Keep the threshold comfortably above the minimum when fast detection is unnecessary, and avoid storing raw event histories.
Permissions Policy provides another boundary. The idle-detection feature defaults to the site's own origin, preventing third-party content from using it unless the top-level page explicitly delegates access. Our Permissions Policy guide explains why that control matters for embedded scripts and frames.
Responsible interfaces also let people turn presence features off inside the product. Browser permission controls are essential, but an in-app switch makes the choice easier to understand and revisit.
A more intentional view of presence
Idle Detection is not a camera pointed at your desk. It is a small set of system-wide state changes. Yet small signals become revealing when they are recorded, combined, and kept. The correct decision depends on whether a site's benefit justifies that pattern leaving your device.
Grant the permission when the purpose is specific. Deny it when the request feels incidental. Revoke it when the relationship ends. Privacy often comes down to these quiet boundaries: a clear reason, a narrow capability, and an honest end point.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.