It was mentioned in this topic:
But it’s not an absolute solution.
It’ll require to disable passwordless root for your AppVM template.
And if attacker has a way to elevate privileges to root inside AppVM then he’ll still know your hardware info including its serial numbers.
Well, one has to start somewhere.
An attacker that has a way to elevate privileges to root, can do all sorts of things besides knowing hardware info, and, as you suggested, at that point it won’t make much difference whether it’s being hidden or not,
That doesn’t mean that we shouldn’t try to lock down sensitive vms just because someone might be able to gain root privileges.
Then again, this is just my 0.02$
I Use disposables and only disposables. In fact I remove all browsers install in any domain except the few I keep offline,have no network access… *vault" if I need to view saved website that is saved in a “offline” domain,open in disposable.
Bookmarks are NEVER kept in any browser. Only in a notepad,in a “offline” domain. If I need to I either type website OR “copy/paste” from notepad to disposable Firefox,Tor browser…
All saved pdf’s from downloading are converted to “TRUSTED” then moved to “offline” domain.
Same with images,pictures or videos… offline domain.
Besides disposable vm’s you can also do the same with “docker” images, if you are skilled enough to build,it’s not that hard.
Any good sites for temp phone numbers for beating the phone regs?
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
For starters, if this is a concern, you do have the option to flush, rotate, and vacuum journalctl logs as well as shred the contents of /var/log (in dom0 some dirs are required, in templates I haven’t had issues), which you could do once you’re done configuring the template, before shutting it down.
You also have the option to set logrotate.conf and journald.conf to your liking to automate that process…
I concur and I am already in the habit of doing so but…lack of logs is also a component of a fingerprint vs the rest of the user population that does not do so. 
Plus that still leaves file/directory date/time stamps (due to template update timing) and some other things as strong cross-VM or cross-time fingerprint indicators.
B
Just as an addendum to previous concerns in this thread.
One of the nice features in 4.2 (and 4.1 IIRC) is that you can use the Qubes Template Manager to easily either fully Reinstall a template or Replace the currently installed one with an updated version without too much fuss.
If you do this semi regularly, that does rotate template-side signatures out of view regularly as well.
B
But did you check how different such fingerprints are? In my experience, many things in the list stay the same.
I was speaking more broadly (not just browser fingerprinting) e.g., say, browser-exploit-that-allows-reading-the-filesystem fingerprinting.
Your Tor Browser can navigate successfully to file:///etc/machine-id and read its contents. All AppVMs inherit this file from the template (and DispVMs from the AppVMs too).
Additionally, everything user readable which the browser can read too, contains very identifying info about your system.
Enable JavaScript and you can be identified by the patterns of your mouse moves, by the speed and specific ways you press the keys on your keyboard, etc. That is slightly off-topic, because the question is about device fingerprinting, not about person fingerprinting, but I thought you it be interesting to consider too.
And how do you best mask/subvert any device fingerprinting?
That would probably become impossible with Web 3.0 and CBDC-related legislation.
This is the first time I might actually be able to contribute something to this forum.
I’ve been very concerned with this issue myself. Sounds like you’re either trying to hide the fact you’re using qubes, or simply trying to make your fingerprints as different as possbible between qubes. Since the fact is that this OS is heavily dependent on Firefox and specific versions of Fedora and Debian, I would imagine one way to get around this is to use separate OSes (and possibly browsers) that are not these, for each identity. Maybe use the community templates. Or better yet, use OSes that aren’t Qubes or community supported. I might recommend the more popular linux or BSD distros to blend into the crowd. Also, tweak the maximum ram’s slightly, in 2 or 4 GB increments so they aren’t the defaults.
Remember to use different net qubes for each of your identities so they all have separate IPs. and maybe try to have all of those net qubes go through a dependable VPN like ProtonVPN, iVPN or Mullvad, for example. Make sure to check your IP in each qube to know if you’ve acheived your desired goal.
Tor browser, with or without Tor and/or Mullvad browser are also great options for minimizing fingerprinting.
I’d be interested to know if there is any room for improvement upon this approach combined with kicksecure.
file:///etc/machine-id in the indivdual qube, NOT dom0, right?
Since the fact is that this OS is heavily dependent on Firefox
If that was true, the OS would be unable to run without Firefox, which is not the case.
OR better yet, use OSes that aren’t community supported.
Community support per se is not a negative factor in regards to fingerprinting.
Example: Windows is not community supported. Is it better?
I might recommend the more popular linux or BSD distros to blend into the crowd.
The biggest crowd is Android, not desktop Linux or BSD, but it doesn’t really matter, as it is impossible to have all other factors equal.
Remember to use different net qubes for each of your identities so they all have separate IPs.
If a device (user) has been fingerprinted, the IP address (which is not the same as IP) doesn’t really matter, as identification is possible regardless of it.
and maybe try to have all of those net qubes go through a dependable VPN like ProtonVPN, iVPN or Mullvad, for example.
This goes against the philosophy of Qubes OS (distrusting the infrastructure).
Speaking of which:
We may also collect information about how the Service is accessed and used (“Usage Data”). This Usage Data may include information such as your computer’s Internet Protocol address (e.g. IP address), browser type, browser version, the pages of our Service that you visit, the time and date of your visit, the time spent on those pages, unique device identifiers and other diagnostic data.
Consider that GDPR’s paragraph (32), (43), Article 6 item 1a, and Article 7 mandate the opposite, i.e. that they actually may not do this without your explicit, informed and separate consent for each of the various purposes listed further in “Use of Data”.
The point is: to reduce device fingerprinting, you should also consider how your most trusted parties process (and protect) your data.
file:///etc/machine-id in the indivdual qube, NOT dom0, right?
In all qubes based on the same template.
“Know your enemy”.
Random hiding from anyone will mostly get you in the trouble with everyone at some point, when it’s very or even most critical for you. Instead, establish your threat model carefully and you’ll be more closely to realizing your odds to hide.
For example, you want to hide from Google? You think you can do that? Great. I can’t. So, I’m not using it. And so on…
I’m much more of a practical application kind of guy and as such, I try not to get bogged down in correcting word usages that don’t align with precise terminology and instead was focusing on helping the OP with what they were trying to accomplish. I’m not saying there isn’t a very important place for such. I’m just saying this is how I do things and I’m pretty sure practical application is what the OP is looking for, not vocabulary.
“IP” is common parlance for IP address. Having two identities linked by IP (IP address) can very much be a first step in associating the two
The OP appears to be trying to prevent qubes being linked to one another by third parties, hence the advice I gave.
I’m very curious as to why you’re referencing website privacy policies to me in response to my post trying to answer another member’s question about preventing fingerprinting. Maybe you meant to post that in reply to the OP. Even then, the OP’s goal seems to be to avoid having to worry about what people do with his/her data by preventing that data from being linked to him/her in the first place. That’s generally one of the main goals in avoiding fingerprinting.
How?
Fingerprinting is a deep subject and deep subjects should not be approached superficially, i.e. they deserve the proper attention and accuracy, so that everything is clear to all parties. We are not (or at least I am not) closely familiar with the level of every person who may read this thread now or in future. In short - the clarifications are not aimed to bog you (or anyone else) down, so don’t worry because of a small non-personal side note.
The OP appears to be trying to prevent qubes being linked to one another by third parties, hence the advice I gave.
The OP does not mention parties at all.
I’m very curious as to why you’re referencing website privacy policies to me in response to my post trying to answer another member’s question about preventing fingerprinting.
I mostly use the forum through email. I reply to a certain message because there is no option “reply to the thread as a whole” (although the post shows up in the thread history too). So, technically, it may appear as a reply to your post but it may contain other feedback too.
Maybe you meant to post that in reply to the OP. Even then, the OP’s goal seems to be to avoid having to worry about what people do with his/her data by preventing that data from being linked to him/her in the first place. That’s generally one of the main goals in avoiding fingerprinting.
The OP (and the topic) is about device fingerprinting with further mention about hardware footprints. The text of the policy explains that the website may collect unique device identifiers, so that is directly related to OP’s explicitly written concern.
The OP says nothing about worries or linking identity to device, although I agree with you the two are often related. Sometimes they are not though.