Re: [Tails-ux] RFC: new time sync'ing user story

intrigeri:
>> In the context of Tails I think that displaying such a map of the world
>> (or any location information) should come with a clear message that this
>> is only to set the "clock display timezone" and not collected in any
>> way.
>
> Agreed on all this, added to the blueprint. In the Greeter, perhaps
> region selection (do we still have that, or is it hidden behind the
> Formats thing?) could be somehow merged with timezone input. Can be
> refined later.
>
>> We should also not mention any city in this interface (unlike GNOME
>> currently) but maybe only names of timezone.
>
> Yes, perhaps. I'm unsure but the details can be refined later.
>
>> Still, some timezone are only used in one country. For example Venezuela
>> is in -4:30, Iran in +3:30, and Afghanistan in +4:30. Yeah!
>> I could totally see people freak out about that.
>
> If they don't freak out when Tails is asking them a region in the
> Greeter, then perhaps they won't freak out when we ask them the
> same elsewhere, but who knows.

Yeah, I also thought about that and I have no clear answer. If of course
don't think people will react differently if the same question about
location is asked in the Greeter or in Tails Clock. We could find a
wording that solve this in both cases maybe.

>> We should do without it but I think I have a solution...
>
> Oh oh :)
>
>> Until we have Tails Greeter, why not save the timezone information in
>> persistence (as Tails Greeter would do) when it's configure through
>> Tails Clock or whatever timezone configuration tool we have? People
>> would start without timezone data from a fresh installation or when
>> using a DVD, but we save this information in persistence whenever
>> possible (maybe opt-in from the timezone interface).
>
> OK. Added to the blueprint.
>
> Opt-in sounds good: I'm personally mentally ready to make persist some
> stuff by default when persistence is enabled (e.g. the entropy seed),
> *but* that's because it's critical for security, combined with the
> fact that the user has little incentive to actively enable such
> a persistence feature, because they don't _feel_ the effects of not
> enabling it. Here, the drawback of not persisting is inconvenience for
> the user, and has no security implications, so I think we can leave it
> to them to decide whether they want more convenience (but some
> infoleak to persistence -- some people travel) or more security.

Sure. We might also wonder how this would interact with the current
persistence configuration wizard as we will have stuff to opt-in from
there and stuff to opt-in from the Greeter or Tails Clock and that, for
some time at least, might not be reflected in the persistence
configuration wizard. But I think we can wait for the problem to really
happen before analyzing and solving it.

>> I think that it should anyway be possible to reconfigure it after Tails
>> Greeter so that possibility might be good to have anyway.
>
> OK.
>
>>> [Nomenclature: let's use "clock display timezone" or something as much
>>> as possible here, since the actual system timezone will still be UTC
>>> in any case -- times in Nautilus etc. will still be displayed in UTC,
>>> and only Tails Clock and the time fixing dialog will use the
>>> configured timezone.]
>
>> Maybe Tails Clock and the timezone configuration interface should go
>> together (be part of the same extension) like in the current GNOME
>> interface we have.
>
> I think that's covered in the blueprint already: "The interface used
> by Tails Clock and by the upcoming time input GUI could perhaps be
> shared; this raises privilege separation issues that need to be
> thought through."

Good. I'm sorry I didn't read the blueprint again to write my second email.

--
sajolida