The software versions would be the same, but the exact files inside VM would be very different, could this be used to fingerprint users? File timestamp could also be used to track different users.
Or is it a better idea to always start with latest VM images and boot into VM live mode, then upgrade system? This won’t work if system need to be restarted to upgrade though.
No. Boot as few times without fully upgraded system as possible. Some vulnerabilities such as APT (past and hypothetical future) should be fixed as soon as possible. The system shouldn’t be non-upgraded, vulnerable and do actions which expose the vulerability to the internet (such as upgrading using known vulnerable APT).
Thanks, most of my concerns are mentioned on that wiki page.
Would more frequent VM images releases mitigate part of them? We would be more unified than upgrading OS inside VM.
Hardware info leaks are harder to prevent though, and will probably require upstreams. Paranoids would have to assume they are fingerprinted unless they use different hardware or/and use exclusively FOSS inside VMs. And in the era of ever haunting spectre, it might even be necessary to pause other VMs when doing sensitive computing.
Ideally every single file inside the VM should be identical to other user’s, to prevent fingerprinting.This can be probably guaranteed by using only vanilla unmodified VM images.
The released VM image is stateless (or stateful with the same identify), it then became stateful after system upgrade (more unique fingerprint).
Is there any post upgrade script to reduce artifacts introduced by upgrading? Like remove old kernels, old configs, logs, caches?
No.
Essentially I’m talking about creating new fingerprints.
If I have to run a privacy invasive program, it’s better to begin with a VM image from Whonix or Debian Live, not my (up-to-date) Whonix workstation or Debian qcow2.
If somehow a website in Tor Browser is able to list all/some files inside VM via JS, then that website can link all the activities done from that VM image.
So it might be a good practice to restart from released VM images and update (creating new unique fingerprints), rather than keep using a months old qcow2 (reusing old fingerprint). In this regard, I thought more frequent VM image releases is beneficial.
How frequent? Builds take time. Are you willing to sponsor such an effort?
Monthly should be enough I think, as long as standard apt upgrade method won’t download a few hundred megabytes.
I found ova image release about once per month, while libvirt image takes much longer. Is building QEMU images so much harder? I can surely donate some computing power monthly, how much does it cost to build a QEMU image?
It’s been quite some time since 15.0.1.7.2 KVM was released, so lots of updates accumulated. Time to prepare a new KVM image? Does this process take much effort?
All ports’ release cycles are synced, meaning a new one will be made whenever the next VBox stable point release is ready.
Yes, a whole day is dedicated to building, testing and uploading both Whonix and Kicksecure images. In the future Whonix Host, Kicksecure Host and ARM64 ports will be added to that list.
I can see a new point release for KVM is near.
I used to reuse existing VMs by just replacing old .qcow2 with new ones, but isn’t the non-deterministic mac address a concern? What’s the reason that the XMLs do not specify the MAC addresses?
I’d also create a new VM (non-Qubes) with an official image, if I plan to install something privacy intrusive. Does it help a bit (any better than installing them with guest live mode)? Does it make sense to start from Whonix package (Qubes) and upgrade, rather than creating AppVM from TemplateVM, in terms of reducing fingerprinting?
It’s already here. you can directly grab it here. The links on the wiki download page needs to be sorted out:
MAC address:
Privacy intrusive can be approximately equated with compromised for this consideration. See:
Footnote 17 and 18 explained, footnote 16 needs to be updated since ifconfig is being deprecated (ip a | grep ether seems enough).
Since simultaneous multi workstations and proprietary software should be discouraged, it could be better to include a shared MAC address in QEMU XMLs. So “advanced” users who wish to use simultaneous multi workstations or proprietary software would need to do some research and be warned.
Would shared MAC address be better for most users who just use Tor Browser in Whonix Workstation? I don’t know, but I’d change my guest MAC addresses regularly.
Add. Since IP is already hardcoded inside Whonix Workstation, I find not hardcoding MAC address a bit odd now.
Not sure can be called discouraged. Threat model specific. Situation is documented here and user can decide:
Tor Browser doesn’t leak MAC.
Privacy intrusive software / malware can detect MAC but having a shared one wouldn’t help because of VM Fingerprinting.
Shared MAC would result in:
Zoom correlate different Whonix-Workstation running on different notebooks? Even if I install Whonix on another notebook with another internet connection I am still being correlated!” This happened similarly in Possible tracking of DVMs · Issue #5764 · QubesOS/qubes-issues · GitHub.You can’t use the same MAC for multiple VM, this would interfere with networking. VM identifiers are uniquely generated during the cloning process.