Qubes-Whonix 14 timesync vs usabilty decision

[phabricator-migrator]

Information

ID: 658
PHID: PHID-TASK-y6rvemug5ajhjxdlc3wb
Author: Patrick
Status at Migration Time: invalid
Priority at Migration Time: Normal

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.

Comments

---

marmarek

2017-04-13 12:53:33 UTC

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.

---

Patrick

2017-04-13 13:42:36 UTC

I forgot about one option.

4. 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.

sdwdate-gui/usr/lib/python3/dist-packages/sdwdate_gui/sdwdate_gui.py at master · Kicksecure/sdwdate-gui · GitHub

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)?

---

marmarek

2017-04-13 13:57:40 UTC

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?

---

Patrick

2017-04-13 17:39:21 UTC

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?

---

marmarek

2017-04-14 18:09:03 UTC

! 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).

---

anonymous1

2017-04-16 12:09:05 UTC

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

---

Patrick

2017-04-16 16:26:03 UTC

! In T658#12975, @anonymous1 wrote:
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

---

anonymous1

2017-04-16 17:32:34 UTC

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

---

Patrick

2017-04-27 18:04:22 UTC

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

2017-05-03 01:19:46 UTC

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

---

Patrick

2017-07-23 16:03:33 UTC

Whonix #Whonix_14 let’s go with:

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

(Until T534 is implemented.)

---

Patrick

2017-12-02 19:26:35 UTC

“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.