Beating 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…

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.


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.

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.


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. :slight_smile:

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.


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.


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.

file:///etc/machine-id in the indivdual qube, NOT dom0, right?