Discussion: Disable whonix clock randomization?

[rocodes]

• I have searched for duplicates or related issues

Description

See freedomofpress/securedrop-workstation-ci#68, and freedomofpress/securedrop-workstation-ci#68 (comment)

Whonix clock randomization can be a source of failed updates and failed SDW provisioning. This is a discussion issue about whether we should disable it, and if so, for how many components. It's also worth bearing in mind that we should aim for a least-complexity/small-scoped-effort solution since we still have an eye on arti integration down the line.

To discuss:

• Understanding intended vs actual anti-fingerprinting benefits? see discussion https://forums.whonix.org/t/boot-clock-randomization-bootclockrandomization/2200/16
• if moving towards disabling: system-wide or just on sdw specific whonix stack? (Related: refactor sd-whonix provisioning from clone of whonix-gateway-XX template #1060)

How will this impact SecureDrop/SecureDrop Workstation users?

• Depends on implementation, see above. Benefits could range from from "fewer errors during preflight updater run" (if scoped to sd vms only) to "fewer errors during install/provisioning and updater run" (if systemwide). Downsides could be potentially intrusive managing of whonix components, which may be used for other non-SDW purposes, and potential loss of anti-fingerprinting mitigation for sdw vms or system vms (needs investigation).
• In general, journalists are not intended to be anonymous, but I think we should not adjust the default system whonix settings since that makes decisions about whonix config for potentially user-created VMs.

How would this affect the SecureDrop Workstation threat model?

• See above, needs investigation.

User Stories

• As a SDW user, I want reliable updates and provisioning with as few errors as possible.
• As a SDW/Qubes user ("power user"), I don't want SDW to make non-transparent changes to my system VMs/ I want to know what state my networking stack is in.