Project

General

Profile

Feature #5774

Robust time syncing

Added by Tails over 6 years ago. Updated over 1 year ago.

Status:
In Progress
Priority:
Elevated
Assignee:
-
Category:
Time synchronization
Target version:
-
Start date:
05/17/2015
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

https://tails.boum.org/blueprint/robust_time_syncing/

Starter:
No
Affected tool:

Description

See the blueprint.

Subtasks

Feature #9420: Wait for feedback from -ux@ regarding the proposed time sync'ing user storyResolved

Related issues

Related to Tails - Feature #6112: Safer tordate parameters Confirmed
Related to Tails - Feature #5773: Revisit network fingerprinting design wrt. NTP Confirmed
Related to Tails - Feature #5424: Think about tordate htpdate changes Rejected
Related to Tails - Bug #9256: Don't restart Tor after setting the right clock Confirmed 04/17/2015
Related to Tails - Feature #10819: Allow changing timezone in session Duplicate 12/31/2015
Related to Tails - Bug #11285: Check if we need to disable UseDefaultFallbackDirs in Tor 0.2.8+ Resolved 03/26/2016
Related to Tails - Bug #11589: Time syncing over bridge is fragile Confirmed 07/22/2016
Related to Tails - Feature #12094: Persistence preset: localized timezone for displayed time Confirmed 12/28/2016
Related to Tails - Feature #5366: When htp fails the user should be prompted Rejected
Duplicated by Tails - Feature #8977: Get rid of tordate Duplicate 02/27/2015
Blocks Tails - Feature #5462: Persistence preset: Tor state Confirmed 08/26/2016
Blocked by Tails - Feature #6284: Display time in local timezone Confirmed 10/27/2015
Blocks Tails - Bug #15548: Tails can't establish a connection with obfs4 bridges and a hardware clock too far away from UTC Confirmed 05/09/2018

History

#1 Updated by intrigeri over 6 years ago

  • Starter set to No

#2 Updated by BitingBird over 5 years ago

  • Subject changed from robust time syncing to Robust time syncing

#3 Updated by BitingBird about 5 years ago

#4 Updated by BitingBird about 5 years ago

  • Related to Feature #5773: Revisit network fingerprinting design wrt. NTP added

#5 Updated by BitingBird about 5 years ago

  • Related to Feature #5424: Think about tordate htpdate changes added

#6 Updated by intrigeri about 5 years ago

  • Category set to Time synchronization

#7 Updated by intrigeri almost 5 years ago

#8 Updated by Dr_Whax almost 5 years ago

After discussing this with various knowledgeable Tor folks, the consensus seem to be that we just have to ask the user to set the time so we can bootstrap the Tor process.

#9 Updated by intrigeri almost 5 years ago

After discussing this with various knowledgeable Tor folks, the consensus seem to be that we just have to ask the user to set the time so we can bootstrap the Tor process.

May we please have the reasoning behind this conclusion?

#10 Updated by intrigeri almost 5 years ago

  • Assignee set to Dr_Whax
  • QA Check set to Info Needed

#11 Updated by intrigeri over 4 years ago

intrigeri wrote:

After discussing this with various knowledgeable Tor folks, the consensus seem to be that we just have to ask the user to set the time so we can bootstrap the Tor process.

May we please have the reasoning behind this conclusion?

I would still love to hear more about this => ping?

In the meantime, I did some research on my side, and it seems that ChromeOS does something very similar to DrWhax' proposal:

Sadly, most of their design docs, UI mockups etc. are apparently not accessible to non-Google employees or something, so it's not easy to understand why they did what. Still, the resulting code is there: https://src.chromium.org/viewvc/chrome?revision=266431&view=revision

#12 Updated by intrigeri over 4 years ago

  • Blueprint set to https://tails.boum.org/blueprint/robust_time_syncing/

#13 Updated by intrigeri over 4 years ago

#14 Updated by intrigeri over 4 years ago

#15 Updated by intrigeri over 4 years ago

  • Description updated (diff)

Moved all the relevant info from this ticket to the blueprint.

#16 Updated by intrigeri over 4 years ago

  • Status changed from Confirmed to In Progress
  • Assignee deleted (Dr_Whax)
  • QA Check deleted (Info Needed)

#17 Updated by intrigeri over 4 years ago

  • Target version set to Hardening_M1

Importing target version that anonym had set on #8977, and with which I fully agree.

#18 Updated by intrigeri over 4 years ago

#19 Updated by intrigeri over 4 years ago

  • Blocked by deleted (Feature #5462: Persistence preset: Tor state)

#20 Updated by intrigeri over 4 years ago

#21 Updated by intrigeri over 4 years ago

  • Type of work changed from Research to Code

The user story and tentative roadmap have been ACK'd on -ux@ => next step is to actually implement this.

#22 Updated by intrigeri over 4 years ago

#23 Updated by sajolida over 4 years ago

  • Related to Bug #9256: Don't restart Tor after setting the right clock added

#24 Updated by sajolida over 4 years ago

  • Target version changed from Hardening_M1 to 2017

#25 Updated by intrigeri over 4 years ago

  • Target version changed from 2017 to 2018

#26 Updated by sajolida about 4 years ago

#27 Updated by intrigeri almost 4 years ago

  • Related to Bug #11285: Check if we need to disable UseDefaultFallbackDirs in Tor 0.2.8+ added

#28 Updated by bertagaz over 3 years ago

  • Related to Bug #11589: Time syncing over bridge is fragile added

#29 Updated by Dr_Whax over 3 years ago

  • Description updated (diff)
  • Assignee set to bertagaz
  • Target version deleted (2018)

#30 Updated by intrigeri over 3 years ago

I'm a bit lost: did we keep this on our roadmap in the end? bertagaz, did you volunteer? If yes, please set the correct target version. Thanks!

#31 Updated by Dr_Whax over 3 years ago

intrigeri wrote:

I'm a bit lost: did we keep this on our roadmap in the end? bertagaz, did you volunteer? If yes, please set the correct target version. Thanks!

It was on the roadmap but without a deadline.

#32 Updated by intrigeri about 3 years ago

  • Related to Feature #12094: Persistence preset: localized timezone for displayed time added

#33 Updated by BitingBird over 2 years ago

  • Description updated (diff)
  • Target version set to 2019

#34 Updated by BitingBird over 2 years ago

  • Description updated (diff)

#35 Updated by intrigeri about 2 years ago

The thread that starts at https://mailman.boum.org/pipermail/tails-dev/2017-December/011945.html shows that this is more urgent than we thought. Is it an option to swap this with something else that was on your (plural) roadmap for 2018?

#36 Updated by u about 2 years ago

  • Related to Feature #5366: When htp fails the user should be prompted added

#37 Updated by intrigeri over 1 year ago

  • Description updated (diff)
  • Assignee deleted (bertagaz)
  • Target version deleted (2019)

As per roadmap updating process. Of course, feel free to re-add it once there's a team :)

#38 Updated by intrigeri 6 months ago

  • Blocks Bug #15168: Improve UX when hardware clock is set to localtime in a timezone too far from UTC added

#39 Updated by intrigeri 6 months ago

  • Blocks Bug #15548: Tails can't establish a connection with obfs4 bridges and a hardware clock too far away from UTC added

#40 Updated by intrigeri 6 months ago

  • Blocks deleted (Bug #15168: Improve UX when hardware clock is set to localtime in a timezone too far from UTC)

Also available in: Atom PDF