Assuming a browser escape (a lot, but humor me), one concern I’ve pondered is that from day 1 of installation, template root volumes begin to diverge across the user base as portions of the root filesystem become a de facto “local cookie” for any bad process that can query the filesystem and communicate to a CNC server.
This could lead to correlation of different personas that utilize the same template in different VMs either at the same time or on staggered order.
Contents of root such as logging, date/time stamps of updated components, etc. do differ across qubes users BUT remain the same across all VMs that utilize that template for that qubes user.
Not only is that data comparable across running VMs if only certain portions of it change on updates/etc., the filesystem data may also be a long term local indicator across many reboot of the same or other VMs.
As it is now, as part of each template installation, the templates are booted to pull the app list into the dom0 menu system.
Therefore at that first template shutdown your template root volume content is now unique across the entire user base.
It’d be nice to have a “frozen-at-download” template that sees its first boot every time it is used as a (disposable?) VM and which also cannot be started directly. Updates would only be possible via reinstallation of the template from a recent built rpm. Customization would not be allowed. App list would be provided to dom0 via another method. Perhaps standard/security updates would be provided using delta RPMs or similar.
B