Opened 12 months ago

Closed 3 months ago

#7126 closed change (rejected)

Don't download filter lists while chrome.idle state is "locked"

Reported by: erikvold Assignee:
Priority: Unknown Milestone:
Module: Core Keywords: closed-in-favor-of-gitlab
Cc: kzar, mjethani, sebastian Blocked By:
Blocking: Platform: Chrome
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description

When the user is in a "locked" state for chrome.idle then I don't think we should be downloading updates for filter lists, because:

  • If the expiration is low (as it will be with diffs) then many updates will be retrieved that do no need to be.
  • We can save energy and bandwidth on the user computer and our servers.
  • User probably wants to conserve energy while in a "locked" state.

At the least I think we should add some delay/throttling to updates during "locked" state for chrome.idle, if we just delay/throttle then we could also do this during the "idle" state for chrome.idle.

https://developer.chrome.com/apps/idle
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/idle

Change History (7)

comment:1 follow-up: Changed 12 months ago by sebastian

  • Cc mjethani sebastian added
  • Component changed from Adblock-Plus-for-Chromium to Core

IMO, it's totally fine to perform filter list updates while the workstation is inactive / the screen is locked. That way filters are up to date, once the user resumes work, and we don't need to waste cycles while there is more urgent stuff to be computed.

With incremental filter list updates we may update filter lists as frequent as once an hour, but not more often (ignoring the randomization of the interval), which doesn't strike me as a huge waste of resources, in particular since the diff will be relatively small, hence requires not many resources to be processed.

comment:2 Changed 12 months ago by sebastian

  • Type changed from defect to change

comment:3 Changed 12 months ago by mjethani

I'll comment on this once I have looked into the incremental filter list updates spec, but on the face of it what Sebastian is saying makes sense.

comment:4 in reply to: ↑ 1 Changed 12 months ago by erikvold

Replying to sebastian:

IMO, it's totally fine to perform filter list updates while the workstation is inactive / the screen is locked. That way filters are up to date, once the user resumes work, and we don't need to waste cycles while there is more urgent stuff to be computed.

Unless we defer updates just after the chrome.idle state changes we could be updating while more urgent stuff is computed anyhow (ex: user becomes active to load an urgent page). I'm purposing a few options like throttling (more below), and we can mitigate this issue if we want to.

With incremental filter list updates we may update filter lists as frequent as once an hour, but not more often (ignoring the randomization of the interval), which doesn't strike me as a huge waste of resources, in particular since the diff will be relatively small, hence requires not many resources to be processed.

I'm not saying it's a "huge waste", it's just that I sleep about 8 hrs every day, I don't think it makes sense for abp to be updating during those hours, I just want the updates when I am active. I would like updates just before I am active but that is hard to predict (we could try though, like allow an update at 6am, or just before normal active hours), that is why I also suggested throttling.

comment:5 follow-up: Changed 12 months ago by sebastian

This seems like quite a micro-optimization to me. With incremental filter list updates, it's either a tiny update (both in regard of bandwidth consumption and processing effort) once an hour, or a larger update with the accumulated changes after n hours, which I doubt will make much of a difference in practice. With regular filter list updates on the other hand, the interval is usual so high that it doesn't matter either.

Not to mention the drawback that this will rather cause filter lists to be outdated more often than they were before (unless you can exactly predict when the user will be back). Moreover, as less predictable the download behavior is as less accurate will be our filter download stats.

comment:6 in reply to: ↑ 5 Changed 12 months ago by erikvold

Replying to sebastian:

This seems like quite a micro-optimization to me. With incremental filter list updates, it's either a tiny update (both in regard of bandwidth consumption and processing effort) once an hour, or a larger update with the accumulated changes after n hours, which I doubt will make much of a difference in practice. With regular filter list updates on the other hand, the interval is usual so high that it doesn't matter either.

It is a micro optimization I agree, but I wanted to make a bug for it anyhow, that doesn't mean we have to handle it anytime soon, I just want to record it.

Not to mention the drawback that this will rather cause filter lists to be outdated more often than they were before (unless you can exactly predict when the user will be back). Moreover, as less predictable the download behavior is as less accurate will be our filter download stats.

If the user turns off their computer, or turns wifi off, then the effect is the same as the most drastic option that I mentioned, so it's not uncommon. I'm not sure what the affect would be on our filter list download stats, I guess if we want to know how many active users we have then we'll have better stats.

comment:7 Changed 3 months ago by sebastian

  • Keywords closed-in-favor-of-gitlab added
  • Resolution set to rejected
  • Status changed from new to closed

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.

Note: See TracTickets for help on using tickets.