I’d be curious to know: Why doesn’t a qube A delegate the job to check for updates to its parent template A_TPL? By that I mean template qube A_TPL itself would be started for update checks, e.g. by via qrexec mechanism triggered from A and coordinated by dom0. This has two advantages in my view:
- Automatic update checks now can work for templates of offline qubes (without netVM). Currently I need to manually do update checks for those qubes without internet access.
- It would be easy to switch all
dnf/apttraffic - update requests and update downloads - to Tor network, because templates are responsible. Templates don’t have a netVM, hence use the update proxy. And this proxy can be globally changed by Qubes Global Config → Updates → Update proxy → Default update proxy. So to re-route all update traffic to Tor, you simply can change this value tosys-whonix. - Mental model gets easier. Every package update indirectly flows through update proxy.
But you are still constantly telling ISP and others over clearnet, that you are using Qubes OS, by polling for automatic updates e.g. on domain deb.qubes-os.org, for every started qube. I think, it would be useful to have the ability to hide this fact and not expose more information than needed, while still using automatic update checks.
I’d like to emphasize that I have a quite boring threat model. But my impression is, that you might be suspected by authorities solely due the fact that you are using Qubes OS. Of course this is dependent on the location/country.