Page MenuHomePhabricator

Qubes-Whonix 14 timesync vs usabilty decision
Closed, InvalidPublic

Description

Whonix 14 will come with major time related deanonymization attack defenses. The only networking allowed is Tor and sdwdate until sdwdate succeeded, i.e. until the clock is unlinked from all other VMs. (T533)

On the Qubes-Whonix side this does not work well yet usability wise.

The real solution would be T534, but that is hard to implement. Needs tons of time that I currently do not have. I doubt I can implement it in time for Whonix 14.

Options are:

  • 1) disable this new feature in Qubes-Whonix [1]
  • 2) leave it enabled, but then users would have really bad usability [2]
  • 3) somehow magically find a contributor who implements T534 [3]

Which option do you suggest? @marmarek


[1] Enabling / disabling this feature is as simple as an /etc/whonix_firewall.d/ config snippet drop-in.
[2] Tor Browser might already be started, but with broken connectivity, since time synchronization is not done yet. And if time synchronization was to fail, then this issue would not be communicated to the user.
[3] I could ask iry to work on the gui part, but at the moment iry has its hands full with anon-connection-wizard.

Details

Impact
Normal

Event Timeline

Patrick created this task.Apr 13 2017, 11:26 AM

I'm not sure about sdwdate-gui details, but could it be started in a mode without tray icon and only show notifications? Maybe also make sure that notifications do not expire until sdwdate succeed. Or maybe hide tray icon when time is synchronized?
Those should be much easier to do than full T534.

I forgot about one option.

  1. Accepting that there will be X tray icons for X number of

Whonix-Workstation VMs until T534 gets implemented. For example:

  • a) sys-whonix + anon-whonix -> 2 sdwdate-gui systrays; or another example
  • b) sys-whonix + anon-web + anon-mail + anon-chat -> 4 sdwdate-gui systrays

What do you think about option 4)?

marmarek (Marek Marczykowski-Górecki):

I'm not sure about sdwdate-gui details,

Code wise at the moment it's rather simple. Below 200 lines of python3 code.

https://github.com/Whonix/sdwdate-gui/blob/master/usr/lib/python3/dist-packages/sdwdate_gui/sdwdate_gui.py

but could it be started in a
mode without tray icon and only show notifications?

Let's call this option 5).

Perhaps. Still too much work.

  • Not having notifications that never be closed. (Just now got one with

notify-send --expire-time=0 test where the X button does nothing.)

  • Close the no longer needed notifications.
  • Have a concept of persistent-because-in-progress types of

notifications vs short-lived-notifications-on-success. (At the moment,
sdwdate-gui is rather simple. It shows whatever sdwdate wrote into a
file and file changes to that.)

And I speculate Joanna would hate to see a user auto starting like 4
Whonix VMs and then 4 persistent notifications that don't go away let's
say for example in case of network issues.

I guess usability wise 5) could be worse than 4)?

What about hiding sdwdate-gui icon when time is synchronized? So, have an icon only when there is some problem or sdwdate is still bootstrapping? This isn't ideal as actions like restart/stop will be unavailable, but maybe good enough for now?

Another issue at the moment with sdwdate-gui in Qubes is, that users
cannot really know which sdwdate-gui belong to which VM. The coloring of
the sys-tray works, but you could not distinguish them if both used the
same color.

That's more of a general Qubes issue. Should I try to work around it by
adding the Qubes VM name to the sdwdate-gui right click menu?

Same is true for the hover over passive tooltips. Should I add the Qubes
VM name there as well?

marmarek (Marek Marczykowski-Górecki):

marmarek added a comment.
What about hiding sdwdate-gui icon when time is synchronized? So,
have an icon only when there is some problem or sdwdate is still
bootstrapping? This isn't ideal as actions like restart/stop will be
unavailable, but maybe good enough for now?

Let's see.

  • a) a mode where sdwdate-gui terminates itself or shows no systray

after time synchronization is done

  • b) another mode where sdwdate-gui works normally
  • or just deprecate mode b)?
  • sdwdate-gui would need a concept of "timesync done". At the moment

it's just reading from a file that sdwdate maintains.

May also seem a bit strange, systrays that come and vanishes? After
booting a VM, it shows a yellow systray, which is gone after a while? Do
you think that is usability wise still better than multiple persistent
systrays?

In T658#12969, @Patrick wrote:

Another issue at the moment with sdwdate-gui in Qubes is, that users
cannot really know which sdwdate-gui belong to which VM. The coloring of
the sys-tray works, but you could not distinguish them if both used the
same color.
That's more of a general Qubes issue. Should I try to work around it by
adding the Qubes VM name to the sdwdate-gui right click menu?
Same is true for the hover over passive tooltips. Should I add the Qubes
VM name there as well?

This is indeed valid issue. In general case adding VM name inside tooltip isn't good, because VM can spoof it. But since we don't have anything better now (there is very little space around tray icons), IMO it would be ok here.

  • sdwdate-gui would need a concept of "timesync done". At the moment

it's just reading from a file that sdwdate maintains.

Existence of /var/run/sdwdate/success?

Indeed this may be a bit strange, but not so unusual - for example some graphical package managers shows an icon only when updates are pending. Yes, IMO it would be better than multiple persistent systrays - if for nothing else, for saving space in notification area. I'd add it as a separate mode, and deprecate it after implementing proper solution (T534).

What about having a single sdwdate for all Qubes which will add/substract some random skew for each VM?

What about having a single sdwdate for all Qubes which will add/substract some random skew for each VM?

I'd like that, however the design for that is not done. The implications on anonymity may prevent advise against that. Recently raised here:
T387#12552

With the recent work on the time sources the results would be very close to NTP accuracy and setting offsets to no more than 1 or 2 seconds, I think it is not such a bad idea to have just a single sdwdate

anonymous1 (anonymous1):

With the recent work on the time sources the results would be very
close to NTP accuracy and setting offsets to no more than 1 or 2
seconds, I think it is not such a bad idea to have just a single
sdwdate

This seems very risky. Once by chance two servers are off too much, it
would mess up all VMs.

anonymous1 added a comment.EditedMay 3 2017, 3:12 AM

I think we can ignore the results when three of them are not very close. It should still be more efficient than multiple instances.

In this case all three sources would need to be off to similar degree to mess up VMs

Whonix Whonix 14 let's go with:

  1. disable this new feature in Qubes-Whonix [1]

(Until T534 is implemented.)

"Solution": for now, not enabling timesync fail closed neither in Qubes-Whonix nor Non-Qubes-Whonix since neither T636 nor T534 were finished in time.

Patrick closed this task as Invalid.Dec 2 2017, 8:27 PM
Patrick claimed this task.