On 05/18/2015 01:42 PM, sajolida wrote:
> intrigeri:
>> [Please keep anonym Cc'd; also Cc'ing tails-dev@ once so that people
>> there learn about this discussion -- but please drop tails-dev@ from
>> the list of recipients when replying. Thanks!]
Dropped tails-dev@ now, which apparently was forgotten. :)
>> anonym and I (thanks to an initial suggestion by DrWhax) came up with
>> a draft proposal to change how we set the system time in Tails, and
>> how this integrates with the Tor bootstrap process.
>>
>> We would like to get some initial feedback regarding the proposed user
>> story. Note that it is related to how timezone selection will be
>> presented in the new, revamped Greeter.
>>
>> => see the "Ask the user what time it is" section on
>> https://tails.boum.org/blueprint/robust_time_syncing/
>
> I like it.
\o/
>> Don't hesitate asking any question that's not answered in that
>> blueprint yet, no matter how "stupid" you might think it is: quite
>> often, this very kind of questions helps looking at the problem at
>> hand from a different angle, and find better solutions :)
>>
>> If anyone has comments or questions on the technical/implementation
>> aspects, please do so in separate messages, sent to tails-dev@ only.
>
> Maybe I'll mix up too much UI and implementation in my questions but
> here they are:
>
> - The blueprint mentions that "certain OSes set's the BIOS clock to the
> local time". How would this interfere with the current proposal?
Actually, that statement explains perhaps 90% of the reason why this
problem exists for us in the first place. First, let's note that the
BIOS/hardware clock stores the time *without* timezone, so it's up to
whoever reads/writes it to make assumptions about the timezone. That's
where Windows differs from all other relevant OSes; it interprets this
time differently. So if Windows treated the hardware clock as if in UTC,
most users would have a correct clock from Tails perspective. The only
users that would have the time issue would be those for which the clock
tryly is correct, e.g. it has drifted, or the CMOS battery has died.
It's worth noting that Windows (7 and up, at least) can be configured to
use UTC for the hardware clock, but a quick look it seems buggy, so I'm
unsure if we want to recommend users to do such a reconfiguration.
> - Shouldn't we ask for the timezone first and then the time, or the
> two things at the same time. Maybe that's what is already meant by the
> "and" in "And the corresponding UI lets me choose my preferred timezone".
The idea is to show all of it: date, time and timezone. And all of them
can be altered to set the system clock.
> - Would people on Windows be asked for this every time or otherwise
> have a wrong clock on Windows?
In the first and second iterations, we would nag users with a popup as
soon as the clock is detected to be incorrect (i.e. Tor complains that
it is when we bootstrap). For Windows users that indeed means that
unless they live in a timezone close to UTC (so their local time
coincides with UTC == what we expect ==> Tor will be happy) they will be
nagged every single time.
Of course, in the final iteration we'd always show the clock in the
Greeter, and the hope is that users will fix it there if needed so they
won't be nagged later. And with persistence we'll preserve the timezone
choice so that it only have to be selected once (or until Windows
manages to set the time incorrectly, which unfortunately isn't so rare).
It could be that the situation in the first and second iterations is a
bad enough UX regression that we don't want to do it. If so, perhaps it
can be mitigated by supporting persistence of the chosen timezone
already in these iterations?
> - How wrong the clock has to be to trigger that stuff? I read from my
> current consensus:
> - "valid-after 2015-05-18 11:00:00"
> - "valid-until 2015-05-18 14:00:00"
> If all consensus are valid during 3 hours, then having the clock off
> by 10 minutes would trigger that stuff 1 out of 18 times (very roughly).
> That sounds reasonable.
I think the worst case is if you bootstrap Tor at the moment when a new
consensus has been created, which is hourly, e.g. 11:00:00 sharp. If
your clock is just a few seconds in the past, e.g. 10:59:30, the
consensus you just fetched will not be valid yet. Of course, in a few
seconds it will, but Tor isn't great at promptly detecting when these
things changes, IMHO.
> - How precise the clock must be set by the user to work? and to get
> hidden services to work (that's advertised as the feature that needs the
> most precise clock)? Would ±5 minutes work? If my computer's clock is
> off, then I might have to fallback on a physical clock (let's say my
> watch) which can often be ±5 minutes off.
For the consensus, it can be hours incorrect, it just has to be within
[valid-after, valid-until] (so, note that clocks that are in the past is
worse). For hidden services, IIRC it can be up to 30 minutes incorrect
in either direction.
Cheers!
