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

Closed
reillyeon opened this issue Oct 28, 2020 · 5 comments
Closed

Idle Detection API #453

reillyeon opened this issue Oct 28, 2020 · 5 comments
Labels

Comments

@reillyeon
Copy link

@reillyeon reillyeon commented Oct 28, 2020

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
Copy link
Collaborator

@annevk annevk commented Oct 29, 2020

@annevk annevk added the w3c-cg label Oct 29, 2020
@tantek
Copy link
Member

@tantek 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: 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
Copy link
Member

@martinthomson 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 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
Copy link

@rubyFeedback rubyFeedback commented Sep 27, 2021

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
Copy link

@zer zer commented Sep 28, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

6 participants