ay...@chromium.org, rei...@chromium.org
https://github.com/WICG/idle-detection/blob/main/README.md
https://wicg.github.io/idle-detection
Yes
https://web.dev/idle-detection/
https://github.com/WICG/idle-detection/blob/main/mdn-drafts/QUICK-REFERENCE.md
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.
To prevent a regression in experience for users who have already granted a site permission to access this information we are requesting a seamless transition from Origin Trial to Stable.
https://github.com/w3ctag/design-reviews/issues/336
Issues addressed
Origin Trial feedback
Duplicate mobile notifications are a top user complaint for our partner's messaging application. After deploying this Origin Trial their metrics showed that users who granted their site permission to know when they were active on their desktop device received far fewer mobile notifications. Metrics tracking whether users responded to messages however remained steady, showing that this improvement in user experience had no adverse effect on message delivery. In other words, it worked precisely as intended.
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 (https://github.com/mozilla/standards-positions/issues/453)
WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031565.html)
Web developers: Positive (https://discourse.wicg.io/t/idle-detection-api/2959)
This API uses asynchronous events and Promise-returning functions to allow Chrome to maintain good performance and future-proof the design.
Developer outreach has already begun, including a post about the feature on web.dev.
The security and privacy risks are discussed in the explainer and draft specification.
An option to override the Idle Detection state for testing purposes is available through Chrome DevTools in the Sensors panel.
Yes
IdleDetection
True, the IdleDetectionPermissionContext depends on VisibilityTimerTabHelper to implement incognito detection mitigations.
https://bugs.chromium.org/p/chromium/issues/detail?id=878979
https://bugs.chromium.org/p/chromium/issues/detail?id=1129665
https://web.dev/idle-detection/
https://github.com/WICG/idle-detection/blob/master/HOWTO.md
https://reillyeon.github.io/scraps/idle.html
https://chromestatus.com/feature/4590256452009984
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 hand-crafted with love.
--
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%3DMZHEYVTMX3HYb9SsVwSLq%2BjDGGG6CuRyw7C0Gr3nsxd-A%40mail.gmail.com.
On Mon, Jul 26, 2021 at 10:51 PM Reilly Grant <rei...@chromium.org> wrote:Gecko: No signal (https://github.com/mozilla/standards-positions/issues/453)
WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031565.html)
--
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/68e36d42-9a51-45a6-92cf-0b4b543092ben%40chromium.org.
Hi Reilly,Sorry it's taken so long for an API owner to chime in.Could you reply with more details about the analysis of and mitigations taken to address the kinds of risks raised in the Webkit and Mozilla feedback?
Finally, I don't believe that the concerns of behavioral tracking are well-founded. This API provides a higher-resolution indication of the current state but in order to establish patterns the site performing the tracking must be continuously active. Such a site, even without this API, can already create such a profile by observing when the site is visible, when the user interacts with it as well as background events such as system suspend and network changes which can be observed by any page allowed to continuously execute script. The additional information provided by this API does not seem particularly novel to such an attack, but is critical for the real-time messaging applications the API is targetting.
----Thomas Steiner schrieb am Dienstag, 27. Juli 2021 um 11:11:29 UTC+2:On Mon, Jul 26, 2021 at 10:51 PM Reilly Grant <rei...@chromium.org> wrote:Gecko: No signal (https://github.com/mozilla/standards-positions/issues/453)
WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2020-October/031565.html)
Mozilla's position gets even more negative now:jj
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/68e36d42-9a51-45a6-92cf-0b4b543092ben%40chromium.org.
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%3DMZ7W6-pucx95eAZ8K-DBwQEZ%3DSLtewgkZVHts59xsARZw%40mail.gmail.com.
On Mon, Aug 16, 2021 at 3:25 PM Reilly Grant <rei...@chromium.org> wrote:Finally, I don't believe that the concerns of behavioral tracking are well-founded. This API provides a higher-resolution indication of the current state but in order to establish patterns the site performing the tracking must be continuously active. Such a site, even without this API, can already create such a profile by observing when the site is visible, when the user interacts with it as well as background events such as system suspend and network changes which can be observed by any page allowed to continuously execute script. The additional information provided by this API does not seem particularly novel to such an attack, but is critical for the real-time messaging applications the API is targetting.Another argument made by a Webkit representative was that since sites can already do the things you specified above, they can keep doing that and this API is not necessary. The Webkit representative arbitrarily ended the thread at that point without giving you an opportunity to reply, so for the record could you reply to that argument here?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLkFeQszAdrceNCDU4%2BrO36%3DS_deq3T4iVgDjZ1D%2BbhOmw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWF%3DUpG-MZkz8UsUDofF0zQ_w1_-nK6a9H00rhyNzUTcw%40mail.gmail.com.
Thanks for the additional background. I still do not see how this “tackles the arguments” I have seen in Mozilla and WebKit’s objections to this feature.I understand the objections to be something like “the user harm inherent in this feature outweighs the developer benefit.” So it looks to me like the argument is over whether this summit is worth approaching at all, directly or indirectly. To my mind, tacking the arguments presented would either include showing why the developer benefit is being devalued, or providing additional mitigations for user harm (to the current proposal, not theoretical future protections).I do get the argument that this is a relatively responsible way to work on the feature. But when your vantage point is “this is a relatively responsible way to add user harm to the platform” it is not very convincing.
Thanks for the additional background. I still do not see how this “tackles the arguments” I have seen in Mozilla and WebKit’s objections to this feature.I understand the objections to be something like “the user harm inherent in this feature outweighs the developer benefit.” So it looks to me like the argument is over whether this summit is worth approaching at all, directly or indirectly. To my mind, tacking the arguments presented would either include showing why the developer benefit is being devalued, or providing additional mitigations for user harm (to the current proposal, not theoretical future protections).