Hello again,
Apologies for starting two threads in quick succession.
First of all I want to say thank you for all the improvements in handling clock skew between 0.3.5 and 0.4.5. We recently migrated Briar to 0.4.5, and some situations that are common on mobile, such as the system clock being configured with the wrong timezone, are now much less likely to affect Tor connectivity (except when using obfs4).
When the system clock is very far behind real time, Tor's clock skew events enable us to warn the user to check their time and date settings. When the clock is ahead of real time by up to a day, there are no clock skew events but Tor can bootstrap. But when the clock is several days ahead of real time, there are no clock skew events and Tor gets stuck boostrapping at 14%.
At the moment we're having trouble distinguishing this situation from other situations that might cause bootstrapping to get stuck, such as access to the Tor network being blocked. So ideally we'd like to be able to detect that the clock is the problem and ask the user to fix it.
I should say that this is probably a rare situation. Old devices that haven't been turned on for a while sometimes reset their clocks to a point in the distant past, but I've never seen a device spontaneously change its clock to a point in the distant future. Still, people do mess around with the time and date settings so we'd like to detect and fix this issue if possible.
Is there any way for Tor to tell, during bootstrapping, that the system clock appears to be far ahead of real time?
Thanks, Michael