What else?

Default qubes.UpdatesProxy policy for TemplateVMs is using sys-net:
/etc/qubes/policy.d/90-default.policy

# HTTP proxy for downloading updates
# Upgrade all TemplateVMs through sys-whonix.
#qubes.UpdatesProxy     *    @type:TemplateVM        @default    allow target=sys-whonix
# Upgrade Whonix TemplateVMs through sys-whonix.
qubes.UpdatesProxy	*   @tag:whonix-updatevm    @default    allow target=sys-whonix
# Deny Whonix TemplateVMs using UpdatesProxy of any other VM.
qubes.UpdatesProxy	*   @tag:whonix-updatevm    @anyvm	deny
# Default rule for all TemplateVMs - direct the connection to sys-net
qubes.UpdatesProxy	*   @type:TemplateVM        @default    allow target=sys-net
qubes.UpdatesProxy	*   @anyvm                  @anyvm	deny

Also need to check dom0 update qube:
qubes-prefs updatevm

For users that desire advanced anonymity, there should be no clearnet traffic while performing activities via Tor that require privacy.

Does that apply to e.g. DHCP traffic? There isn’t much that can be done about that.

Otherwise, ensuring that nothing can talk to sys-net via qrexec and that all network traffic goes through sys-whonix should suffice.

Qubes network time synchronization running in sys-net

Wouldn't it cause a problem for some users if he select sys-whonix as a clockvm and user will have wrong RTC time from hwclock due to BIOS reset or some hardware RTC fault or user will boot in Windows and his RTC will be changed from UTC to local timezone?
sys-whonix won't be able to connect to Tor if you don't have accurate clock:
7/8/2015 6:49:43 AM.695 [WARN] Our clock is 1 hours, 10 minutes behind the time published in the consensus network status document (2015-07-08 08:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!
Maybe there's a need to make a notification of this warning for user so that he would pay attention to the problem with his system time and fix it manually.

For users that desire advanced anonymity, there should be no clearnet traffic while performing activities via Tor that require privacy.

Does that apply to e.g. DHCP traffic?

If the DHCP traffic:

• A) stay within the LAN, then there should be no issue, OK.
• B) leaks to the ISP, then that would be an issue, problem.

Since DHCP "usually" (afaik) does not leak to the internet / ISP and stays within the user's LAN, that should be OK.

But some ISPs are actually LAN based and then there would be DHCP leaking to the ISP. This isn't popular. But these users would be at a disadvantage.

Otherwise, ensuring that nothing can talk to sys-net via qrexec and that all network traffic goes through sys-whonix should suffice.

That's useful.

#1814 was an issue until a while ago but it's the kind of categories to look for. Or Qubes network time synchronization running in sys-net. The question is, if sys-firewall or sys-net generates any other clearnet traffic by itself.

Qubes network time synchronization running in sys-net

Wouldn't it cause a problem for some users if he select sys-whonix as a clockvm

That is:
https://phabricator.whonix.org/T387

sys-whonix won't be able to connect to Tor if you don't have accurate clock: 7/8/2015 6:49:43 AM.695 [WARN] Our clock is 1 hours, 10 minutes behind the time published in the consensus network status document (2015-07-08 08:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!

For a few releases now, sdwdate can fix slow clocks including very slow clocks (such as clock being set to year 1980). More details here:
https://www.whonix.org/wiki/Dev/TimeSync#Clock_Fixing

But this is getting off-topic here. Please open a separate discussion for sdwdate if required.

Maybe there's a need to make a notification of this warning for user so that he would pay attention to the problem with his system time and fix it manually.

That is:
https://www.kicksecure.com/wiki/Sdwdate-gui

I have had success by adding firewall rules to every non-Whonix VM that prevents outgoing traffic.

sudo nft add chain ip filter OUTPUT '{ policy drop; }'
sudo nft add rule ip filter OUTPUT oifname "lo" counter accept
sudo nft add rule ip filter OUTPUT counter drop

sudo nft add chain ip6 filter OUTPUT '{ policy drop; }'
sudo nft add rule ip6 filter OUTPUT oifname "lo" counter accept
sudo nft add rule ip6 filter OUTPUT counter drop

I have not seen any leaks when I apply these rules before connecting to any network.

Is there anything preventing this from being a temporary solution to this problem until the Qubes developers get around to examining it properly? It would be very easy to make a script that turns this on/off.

@feffiboujike Not that I can think of, though you can simplify things. In particular you can use inet instead of handling IPv4 and IPv6 separately, the counter drop can be omitted, and the rest can be handled in a single transaction.

For issue tracking purposes:
Please add the Whonix tag.

I am not sure how much this helps, tbh.

Tor does not protect against traffic confirmation attacks. It is still possible to correlate outgoing traffic from the user’s machine to traffic at a particular server and therefore determine if the user is connecting to that server. This attack cannot be prevented without either paying a large latency penalty (mixnets) or by sending a constant amount of traffic even if most of it is wasted.

That's a more difficult attack that requires a stronger adversary.

If this task was solved, then at least the mentioned omnipresent points of centralization could not mount this attack anymore.

A traffic confirmation attack is in a different category than than a user connected to $cdn_server both anonymously and non-anonymously that can witness that both connections stopped at the very same time.