The passive tooltip (popup) is broken in latest Whonix-Gateway VirtualBox (KDE) (not yet uploaded) build. I mean these tooltips as seen in this screenshot:
(It’s probably also broken in the currently uploaded developers-only build?)
Previously it was broken because the package sni-qt was not installed. Not installed this time either. However, installation of sni-qt did not fix this issue.
In a VBox fresh install (Debian 9, VBox 5.2.6, Whonix 14.0.0.6.6).
When hovering on the sdwdate-gui icon, the KDE default information shows (pops), like for any other systray icon. No tooltip.
Can you try:
Restart sdwdate from the menu, hover again quickly on the icon and stay there. The tooltip will show on the next status change, without the status however (Time Synchronisation Monitor with a blank line below).
I believe this is an issue with KDE. In Qubes, when starting sdwdate-gui for each anon-vm separately (same script as in VirtualBox/KVM), the tooltip shows as intended.
Restart sdwdate from the menu, hover again quickly on the icon and stay there. The tooltip will show on the next status change, without the status however (Time Synchronisation Monitor with a blank line below).
All true.
I believe this is an issue with KDE. In Qubes, when starting sdwdate-gui for each anon-vm separately (same script as in VirtualBox/KVM), the tooltip shows as intended.
2018-06-28 01:37:21 - sdwdate - WARNING - Maximum allowed number of failures reached in pool 1 (6 of 18). Giving up.
If the problem occurs too frequently, please report it.
Sleeping for 13 minutes.
Do you see the case for waiting randomized minutes and nanoseconds to improve anonymity (to avoid being detected as Whonix / sdwdate users) by avoiding predictable traffic between sdwdate time fetches?
On success sdwdate is currently waiting randomly between 60 and 180 minutes. (Plus always randomized nanoseconds.)
On error (even at first boot!) sdwdate is currently waiting between 5 and 15 minutes.
What about not waiting at all in case of error? Consequences:
possibly continuous traffic to onion time sources
predictable traffic?
sdwdate log size ever increasing (but could find a solution maybe)
Maybe on error wait between 0 and 10 seconds? Or between 5 and 15 seconds? Or between 5 and 60 seconds? Or…?
No - as network observers outside Tor are not in a position to perform traffic analysis at this level and if you have a malicious guard you are vulnerable to a lot more attacks than them knowing you use Whonix.
I’m in favor of eliminating the delays and making it perform the checks immediately to improve response time especially with the blocking until sync feature.
No - as network observers outside Tor are not in a position to perform traffic analysis at this level and if you have a malicious guard you are vulnerable to a lot more attacks than them knowing you use Whonix.
Imagine an idle Whonix-Gateway. Not issuing any traffic. But predictable
every “33” minutes it issues traffic. Since Tor does not use any
padding… That would at least be ground for suspicion that
Whonix/sdwdate is in use?
I’m in favor of eliminating the delays and making it perform the checks immediately to improve response time especially with the blocking until sync feature.
How many retries? Infinite retries? Perhaps increased waiting time with
ever failed attempt to save traffic?
(Until some maximum waiting retry time is reached. Meaning, wait maximum
5-10 minutes before next attempt or so after 10 failed attempts.)
Tor cells are fixed size so completely opaque to an outside observer. Tor has recently gained padding inside the network but its a multi-part project and some parts of the implementation are being worked out. There is always some form of communication between the client and relays even when idle - whether closing circuits or switching. There is no reason to worry about it being a problem.
Three successive retry attempts before checking at the next time interval that its currently programmed to do - so as to not overload the network or use up resources.
Sorry for the delay in reviewing this. python isn’t my strong skill and this is quite difficult stuff for me. I am finally on it now though
sdwdate_gui.py
It changes from ## Copyright (C) 2015 - 2018 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>
to ## Copyright (C) 2015 - 2017 Patrick Schleizer <adrelanos@riseup.net>
so I wonder if it was based on an older revision?
Wondering if some of the smaller bug fixes I introduced got lost in the process?
I was hoping to introduce this in Whonix as soon as possible but due to missing dom0 policy files it will be postponed 10-14 days I expect until it reaches Whonix stable-proposed-updates.
Until then we can’t start sdwdate-gui-qubes by default since the dom0 qrexec prompt would confuse too many users.