[feedback] [public commentary] How does this benefit USERS?

[ParaplegicRacehorse]

Lots of reasons why/how this could benefit developers -- especially developers who participate in the surveillance-economy -- but zero explanation about how this could benefit regular users.

As a user, I certainly do not want my hardware (keyboard, mouse), or any other out-of-context status reported to or detectable by a some bit of injected js.

If this is to be established as a standard, the question of how it benefits users and not just developers and site hosts, must be answered.

1. What risks of abuse does this create? (I can think of dozens. Can you?)
2. How are those risks mitigated in code?
3. What benefit is provide to a site or web-application's users?
4. What alternative means of providing [benefit] already exist?
5. How does this improve upon prior art?
6. In what ways is this inferior to prior art?

[reillyeon]

I am closing this issue because I believe the existing explainer and specification provide sufficient documentation of the user benefit of this API. For completeness I have answered the question below with links to external sources.

• What risks of abuse does this create? (I can think of dozens. Can you?)

There is an entire section of the specification dedicated to exploring the potential risks: https://wicg.github.io/idle-detection/#security-and-privacy

• How are those risks mitigated in code?

These mitigations are described in the specification,

1. The site must ask for the user's permission before it is allowed to listen for idle state change events.
2. This API is only available in secure contexts, which protects the user by ensuring that the site they are granting this capability to has not been tampered with by a network attacker.
3. The minimum threshold for detecting an idle state change is 60 seconds, which means that while a site can determine generally whether or not the user is actively using their device they can't detect what kind of activity the user is performing.
4. In Chromium we are currently investigating ways of adding additional uncertainty to the data reported by this API. This work is tracked by issue 939870.

• What benefit is provide to a site or web-application's users?

This topic is covered in the introduction section and was also explored in the Blink Intent to Ship thread. To summarize, duplicate notifications are a top user complaint for web-based messaging applications. This API allows these applications to deliver a better user experience.

• What alternative means of providing [benefit] already exist?

Solving the duplicate notifications problem isn't possible without this API. Messaging platforms with native apps use an equivalent version of this API and because it wasn't available on the web they provided a worse user experience in their web apps.

• How does this improve upon prior art?

Javascript libraries which only listen for input events in the current document in order to determine user activity already exist but are fundamentally limited by the lack of this API.

• In what ways is this inferior to prior art?

Since this API requires requesting the user's permission it has greater friction than other solutions.

[tomayac]

Additional more Web (instead of browser) developer-focused documentation of the use cases: https://web.dev/idle-detection/#use-cases.

[ParaplegicRacehorse]

Developer-focused?

So... still no response to how web-app users / site visitors benefit? I mean, if there's no benefit to user/visitor, there is no purpose to the API except to create yet-another datapoint for invasive browser fingerprinting.

[tomayac]

So... still no response to how web-app users / site visitors benefit? I mean, if there's no benefit to user/visitor, there is no purpose to the API except to create yet-another datapoint for invasive browser fingerprinting.

You are signed in to Example Chat on both your mobile phone and your desktop. Your phone sits idle right next to your actively used desktop computer. Someone sends you a chat message.

• Without the API: Your phone vibrates and plays a sound and your desktop computer shows a notification.
• With the API: Your phone stays idle and your desktop computer shows a notification.

[ParaplegicRacehorse]

Hmm. Okay.

I still cannot imagine such a minor annoyance outweighing the potential for abuse by the ad-tech industry, and others participating in the surveillance-economy; particularly the big players like Google, Amazon, Facebook, Microsoft, TenCent, etc.

I don't have -- and won't create -- an account at the WICG website to register my objection to this highly intrusive API which will allow additional point(s) of data for browser fingerprinting abuse; unless and until a solid plan for user (as apposed to developer) protection is put in place. Would you register a complaint/objection it on my behalf?

[tomayac]

I still cannot imagine such a minor annoyance outweighing the potential for abuse by the ad-tech industry, and others participating in the surveillance-economy; particularly the big players like Google, Amazon, Facebook, Microsoft, TenCent, etc.

It's maybe a minor annoyance for you, but a big thing for others. Also a friendly reminder that this API is behind a permission prompt.

I don't have -- and won't create -- an account at the WICG website to register my objection to this highly intrusive API which will allow additional point(s) of data for browser fingerprinting abuse; unless and until a solid plan for user (as apposed to developer) protection is put in place. Would you register a complaint/objection it on my behalf?

You coming here was the right thing to do, and I feel both @reillyeon and I have responded to your concerns in great detail. Thanks for your input.