Initial spec text for bounce tracking deletion timer. #37
Conversation
|
@jyasskin PTAL. This is parented to the other PR. I'm not sure github handles that well so you may see changes from that other PR in this one as well. If you could give me a directional review of the new text that would be great. I'll be OOO till Tuesday and will try to address feedback then. |
index.bs
Outdated
| 1. If |bounceTime| + [=bounce tracking grace period=] is less than or equal to | ||
| |now|, then [=iteration/continue=]. |
There was a problem hiding this comment.
Since these are wall times, what happens if the user adjusts their system clock during the bounce tracking grace period? Since bounces would happen within a single user agent session, maybe some of this should use monotonic moments?
There was a problem hiding this comment.
While a single bounce may be within a single browsing session, the interactions may come in different browsing sessions. For that reason we can't really use monotonic time.
As a consequence if the user change's their clock significantly it could trigger deletion. The lifetime of user activation protection is expected to be much longer than the grace period or timer period, though. So only large changes are likely to cause this to happen.
There was a problem hiding this comment.
If the user sets their clock to earlier, I think all the activations and candidate bounces live longer than they're supposed to. So ... maybe we should have the bounce tracking timer check for |bounceTime| or |activationTime| being after |now|, and ... reset those to |now|? It's fine to leave that as a TODO in this PR.
wanderview
force-pushed
the
dev-timer
branch
2 times, most recently
from
0c2fe15 to
f6aacbf
Compare
|
I've tried to address action items. PTAL. Thanks! |
index.bs
Outdated
| 1. If |bounceTime| + [=bounce tracking grace period=] is less than or equal to | ||
| |now|, then [=iteration/continue=]. |
There was a problem hiding this comment.
If the user sets their clock to earlier, I think all the activations and candidate bounces live longer than they're supposed to. So ... maybe we should have the bounce tracking timer check for |bounceTime| or |activationTime| being after |now|, and ... reset those to |now|? It's fine to leave that as a TODO in this PR.
Hmm, I'm unsure if it's worth doing anything about this. I'll add a TODO item to consider it, but it seems unlikely users will be doing this at scale. And in terms of a single user its not catastrophic for deletion to be delayed based on a rare event. |
This text roughs in the general shape of how deletion will occur based on a timer comparing against timestamps stored in a global map. Some details still need to be resolved.
SHA: 28b3e64 Reason: push, by wanderview Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This text roughs in the general shape of how deletion will occur based on a timer comparing against timestamps stored in a global map. Some details still need to be resolved.
Preview | Diff