Other than IP address, what kind of fingerprints carry over from Qube to Qube? And how do you best mask/subvert any device fingerprinting?
What do you mean by Qube to Qube?
Iām mean setting up a different qube, accessing a web service thru another qube. What could the web service use to fingerprint each qube as the same device?
web browsers have many settings that could fingerprint you as āuniqueā
if you want to secure firefox, i would study the configs here: GitHub - arkenfox/user.js: Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
but even with that, there are too many ways to tie different firefox vms to the same os because of the attack surface of web browsers. best you can do is āhopeā the website you are visiting isnāt using every trick in the book to fingerprint.
but in general, screen res, language, time, timezone, etcā¦
depends
1 Like
Are you asking about browser fingerprinting when you visit sites?
Or about networking in general for example ssh?
Or about cases when a few of your qubes will be compromised and attacker can look for info in your qubes shell and see if the compromised qubes run on the same machine?
1 Like
Iām not sure where the fingerprinting is happening.
If I want to mask the hardware footprints, are there any spoofing tools I can use?
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.
2 Likes
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.
3 Likes
1 Like
Any good sites for temp phone numbers for beating the phone regs?
A user suggested these two in another thread. Havenāt tried them personally.
1 Like
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.
1 Like
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.