Idle Detection API

[reillyeon]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Idle Detection API
• Specification or proposal URL: http://wicg.github.io/idle-detection
• Caniuse.com 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.

[annevk]

https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html has a number of good questions.

[tantek]

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: https://lists.w3.org/Archives/Public/public-new-work/2021Jul/0011.html)

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.

[1] https://pubmed.ncbi.nlm.nih.gov/31589063/
[2] https://www.apa.org/pubs/journals/releases/emo-emo0000422.pdf
[3] https://www.sciencedirect.com/science/article/abs/pii/S0195666310000723

(Originally published at: https://tantek.com/2021/209/t1/idle-detection-api-harmful)

[martinthomson]

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 https://en.wikipedia.org/wiki/Yao%27s_Millionaires%27_problem 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.

[rubyFeedback]

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.)

[zer]

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

[Spacefish]

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.