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.
exit menu entry missing
That is on purpose. It was left for testing or debugging. The question is, once sdwdate-gui is thoroughly debugged, do we still want it? It is just commented.in the code.
left click does no longer show popup?
It does, on the second left click, or randomly on the first one, for an obscure reason seemingly created in KDE5, one among other annoying issues.
starts with Unexpected error: <class 'NameError'> but otherwise working
I could not reproduce this one.
The call is done in lines 186 and 215. update_tip('_caller_') runs show_message('_caller_'), which then runs run_popup('_caller_'), under conditions.
This code could be simplified, but I remember trying a couple of times, without much success.
I’d like to say that when installing sdwdate with --no-install-recommends (I don’t like the KDE dependencies) the python3.stem module doesn’t get installed and borks everything. Maybe that should be a required package?