Idle Detection API #453
Comments
https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html has a number of good questions. |
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/ (Originally published at: https://tantek.com/2021/209/t1/idle-detection-api-harmful) |
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. |
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.) |
@rubyFeedback See PR #560 or Mozilla's position here. |
reillyeon commentedOct 28, 2020
Request for Mozilla Position on an Emerging Web Specification
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.
The text was updated successfully, but these errors were encountered: