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

[erikvold]

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

[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.

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.

[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.

[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.

[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.

[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.

[sebastian]

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