Chrome 94 was recently released with a new feature: Idle Detection.
Specifically, there’s a new JavaScript API called IdleDetector. It reports two things to the JS code of the web page you’re viewing: keyboard/mouse activity, and if your screen is locked or not.
Much has been said about the diabolical nature of this new capability in Chrome…
Thing is, while we can be forgiven for doubting Google’s motives in adding this feature, it just so happens that Idle Detection is actually quite safe – and useful!
What does IdleDetector do?
In the past, web pages running in your browser had no way of knowing if you were actively using your puter or not.
This could be problematic because sometimes as a programmer, you want to delay certain actions (like updating the page, running a background task, etc) if the person is not using your page.
With IdleDetector, that’s now possible.
Well, okay… but does any site really need this?
Frankly, most sites don’t need it.
I can think of a few exceptions, such as JavaScript-heavy sites like Google Docs, and so on. But most of the time, it won’t even be needed.
There is one situation where it’s really handy: PWAs (Progressive Web Apps). If you don’t know what a PWA is, watch my vid on PWAs!
Since PWAs are literally web pages running in a window on your desktop, they really need to know when they (and the user) are active or not. IdleDetector solves this problem.
For example, I made a proprietary chat + voice/video-calling app for a client. You use it as a PWA. In order to have proper detection of Here / Away status for each user, IdleDetector is perfect!
Wait, isn’t that a huge security threat?
No, actually. Contrary to what everyone else is saying, the IdleDetector API requires explicit, active permission from the user for every site it’s used on. Lemme explain that one!
Ya know how every site you visit these days gives you a Notifications popup? Ya know how that’s really annoying?
Well, that’s not supposed to happen. In JS, a call to Notification.requestPermission() is supposed to require an actual ‘user gesture’ (aka click or tap) before permission is requested in those annoying popups. For some odd reason, browser makers just ignored this rule, so at the moment we’re endlessly irritated by those popups.
What’s worse, because so many sites send push notifications, push servers are often overwhelmed – which means much of the time, you won’t get notifications you signed up for. Well done, coders and browser makers!
IdleDetector actually follows the rules: Before a site can use it, the user must explicitly click to allow that site to even ask if it can use IdleDetector (in yet another popup). But unlike Notifications, that permissions popup CANNOT be launched programmatically. That means that sites need to do something like this:
- Add button somewhere: Alllow Idle Detection
- Get user to click that button
- Upon clicking the button, the user’s browser shows them the permissions request popup for Idle Detection
- If they allow it, the site can use it. If they deny it, POOF! No Idle Detection – period.
You can also configure your browser to never allow IdleDetector – just like with push Notification popups!
How do you use it?
I’ll leave the technical details to this handy article: Detect inactive users with the Idle Detection API
I will only add a few things.
First, note that the Locked/Unlocked detection does NOT include when your screensaver is running. If you leave your puter and it doesn’t automatically lock (even if the screen goes to sleep), the ‘locked’ status will never be triggered. So, ‘locked’ literally means your puter is locked at the OS level, and the user will need to type in his password when he returns to his puter. Forget about screen savers, low power modes, and so on – those are all ‘unlocked’!
Second, Idle/Active detection could formerly be done in JavaScript via mouse/keyboard event polling along with window onFocus detection. But it was pretty crap… IdleDetector fixes this problem by checking the system (OS) level idle state and making it available inside JavaScript code. So, ‘idle’ doesn’t mean you’re not using Chrome; it means you’re not using ANY application on your system at all. IOW, it’s true idle/active detection for web sites.
Also note that the ‘threshold’ for detecting idle defaults to 60s. You can increase it if you want. That means that IdleDetector will report ‘idle’ only after 60s of no system-wide activity. BUT, it will instantly report ‘active’, ‘locked’, and ‘unlocked’ status changes.
Keep in mind that native applications you run on your puter ALL have access to locked/idle states, and you never grant them permission to have that information. With the Idle Detection API, you decide which sites get it, and which don’t.
Et Voila!
So, yes: IdleDetector is quite useful in certain cases.
And sure, it may mean more annoying popups to turn off – but nowhere near as many as Notifications caused.
And in the end, IdleDetector actually plays by the rules to make it easy to prevent sites from violating your privacy!
Recent Comments