obfs4 documentation does not mention the need for a hardware clock set to UTC
It feels a bit weird that to learn about one of the most common issue with bridges, a user has to figure out that it’s documented on “known issues” but not on the page about bridges.
I’m wondering if https://tails.boum.org/doc/first_steps/startup_options/bridge_mode/ should link to https://tails.boum.org/support/known_issues/#utc.
#3 Updated by sajolida 2020-03-24 21:19:14
- File Additional_Clocks.png added
- File Beijing.png added
- File Time_Language.png added
- Status changed from New to Confirmed
Indeed, we should mention this issue on
Still, let’s be clear that the current known issue is crap, so the extra work of making it more visible as is will probably be helpful to very few people and might even be dangerous:
- We don’t tell how far is too far East from UTC.
Someone on Tor#32439 reports that UTC+3 is already problematic.
Do we have a way of knowing how far East is too far?
- I bet that Tor Launcher can get stuck on “Loading Network Consensus”
for other different reasons: at least bad or slow network, maybe
censorship (I’m guessing).
- The workaround that we are pointing to currently is to hack the
Windows registry. Something that very few people will know how to do and
that might vary depending on the version of Windows. I’m afraid that people
could break their Windows if they applied a wrong variant or didn’t
apply it correctly. We could still keep it as an alternative for power users
but only if we had something better.
1. Only explicit the problem but not mention the registry hack anymore. Maybe it’s better than nothing. Something along the lines of what we already have:
If you are East from UTC, connecting to Tor using `obfs4` bridges might be impossible and Tor Launcher might get stuck on Loading Network Consensus.
2. Instruct people to try setting their Windows on UTC from the UI. I tested this on Windows 10. The result is less convenient than hacking the registry but it’s way easier to perform and potentially less dangerous. People could test whether this solve their problem. If it does, they could either do the change when needed or configure another display clock for their local time. As you can see, not a really great solution either.
Below are some screenshots of this process.
Honestly, the situation of Tails with bridges has been very bad since pretty much forever because we lack development resources. I’m not sure that investing several hours of Technical Writing into this would make a significant difference so I’m tempted to go for 1 and forget about it.
intrigeri + cbrownstein: What do you think?
#4 Updated by intrigeri 2020-03-27 09:46:10
> * We don’t tell how far is too far East from UTC.
> Someone on Tor#32439 reports that UTC+3 is already problematic.
> Do we have a way of knowing how far East is too far?
My understanding is that anything strictly more East than UTC+1 is enough to break obfs4.
I agree that the registry hack is too hard/dangerous for many people.
I think option 2 has too far-reaching problematic UX consequences that IMO it’s not worth the tech writing effort.
> Honestly, the situation of Tails with bridges has been very bad since pretty much forever because we lack development resources. I’m not sure that investing several hours of Technical Writing into this would make a significant difference so I’m tempted to go for 1 and forget about it.
Realizing that it’s where we are at hurts a bit, but I have to agree with you here.
In passing, taking a step back:
- I don’t know if the ongoing work on Meek support will solve this. If Meek is not affected by this problem like obfs4 is, then supporting Meek would make this obfs4 problem less important for users in places where Tor is blocked, such as potentially Riou.
- If Meek does not solve the problem, then I think we’re back to what I wrote on
Bug #15168: “So the only way we can improve things in this situation is via Feature #5774 (more specifically, the part of the plan where we ”[let] the user set the correct time and choose their preferred timezone" whenever Tor fails to bootstrap" “and/or via the ”Integration with the new Greeter" part of that plan. Both refer to https://tails.boum.org/blueprint/robust_time_syncing/."
Note that on https://tails.boum.org/blueprint/network_connection/, we’ve postponed this to “Potential extra iterations”.