Definitely. I will keep you posted on the progress.

Im going to let this API mature a bit before I make a decision on it. The immediate problems I'm seeing with the specification is that it requires permission from the user. That kind of defeats the purpose when used as a security mechanism. We can use this discussion as an RFC for this. I guess the first questions are:

1. What should happen if the user denies permission to the Idle Detection API? Should we fall back to the timer based idle detection or just bail out and no op? I think if a user is prompted for permission and you ignore their answer and track their activity anyway might make them lose trust. I personally think don't ask, don't tell is better. If idle security is a requirement for your app then prompting the user is just adding unnecessary friction.

2. We can definitely make this an optional configuration, Im just wondering what the benefits are over the current implementation. I know that its native implementation is probably more performant, but I don't think performance is an issue since we have the ability to move the timers to a separate thread via web workers.