Intent to Continue Experimenting: Idle Detection API

[Reilly Grant]

Contact emails

ay...@chromium.org, rei...@chromium.org

Explainer

https://github.com/WICG/idle-detection/blob/master/README.md

Specification

https://github.com/WICG/idle-detection/pull/29

Design docs

https://github.com/WICG/idle-detection/blob/master/README.md

Summary

The Idle Detection API notifies developers when a user is idle, indicating such things as lack of interaction with the keyboard, mouse, screen, activation of a screensaver, locking of the screen, or moving to a different screen. A developer-defined threshold triggers the notification.

Blink component

Blink>Input

TAG review

https://github.com/w3ctag/design-reviews/issues/336

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

The IdleDetector interface complements existing indicators of user activity such as mouse and keyboard events, and the page visibility state. Sites using an IdleDetector should function correctly in browsers which do not implement it (as they do today) but with all the known problems documented in the motivations for introducing this API.

Gecko: No signal, the chrome.idle API is supported in Firefox's Web Extensions implementation. There has been no comment on support in web content. I will file a standards position issue once the specification PR mentioned above is merged.

WebKit: Negative, Safari does not support the chrome.idle API in their Web Extensions implementation. Apple included this API in a list of proposed APIs for which they had fingerprinting concerns. I will open a thread on webkit-dev once the specification PR mentioned above is merged.

Web developers: Positive, there were two issues filed about choosing the “notifications” permission which drove the decision to switch to a new “idle-detection” permission for this Origin Trial. 

Ergonomics

This API uses asynchronous events and Promise-returning functions to allow Chrome to maintain good performance and future-proof the design.

Activation

A polyfill for this API would not be useful as the benefit of the API comes from the information which cannot otherwise be gathered using existing methods. It is possible that this API could be combined with existing methods for determining user presence into a single library for this purpose. Developer outreach has already begun, including a post about the feature on web.dev.

Security

The security and privacy risks are discussed in the explainer and draft specification.

Goals for experimentation

The goal of this experiment is to validate that the API provides an improved user experience. Interested developers have been able to build prototypes while this feature has been available behind a flag. We are now ready to move forward with experiments involving real users.

Experimental timeline

The experiment will be extended for 2 additional milestones, continuing through the stable release of Chrome 87 and ending a week before the stable release of Chrome 89.

Reason this experiment is being extended

An experimental version of this API was originally launched in Chrome 84 and will remain available through November 10, 2020. Due to a misunderstanding of our mutual timelines the primary partner interested in this API will not be able to roll out an experiment using this API to a significant number of users until after the original Origin Trial has ended.

This extension will also introduce a change in the permission model. The original design reused the "notifications" permission to grant access to this feature. Due to feedback on this choice we have introduced a separate "idle-detection" permission and an IdleDetector.requestPermission() function for requesting it, as well a Chrome UI for managing it once it has been granted.

Ongoing technical constraints

None.

Debuggability

An option to override the Idle Detection state for testing purposes is available through Chrome DevTools in the Sensors panel.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, this feature is supported on all platforms other than Android WebView. Adding support for this final platform requires plumbing a new permission type through the WebView API.

Is this feature fully tested by web-platform-tests?

Yes, https://wpt.fyi/results/idle-detection.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=878979

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/4590256452009984

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/OuwzBmH02M4/5ChXdXZQBwAJ

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/9OwINXHzbUE/m/LOcbtEjAAAAJ

This intent message was generated by Chrome Platform Status and polished with love and care.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Mathias Bynens]

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMY%2BMsbTBC5cnwjcEnwzzYriBQf88fUNRr3VTHtVHMgTvw%40mail.gmail.com.

[Yoav Weiss]

IIUC that would mean that the feature is in OT from M84-M89, so for 6 full milestones.

That's hitting the typical limit we want OTs to run (above which we consider them to have a high risk of burn-in)

Can you elaborate on why such a long OT period is required? Any feedback from the OT so far? Have commercial properties come to rely on the API in ways that would make them sad if it were to change or go away for a short period of time?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgaJBJPACoUM2qW0XUYDev0117CyYrNYUmSp39R-K5MWvg%40mail.gmail.com.

[Reilly Grant]

As explained in the "Reason this experiment is being extended" section there is not enough feedback on this Origin Trial so far because our primary partner did not deploy a site using the feature during the M-84 or M-85 stable periods. We considered formally cancelling the Origin Trial due to lack of participation and rescheduling but by that point it was close enough to the start of the M-86 stable period that it didn't seem worth the confusion we could cause by disabling and reenabling the feature while developers are finally starting to look at using it.

The revised schedule ends the Origin Trial at the M-89 stable release, just as the current trial would end at the M-87 stable release, so only 5 milestones.

[Yoav Weiss]

LGTM to continue experimenting till M89 hits stable. 

[Reilly Grant]

We are still coordinating with our partners to figure out when they will be ready to deploy code to a wider audience using this experiment. I will not be enabling the Origin Trial in Chrome 87 and will update this thread when a new milestone has been chosen, likely Chrome 88. Interested developers can continue to test out the API locally, including the changes landed in Chrome 87 described above, using the chrome://flags/#enable-experimental-web-platform-features flag.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Reilly Grant]

Updating this thread with the new experiment timeline: We will be enabling this Origin Trial when Chrome 88 is released to stable-channel and running it for 3 releases. Chrome 90 will be the last release. Origin Trial tokens will not be renewable past May 18th, 2021 (the stable cut date for Chrome 91).

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Thomas Steiner]

On Thu, Jan 14, 2021 at 3:38 AM Reilly Grant <rei...@chromium.org> wrote:

Updating this thread with the new experiment timeline: We will be enabling this Origin Trial when Chrome 88 is released to stable-channel and running it for 3 releases. Chrome 90 will be the last release. Origin Trial tokens will not be renewable past May 18th, 2021 (the stable cut date for Chrome 91).

PR to update our article accordingly.

[yo...@yoav.ws]

LGTM to experiment M88-M90, given that the experiment did not run on M87