Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idle Detection API #453

reillyeon opened this issue Oct 28, 2020 · 6 comments · Fixed by #560

Idle Detection API #453

reillyeon opened this issue Oct 28, 2020 · 6 comments · Fixed by #560
w3c-cg Specifications in W3C Community Groups (e.g., WICG, Privacy CG)


Copy link

Request for Mozilla Position on an Emerging Web Specification

  • Specification Title: Idle Detection API
  • Specification or proposal URL:
  • URL (optional):
  • Bugzilla URL (optional):
  • Mozillians who can provide input (optional):

Other information

This feature will be entering an Origin Trial in Google Chrome soon. There is interest in this API expressed through the WICG from Slack and Google Chat.

Copy link

annevk commented Oct 29, 2020 has a number of good questions.

@annevk annevk added the w3c-cg Specifications in W3C Community Groups (e.g., WICG, Privacy CG) label Oct 29, 2020
Copy link

tantek commented Jul 28, 2021

I have user-surveillance and user-control concerns about the Idle Detection API. Even with the required 60 second mitigation, it can be used for monitoring a user’s usage patterns, and manipulating them accordingly. (Also noted in Mozilla’s formal objection to the proposed 2021 W3C DAS WG charter:

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.

Thus I propose labeling this API harmful, and encourage further incubation, perhaps reconsidering simpler, less-invasive alternative approaches to solve the motivating use-cases.


(Originally published at:

Copy link

martinthomson commented Jul 29, 2021

Thanks for doing this Tantek.

FWIW, the problem statement here, as I understand it, is delivery of a notification to the "correct" instance of a browser. Here, the proposal is to expose information to sites about user activity. This is approximately how long since they last used the device.

There is an alternative for this: let the devices sort it out between themselves and let you know the outcome. You could imagine implementing a protocol for if you could get the devices to talk to each other. Of course, doing that is surprisingly difficult (to clarify: not implementing the protocol, but getting the endpoint to talk to each other in real-time), probably disproportionate to the value we get from solving the problem. So once again, it is much, much easier to do the thing that is not good for privacy.

Copy link

Has there yet been a position to the idle-tracking by Mozilla yet? If so perhaps someone could add a link here that can be used as answer (indirect or direct) to reillyeon's initial thread; I may have missed the URL. (I am less interested in W3C because I consider them promote whatever Google wants anyway, so there is no news for me in this regard. It may be more interesting what Mozilla says in this regard, so the link to W3C is less helpful and interesting to me than e. g Mozilla's stance, but I haven't noticed a link to some statement. Perhaps it was already mentioned in some blog which I may have missed.)

Copy link

zer commented Sep 28, 2021

@rubyFeedback See PR #560 or Mozilla's position here.

Copy link

IMHO the major usecase in "chat applications" is letting other people / co-workers know whether you are availiable or not, without setting your status manually. I would extend this to VoIP / general realtime-collaboration platforms, as if you notice, your colleague is not availiable, you don´t try to call him / forward a call to her/him for example.

I guess classifying the "chat" usecase as a weak argument with alternatives availiable, stems from the assumption, that the primary usecase is to forward notifications to a mobile / another device if the user is not present on his working pc for example. And there are alternatives for this (like deliverying them to all devices). But it does not consider the usecase of informing your co-workers about your presence state, which might want to start to collaborate with you in a realitme-collaboration software right now.

I fully understand the privacy concerns regarding user tracking here, so i would propose the following solution:
Implement the API proposal, but when the dialog asking the user for permission is shown, offer three options instead of the standard "Allow" / "Deny".
The third option should be "Appear always active", if that option is selcted, the calling web application is notified that the permission is granted, but the "change" callback is only called once, with the screenState set to "unlocked" and the userState set to "active"

Thereby putting the user into control and giving him the option to "opt-out" of the feature, without letting the requesting application know. But still allowing legitimate use-cases of the feature for people who choose to grant permission for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
w3c-cg Specifications in W3C Community Groups (e.g., WICG, Privacy CG)
None yet

Successfully merging a pull request may close this issue.

7 participants