How to block sites from requesting Idle Detection API permissions in Chrome
Google introduced a controversial API in Google Chrome 94 this month. Called Idle Detection API, it allows sites to query the device to find out whether it is idle or in active use. A device enters idle state if it is not used actively for a period; the API can request the idle state of components or events, such as the keyboard, mouse or screensaver.
Google suggests that sites could use it for a number of useful applications, such as revealing if contacts in chat are available, to reset Kiosk systems automatically after a period, or to run expensive computations only if the user is not idle.
Critics of the Idle Detection API, Mozilla and Apple specifically, point out that it has the potential for abuse. While it is true that users need to give permissions to sites before access to the Idle Detection API is granted, sites may convince users to give the permission. Engineers of the companies believe that the API may be abused for dark usage patterns or to run expensive computations when the device is idle.
Mozilla and Apple decided that Firefox and Safari won't support the Idle Detection API, at least not in its current form. Chrome users, and those running Chromium-based browsers, will get the API. Some companies may disable it in their browsers, others may not.
Chrome is a prime example. The API is already implemented in Chrome 94 Stable, and users may see requests by sites to give them permission. The default setting is set to "ask", which means that sites will request permission from the user each time a site is visited. Sites may be blacklisted or whitelisted, to block them permanently or allow access to the API without requests.
Chrome users may block all requests automatically by switching the default state of the site permission. Sites requests will be denied automatically if the switch is being made. The same setting may also work in other Chromium-based browsers who have implemented the API and have not disabled it.
Here is what needs to be done:
- Load chrome://settings/content/idleDetection in the web browser's address bar.
- Switch the Default behavior state from "Sites can ask to know when you're actively using your device" to "Don't allow sites to know when you're actively using your device".
Chrome won't display permission request prompts anymore once the change has been made. Just flip the preference again if you need to reset it. Another option that you have is to add sites to the allow list, as these may then use the API without request prompt.
Now You: what is your opinion on the Idle Detection API? (via Techdows)
I just checked the latest Vivaldi, and it’s disabled (I didn’t set it that way ;)
I’m a mac-boy, here comes nothing but a link to “Profile” (I’m German). No explanations.If you wish, I can send you a screenshot.
What about Edge? Has Edge no idleDetection?
@Bernhard Bauer
Edge has it as well. Open the internal page via the URL chrome://settings/content/idleDetection and you shall see.
That being said, privacy concerns in Edge are misplaced, you have no privacy by using it:
https://arstechnica.com/information-technology/2020/03/study-ranks-edges-default-privacy-settings-the-lowest-of-all-major-browsers/
Try Vivaldi or Brave, thank me later.
Only works for me using Chrome for Windows 10 desktop.
url fails (doesn’t exist) when parsed on both my pixel and motorola android 11 mobile phones.
I use both Brave & Chrome
Privacy is not the prime issue for me. It IS rapid, SAFE browsing free from unwanted popups.
Chrome is merely used when I need to USE Google Search over Brave Search, and I always take advantage of Voice input when using Chrome.
Very occasionally, whilst browsing US News sites that declare themselves unavailable to European IP addresses, I use Opera together with their open VPN.
Oh yes – I am 74 and a former Technology GURU for Price Waterhouse
About “Idle Detection API”,
Google’s view:
Detect inactive users with the Idle Detection API
https://web.dev/idle-detection/
Use the Idle Detection API to find out when the user isn’t actively using their device.
May 18, 2020 • Updated Aug 25, 2021
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.
Examples of sites that may use this API include:
> Chat applications or online social networking sites can use this API to let the user know if their contacts are currently reachable.
> Publicly exposed kiosk apps, for example in museums, can use this API to return to the “home” view if no one interacts with the kiosk anymore.
> Apps that require expensive calculations, for example to draw charts, can limit these calculations to moments when the user interacts with their device.
Mozilla’s view:
Idle Detection API · Issue #453 · mozilla/standards-positions · GitHub
https://github.com/mozilla/standards-positions/issues/453
[Closed] reillyeon opened this issue on Oct 28, 2020
“I consider the Idle Detection API too tempting of an opportunity for surveillance capitalism motivated websites to invade an aspect of the user’s physical privacy, keep longterm records of physical user behaviors, discerning daily rhythms (e.g lunchtime), and using that for proactive psychological manipulations..”
Apple’s view:
[webkit-dev] Request for a position on the Idle Detection API
https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html
Ryosuke Niwa rniwa at webkit.org
Wed Oct 28 21:19:57 PDT 2020
“Our concerns are not limited to fingerprinting. There is an obvious privacy concern that this API lets a website observe whether a person is near the device or not. This could be used, for example, to start mining bitcoins when the user is not around or start deploying security exploits, etc.”
The topic at ungoogled-chromium seems to have been [Closed] and left to the discretion of the developers.
Whether it will be disabled or become an opt-in/out feature is currently being withheld.
https://github.com/Eloston/ungoogled-chromium/issues/1659
In Brave, “Disable idle detection API #7054” was applied on Nov 7, 2020,
So it is mentioned as “already disabled in Brave”, but the reality is different.
https://github.com/brave/brave-core/pull/7054
It seems that APIs that had been disabled are now enabled, contrary to Brave’s intentions (specifications), so users should probably check it out.
Well, expecting another long article written by Brave justifying that it was not the case, we left it for some who may use it blah blah blah. I have no problem in having this API in Brave browser, but a detailed explanation is a must rather than saying not going to do it and later down the road still did it.
@owl @Yash
Instead of trolling, perhaps start reading the comment of @Ayy and my reply to it. The feature is disabled in Brave, independent testing suites confirm it. The settings page was left to rot because of the associated maintenance burden of a removal, the settings displayed there do nothing because the feature is hard-disabled in the background.
@Iron Heart,
> Instead of trolling, perhaps start reading the comment of @Ayy and my reply to it.
@Ayy,
https://www.ghacks.net/2021/09/27/how-to-block-sites-from-requesting-idle-detection-api-permissions-in-chrome/#comment-4504760
and my(@Iron Heart) reply,
https://www.ghacks.net/2021/09/27/how-to-block-sites-from-requesting-idle-detection-api-permissions-in-chrome/#comment-4504800
Your and @Ayy’s comments appeared long after my post (@Ayy’s post was unpublished, in moderation by Marin. And your post is more than half a day after mine!).
It’s self-explanatory by the timestamp, but the one who is really being a ridiculous troll (Iron Heart acting like an absolute god) is yourself.
Everyone is bored and fed up with your stupidity.
I’m warning you, at least know whether you’re posting “earlier posted” or “later posted”!
@owl
> Everyone is bored and fed up with your stupidity.
I am stupid for revealing your own posting to be uninformed / stupid? Yeah, don’t think so.
Just admit that you were wrong and move on.
@Iron Heart,
My only point to you is, “I’m warning you, at least know whether you’re posting “earlier posted” or “later posted”!” But again, you are trying to close with a lazy reply. Your eccentricity is appalling. Anyway, you seem to want to say that you have no denial.
Just give me an honest reply. So, do you understanding it?
I use Vivaldi as an alternate browser (set to delete all cookies upon closing). I was disappointed to note that this ‘feature’ was enabled in Vivaldi and has to be opted out of using the procedure noted in Martin’s very helpful posting. Of course less than 1% of Vivaldi users will be aware that they have this option, particularly since you can’t find it in the Vivaldi settings. Bad job by Vivaldi for sure.
Search: Idle Detection API | Vivaldi Forum
https://forum.vivaldi.net/search?term=Idle%20Detection%20API&in=titlesposts&matchWords=all&sortBy=relevance&sortDirection=desc&showAs=posts
Vivaldi’s view:
A “topic” was started by a user six days ago, but there is still no official statement.
In that topic, a community member replied, “Vivaldi 94™ ? will probably be released in more than ten years…” and a curiously dumb response, but it has been left unattended and no proper action has been taken.
It makes me wonder if this program (the “Vivaldi” project) does it have any legitimacy?.
I’m using Brave-Browser and had no idea about it until I read this article.
The Brave in use is Version 1.29.81 Chromium: 93.0.4577.82 (Official Build) (64-bit), but its “API” was implemented and enabled.
I disabled it, following the gist in the article.
Thanks, Martin, for the useful information.
The other chromium I use, Iridium, is currently Version 2021.06 (Official Build) (64-bit), but this new “API” feature was not yet implemented.
I tried Seamonkey a while back. Can’t tell if it works or not, so much other stuff beside the browser. Seems to like itself.
…… says the person complaining about other people complaining.
99% of the population do not care about this. Why are people crying and moaning when it can be turned off?
I understand the majority of the people on this site are privacy this, privacy that but you do love to complain about the small things in life.
whinebot
@ChromeFan: privacy may be a small thing in life to you, but for many people privacy is hugely important. Furthermore, pointing out this new feature is part of Ghacks’s remit, so kudos to Martin for bring this to our attention.
If privacy is so trivial to you, why do you post a comment meant to persuade Martin not to bother with an issue that is clearly of importance to others?
@Klaas Vaak
> “privacy may be a small thing in life to you”
Here we go making making assumptions about a person you don’t know. Who says privacy is a small thing for me? Just because I use Chrome as my browser, doesn’t me I do not value privacy.
> “why do you post a comment meant to persuade Martin not to bother with an issue that is clearly of importance to others?”
I am talking about the people in the comments. It is clearly a non-issue as one could turn it off.
Also, where am I ‘persuading’ Martin to not bother writing an article about this?
Next time put your reading glasses on, and don’t make assumptions about me.
@ChromeFan
> Who says privacy is a small thing for me?
You do, by stating privacy is a small thing in life.
I did not make a link with your using Chrome, I did not know you do, you did not state it, until your 2nd comment.
> I am talking about the people in the comments.
Call privacy one of the small things in life, means you are wondering why Martin even brought up this issue.
> It is clearly a non-issue as one could turn it off.
No, it is not a non-issue. You have to opt out of it, which means most people won’t be aware and will thus be tempted to give permission when asked, just to be able to keep browsing without hassles. This feature should be set to “disabled†by default.
> Next time put your reading glasses on
If you don’t have a good counter-argument making ad hominems is not the solution.
> don’t make assumptions about me
I did not, as I showed, you need to get over your hyper-sensitivity and understand what you are actually writing.
> “stating privacy is a small thing in life”
I did not say privacy is a small thing in life. Obviously it is not. When I say ‘but you do love to complain about the small things in life’, I was talking about the the permission which can be turned off. Maybe you misunderstood me?
> “You have to opt out of it”
The people that are not using Chrome, will have it disabled by default or not have this permission in their respective browser. Therefore, it is a non-issue to these people. The people that have Chrome, and are tech savy will disable this permission, therefore it is a non-issue to these people. For the rest, they (people that don’t care about privacy) will leave it as the default (on).
> “This feature should be set to “disabled†by default”
It will be on the browsers that are not Chrome.
> “making ad hominems is not the solution”
Apologies.
alternatively just stop using Chrome and switch to Brave or Ungoogled Chromium which have had it disabled for over a year, or any other browser really.
Yip in Brave and just updated Ungoogled Chrome and BOTH where ON!
@Dianthus
Read my reply to @owl. Brave contains a dead page, it is off by default. There are test websites for idle detection. Use them, you will see that it’s off.
or just use Firefox, especially in Strict Mode to give you far more privacy against tracking and linking
@mary
> Firefox
> privacy
Choose one. Firefox’s default settings are bad and when you mess with them, you are not really making yourself any less unique than you were before.
Firefox’s tracking protection only uses the Disconnect list and is therefore a joke even in strict mode. It can’t replace a real blocker a.k.a. uBlock Origin. Hell, even Privacy Badger is more effective than what Firefox ships by default.
Firefox’s ETP Strict mode doesn’t even need lists, please educate yourself and stop throwing your irrelevant opinions about unrelated topics. You do this ALL. THE. TIME. because you are ignorant and must shit on everyone who mentions Firefox
commentator: water at room temperature is wet
iron heart: WRONG! alcohol is also wet, and sometimes paint is wet too, and when frozen water isn’t wet, you lose and Firefox is a joke haha I win and saved the internet
you are an absolute trolling shambles, get some help
@mary
It is clearly you who has no clue here. Of course FF’s tracking protection is list-based, Mozilla even gives credit to Disconnect for their lists:
https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop#w_what-enhanced-tracking-protection-blocks
And there are only two differences between the “Standard” and “Strict” settings, namely:
– “Strict” blocks all third party cookies, “Standard” only blocks selected ones known to be trackers already.
– “Strict” blocks tracking scripts in all windows, “Standard” only does it in private windows.
In both cases Disconnect is used, just applied in a more restrictive and a less restrictive way. The Disconnect lists are a joke, as I said, even Privacy Badger should be more effective than this.
> WRONG! alcohol is also wet, and sometimes paint is wet too, and when frozen water isn’t wet, you lose and Firefox is a joke haha I win and saved the internet
If that is how you read my comments, perhaps it is you who needs to get some help… urgently.
here’s what I said: “in Strict Mode to give you far more privacy against tracking and linking”
In strict mode everything is isolated by eTLD+1
iron heart: but lists, wha wha blah blah lists opinion wha blah blah
you really are a piece of work
> And there are only two differences between the “Standard” and “Strict” settings
wrong. Strict also has smart blocking and dFPI. you really are a moz-hateful ignoramus
The current version of Brave had this enabled for me. I just disabled the default behaviour now, following the above directions.
@wilverine you are not alone
https://old.reddit.com/r/privacy/comments/pwkkbj/chrome_94_released_with_controversial_idle/heieb53/
brave is a lipstick wearing pig beholden to google
@keeping it honest (far from it)
Yet another clueless troll post by the lipstick man. It is as the comment of @Ayy and my reply to it say that it is, independent testing suites confirm it. The feature is hard-disabled in Brave. The internal settings page (which can’t be accessed from Brave’s own settings) was left there to reduce maintenance burden, without the settings on it having any effect whatsoever.
you sure about that? on the latest version when I visit that test page it says “Your browser doesn’t support the Idle Detection API… ?”, Brave didn’t remove the menu options for it but even if you add the site to the allow list it still doesn’t function so it’s definitely disabled.
you can confirm it yourself on their sourcecode and also their wiki. https://github.com/brave/brave-core/blob/master/app/brave_main_delegate.cc
https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)#what-chromium-features-are-removed-for-privacysecurity-reasons
@nico
I stand corrected, guess Brave is the only chromium browser actively trying to protect users currently.
@Ayy
It is as you say, Brave has it strictly disabled by default. They don’t remove the internal settings page of the feature because removing it entirely would be an unnecessary maintenance burden. Whenever Google does anything in relation to the page again in other parts of the code, things would break for Brave. No need to do that if users can’t normally access the page from Brave’s regular settings. Users who have found this page have copied the settings URL into the address bar and pressed enter, this this not what people using Brave would usually do, and the settings displayed on this page are inaccurate anyway because the feature is hard-disabled in the background.
As for Ungoogled Chromium, I can kind of see their argument. Chromium explicitly asks you for your permission before the feature gets activated, so they see no immediate need to remove it. Brave chose the disable-by-default route but that is just automatic denial of the permission – which is also OK in my book, just saying that I don’t blame Ungoogled Chromium for anything here.
@Iron Heart,
> Users who have found this page have copied the settings URL into the address bar and pressed enter, this this not what people using Brave would usually do
> As for Ungoogled Chromium, I can kind of see their argument. Chromium explicitly asks you for your permission before the feature gets activated, so they see no immediate need to remove it.
I enjoyed reading your textbook “excuses” as if you were speaking for the developers.
Indeed, there is no doubt that the specific current situation in this issue is as you describe it.
However, your commentary is full of sophistry to “defend” the issue, and you seem to be saying “this is the end of the matter”. This is only a small part of the essence of this issue.
If this was a problem with “your much hated Firefox”, how would you attack it? When I think about it, I can’t help but laugh at the drop in your comment.
So the gist would be something like this.
It should be user-first. In principle, it should be “secure” by default.
In other words, “APIs” that are criticized from many sides should be disabled by default and be an “opt-in” feature. If they explicitly ask for permission, it’s just annoying and no one will pay attention.
The inspection method described by Martin is a “normal method” for those with some skills. If the method displays something incomprehensible, then “some action (at least a “Note” should be added to the page where everyone can see it, etc.)” would be necessary.
Since this was a pending issue raised by Google in May last year, each browser vendor should have been able to prepare (verify) at least that much. In short, it was “laziness.
This issue was covered in an article in gHacks Tech News, so it was useful to notify gHacks subscribers.
Even in the slightest degree, It’s not because of your existence.
Recently, you have been acting arrogantly as if you are representing gHacks Tech News, but you should be aware and respectful that you are just a community member (subscriber).
You say, “I contribute to gHacks. The other commentors are jerks.” You tend to comment on things like that, but who do you think you are?
From my point of view, you seem to be nothing more than a “senseless, self-centered, selfish infant.
On the one hand, I like your attitude of “making clear assertions, giving examples of sources, and explaining in detail,” but on the other hand, everyone is fed up with your ridiculousness because you are always “obsessed with your own theory, making quibbles around keywords that are convenient for you, and digressing. You should do some self-reflection.
@owl
These are not excuses, and I am not speaking for the developers, although I have my reasons for posting what I posted.
They have hard-disabled this feature in the background, and have removed the link to the internal settings page of the feature from Brave’s official settings. I think that they did enough (= their due diligence) here. Removing this internal page, which you can only access via chrome://settings/content/idleDetection and not via Brave’s official settings page anyway, only causes issues.
Brave has to merge in new upstream releases of Chromium for web compatibility & security reasons, they are based on Chromium as you know. If the internal settings page is removed, and if any new code snippet of Chromium interacts with said internal page, this would cause building errors. Those internal settings pages are not as isolated as you seem to think they are either, so a potential removal is not a one trick pony that will never resurface in a troublesome way. Those aforementioned building errors might well be fixable, but any such fix costs time, and delays the release of browser versions based on newer Chromium code – sometimes these releases contain important security fixes.
So for cosmetic reasons, for an internal page you can’t normally access, they would make development harder for themselves and possibly delay security updates… Like, why would they do this? Because five people have found the associated internal URL of a page whose settings are dead anyway? No, thanks.
Comparing this to Firefox is misguided by the way, because Firefox does not have to deal with the sensibilities of merging in third party upstream code. If Mozilla left dead pages within the browser, it would just be pure negligence. The only comparison that would make some sense here would be group policies set by an admin, I think. If you set a group policy in Firefox, the associated setting becomes greyed out but still remains visible(!) within the settings page. As far as Chromium is concerned, the Brave devs act similar to group policy admins in favor of the user prior to releasing the browser, setting defaults favorable to privacy for Brave users in the background. I think this would probably be a valid comparison if you are desperate to make one. And Firefox rarely has sensible, user-friendly defaults, which I criticize often enough so no need to rinse and repeat here. Despite leaving a dead internal page behind for maintenance reasons, Brave does in fact have a sensible default here, contrary to the nonsense you claimed before.
Last but not least, you continue to say very uncharitable things about me, but you know what? As long as you fail to do your own research, as long as you fail to understand the peculiarities of software development, and as long as I am once more the only one here reminding you of your failures, you have no right to complain. Raise the standard of your research and comments, and there will not be any room for me to counter false information anymore. I am allergic to people failing to do their due diligence, you know. The quality of comments here has really hit rock bottom, with people claiming factually wrong stuff out of the blue, with zero research put in and – of course – zero sources given. If I appear to be arrogant or vindictive in my responses to such comments, it is because of my heavy annoyance at both the low quality as well as the sheer number of these comments. I won’t change my attitude, unless there is change in the overall quality of the comments or the valid alternative of these people leaving comes to pass, both would be equally acceptable to me.
That being said, I do believe that you @owl, at least try to argue in good faith here. For example, you saw a dead settings page and drew the wrong conclusions from that. While this reveals a lack of further in depth research, which is annoying, at least one can say that you made your argument in good faith, thinking that you have found a valid issue – fair enough. But there are others who are merely trying to provoke, deliberately trying to misunderstand me, insulting me, quote mining me out of context, and seemingly having a strong vendetta against me for whatever petty reason of theirs. And yes, these people are, as you put it, “jerks”. I can confidently say to these people that I have contributed more here than they ever will, and I have zero problems showing them the way out, preferably towards the troll cave from which they originally came. Sorry if this sounds uncharitable to you, I have been treated worse by them than this. I don’t complain, but neither should you or anyone else about the appropriate echo then, or defend them. I will deal with them as I always have, and this is usually still better than what they deserve for being the inflammatory trolls that they are.
@Iron Heart,
Unlike usual, I was amazed at how sincerely and honestly you replied to my reply without derailing it.
Your candid reply helped me to understand your sentiments.
I could fully feel your inner “kindness” and “benevolence”.
I would like to thank you for your kind message.
It is because I am interested in you that I take time out of my precious time to reply to you.
The only way to deal with jerks is to ignore them.
If you get a reply, it’s because your presence cannot be ignored.
As I have commented before, I have no animosity towards you. On the contrary, I respect you for your innocent “honesty”.
Your comment is full of exemplary elements, but it is flawed in that it exudes “exclusive hostility” toward dissenters.
Individuality is as diverse as faces and fingerprints are unique.
In short, it is impossible to have identical values and tastes. It is normal for parents, children, and even siblings to disagree with each other.
Even if their views and skills differ from yours, don’t look at it from a “binary” perspective of friend or foe, but as friends who share a common goal, even if the means are different.
People are repulsed by being denied or told what to do.
It is appropriate to offer hints for awareness, but not too much, or you will be antagonized.
Building skills requires extensive knowledge and diverse experience, and learning from mistakes is important.
Let’s do acknowledge differences in skills and be respectful of everyone.
@Ay
Actually I raised the issue at the Ungoogled Chromium issue tracker, but they won’t remove/disable it:
https://github.com/Eloston/ungoogled-chromium/issues/1659