GitLab

Directory authorities scan every relay every 22 minutes or so, to test reachability.

As part of establishing the Tor connection handshake, they get a netinfo cell from the relay. So if they look at it, they will know whether the relay's clock is right or wrong.

So we're nearly there. Now we should act when we find a relay with a wrong clock, to help the relay operator fix it, and to reduce the harm to clients.

I suggest taking two responses if a relay has a wrong clock:

(A) Don't assign it the Guard flag. Clients rely on their guards for time, e.g. because they need the guards to have proper cached dir info. And in the glorious future where we've made progress on #2628 (moved) and friends, while we won't want to rely solely on non-dir-auth relays to tell us if we're skewed, if we can drive down false positives from normal relays, the parameters get easier to pick for whatever solutions we decide on.

(B) Put the "BadClock" flag in our vote about it. We don't need to change the consensus building process, or even get that flag into the consensus itself. Just having it in the votes means that consensus-health and relay-search can look at it and visualize it for relay operators, rather than needing to do their own clock scans. (And having it there helps the operator debug confusing questions like why they aren't getting the Guard flag.) And as a bonus here, eventually Serge will put that flag in its bridge networkstatus document, so bridgedb can make a smarter decision, and so relay-search can visualize it too.