Classifier Update should wait for an user-idle period before initiating an update
Categories
(Toolkit :: Safe Browsing, task, P3)
Tracking
()
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.
Comment 1•6 years ago
|
||
Updated•6 years ago
|
Comment 2•5 years ago
|
||
Do you have a profile of this? How does it block it GeckoView startup?
Reporter | ||
Comment 3•5 years ago
|
||
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.
Comment 4•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Description
•