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
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.
1 Like
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.
2 Likes
1 Like
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