Question: Support for IdleDetector interface exposure to ServiceWorker?

[whitehatguy]

Hello!

I note that the current interface declares that IdleDetector is only exposed to Window and DedicatedWorker. Is there any consideration for exposing the IdleDetector interface to ServiceWorker? Possible use cases where this would provide value:

• An application that signals the user via Notifications via a service worker can detect user idle state, and thus redirect notifications to other devices.
• An application that relies on active user presence (per NIST 800-63B reauthentication requirements) could utilize this to poll for user presence and signal a corresponding server-side component as to keep a user session alive, even where the user navigates away to other applications.

Thank you.

[Sora2455]

I don't work for a browser vendor, but:

An application that signals the user via Notifications via a service worker can detect user idle state, and thus redirect notifications to other devices.

Push Notifications that don't show visible notifications to the user are currently disallowed in all browsers, and I don't see that changing.

An application that relies on active user presence (per NIST 800-63B reauthentication requirements) could utilize this to poll for user presence and signal a corresponding server-side component as to keep a user session alive, even where the user navigates away to other applications.

Polling for user presence when user has no tabs open sounds very much like intrusive tracking.

[reillyeon]

An application that signals the user via Notifications via a service worker can detect user idle state, and thus redirect notifications to other devices.

Push Notifications that don't show visible notifications to the user are currently disallowed in all browsers, and I don't see that changing.

This is a key tension that needs to be resolved. We want developers to be able to direct notifications based on user presence but don't want this to be a way for tracking user activity after they've closed the app.

[whitehatguy]

Hi @Sora2455,

Push Notifications that don't show visible notifications to the user are currently disallowed in all browsers, and I don't see that changing.

I'll clarify what I was suggesting. This developer article for Idle Detection lists the following use case:

Chat applications or online social networking sites can use this API to let the user know if their contacts are currently reachable.

Let's say you have a PWA installed, and it has been granted either Notifications permissions (for push notifications) and/or is using Web Periodic Background Synchronization.

I think based on this comment from @reillyeon that the design intentionally prohibits these types of applications (specifically, applications designed to deliver content notifications to users via service workers) from signaling their server that the user is active/idle (either before or after receipt of push notifications or background sync events):

This is a key tension that needs to be resolved. We want developers to be able to direct notifications based on user presence but don't want this to be a way for tracking user activity after they've closed the app.

If the intent is to exclude apps that use service worker events (while the app is "closed"), then it might be good to call that out explicitly in the specification.