Open Bug 1554313 Opened 5 years ago Updated 2 years ago

Classifier Update should wait for an user-idle period before initiating an update

Categories

(Toolkit :: Safe Browsing, task, P3)

task

Tracking

()

Performance Impact medium
Tracking Status
firefox69 --- affected

People

(Reporter: jesup, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf:pageload, perf:responsiveness, Whiteboard: [geckoview:p2])

When the classifier update's timer fires, it should queue a time-bounded idle request to start the update (to avoid being locked out of updating forever). This will avoid it firing in the middle of user activity/interaction/pageload, hopefully.

If we just restarted the browser and the update time has passed, we want to update "soon", but I don't think we want to block initial loads on the update, and so we should use this mechanism in that case as well - the reasoning is that most browser starts will fall into the "I haven't run the browser in 30/60 min" case, and always blocking loads (or slowing them down) has a very low increase in security for a fairly noticeable hit to startup/load performance. We could adjust the deadline in this case, depending on how far out of date we are.

Given the default timeouts of 30/60 minutes for update checks, even a multi-minute update deadline would be ok for the already-running case, and maybe for the startup case.

Priority: -- → P2
See Also: → 1553842

Bugbug thinks this bug is a task, but please change it back in case of error.

Type: defect → task
Whiteboard: [qf:p3:pageload][qf:p2:responsiveness][geckoview] → [qf:p3:pageload][qf:p2:responsiveness][geckoview:p2]

Do you have a profile of this? How does it block it GeckoView startup?

Flags: needinfo?(rjesup)

Classifier updates often (in order to catch emergent phishing/etc attacks). When you restart the browser, frequently the classifier needs to update. Dimi can tell you (I forget now, though I did know at one point) if the initial classifier update blocks initial page load (I think it currently does). I'm suggesting in the startup case we may want to relax that, since this significantly hurts initial startup&load time. There is a user security risk to this, however.
Dimi and I discussed this over slack a year-plus ago; I forget where it ended.

Flags: needinfo?(rjesup)

sorry for the late reply.
Right now, the classifier update doesn't block the initial page load.
We had done some works to improve the performance of update and avoid doing it on every startup ((Bug 1531354 ). We also change update thread to use LazyIdleThread (Bug 1553855).
So I think at this point, Safe Browsing update shouldn't affect the startup load significantly. But if it still does, let me know and I'll see if there is any thing we can improve.

Priority: P2 → P3
Performance Impact: --- → P2
Whiteboard: [qf:p3:pageload][qf:p2:responsiveness][geckoview:p2] → [geckoview:p2]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.