boot clock randomization can indeed use some more discussion and scrutiny. Here is what it's about...
(Trying to speak more generally, less Qubes specific here.)
Assumption: Lots of users are either
- a) using NTP and have usually correct quite precise clocks
- b) using NTP and currently having a slow or fast clock about 1, 2, ... etc. seconds
- c) some have buggy setups and clocks that are far off
There are various local clock leaks. We try/recommend to prevent all of them, but it's impossible to be sure we are aware of all of them.
Before sdwdate finished setting the clock after boot to unlink it from the host [in Qubes terms: from sys-net and other non-Tor VMs] or in case sdwdate fails, there is at least bootclockrandomization to archive that. [The long term is to block all networking but sdwdate until sdwdate is done, but it takes a while until we get there. -> sdwdate-gui) [and for sdwdate fetches itself it is desireable to at least have bootclockrandomization just in case]
In the wiki the only rationale explanation currently is the following.
Using Boot Clock Randomization, i.e. after boot, the clock is set randomly between 5 and 180 seconds into the past or future. This is useful to enforce the design goal, that the host clock and Whonix-Workstation clock should always slightly differ. It's also useful to obfuscate the clock when sdwdate itself is running, because naturally at this time, sdwdate hasn't finished.
- Unlinking is the keyword.
- It's sane to assume that a non-torified host or other VMs may leak the local clock. (local clock leaks)
- It's also sane to assume, that a Whonix VM may leak the local clock. (local clock leaks)
- It's purpose is to prevent correlation / anonymity set reduction by comparing a local clock leak from let's say for example iceweasel in a non-Tor VM and a local clock leak from let's say iceweasel from within a Whonix VM.
Now, how big is group a), b) and c)? It's impossible to say. I am not aware of any research of that and we neither have the resources to do that research.
Let's assume only 10% of users have a clock that is 4 seconds slow. If boot clock randomization added only +1, it seems to me the anonymity set reduction may still work. Or if it randomly picked 0, it would not help at all.
However, it's right, there is a point. For users using Whonix VMs and doing stuff suffering from some local clock leak, we may indeed add some of the group a) users "with a perfectly synced clock" to an artificial "unnecessarily" fingerprintable attribute that otherwise would not exist. On other other hand, users of group b) and c) would be better off. And since it's public knowledge, that Whonix uses bootclockrandomization and sdwdate, all Whonix users can blend into the group of Whonix users. Thereby gain anonymity. And by the obfuscation of local clock state is leaked from within the VM, hopefully such clock correlation attacks become unattractive.
While I am at it... What is sdwdate good for then... Mostly useful for users of group b) and c), it sets the clock to a time that is as securely obtained and as correct as it can get. While still being independent from the host and other non-Tor VMs. And keeps it that way during long running sessions. The time set by sdwdate should then be similar enough for all Whonix users to make clock correlation attacks unattractive.
In an ideal world, we would require neither boot clock randomization nor sdwdate. The host would always boot would a perfectly synchronization time to begin with. And everyone would always have a perfectly synchronized time always. And online time syncing would be impossible to manipulate with by man-in-the-middle attacks.
For example if attacker have already some selected set of data to
correlate (like "all Tor users in area X"), he/she can easily further
narrow the search by eliminating those with time almost in sync
Note, that this +/-5sec (emitted from within Whonix VMs) should only be observable at Tor exit relays, destination websites and onion servers. Not at ISP level. (ISP might observe local clock leaks by the host or other non-Tor VMs.)