Or the information provided by JS regarding the local machine should be reduced
This would however have the downside of incurring an additional latency with an additional abstraction, but if there was a way you turn this off with trusted websites and only leave it on when you're using a site you don't trust it could be more usable? It just seems better than disabling JS entirely since a lot of websites just completely break without JS.
It just seems like with the amount of information that JS can collect, even if you're using TOR or a VPN, if you crunch all the information about a particular user, like the kind of OS they're running, the version of the browser, the screen ratio, mouse click movements, time of access, number of CPU cores, type of GPU, whether or not it's a VM, etc., it just feels like you might be able to devise a pretty reasonable heuristic for where this person is and the kind of computer they're using. I can't really say I know the extent of browser and JS capabilities, but these things already seem alarming enough where I wouldn't really feel super confident that I can't be tracked even with TOR or a VPN.
Edit: Just discovered something similar to this is being worked on already! https://gpuweb.github.io/gpuweb/#malicious-use
You should have enough ropes to hang yourself, and also a few more just in case.
Eh, it seems to me that software ought to be cooperative by default. Plenty of programs will detect whether you have AMD or nVidia graphics and optimize itself for your hardware—why not VMWare graphics?
Where I agree is that there ought to be an easy checkbox to hide it.
It feels like something that needs to be asked permission for, however, so it can’t be used for nefarious purposes.
If a website ever really needs to know my hardware, it can ask me to choose from a drop-down. A lot of users won't know what hardware they have—but, those users are also unlikely to understand the implications of a hardware-detection permission prompt.
Firefox removed the battery API for this. In theory you could do something like show a stripped down site for low power users or something but it was only ever used for tracking.
While browsers have been used for a lot now, gaming seems like the one place we have seen virtually no use outside of random 2D games. I doubt there is a single web game that actually makes useful use of the gpu vendor details.
“What is hardware?”
“Should I let a game know my hardware? Should I let a news website know my hardware?”
Makes sense to me. There are a lot of legitimate reasons software on your computer might need to know it's in a VM or what the limits of your VR engine are.
Does the VM claim it's network driver was manufactured by Broadcom, or does it go with Cambridge Silicon Radio? Or does it decline to provide a vendor, and if it does, how long until software starts assuming that is the sign of a VM, except this time with potential false positives for users of niche hardware?
It would simply be whatever the virtual NIC is. Intel ones seem to be pretty common, likely due to wide availability of drivers and documentation.
VMs wouldn't achieve the performance they do without paravirtualization. VMs don't meticulously emulate all attached virtual devices. Paravirtualized device drivers more or less forward the I/O request to the hypervisor which handles it in a VM-specific way. For example, it's not super useful for a VM to emulate all the bitwise register-twiddling dances needed to talk to a SATA controller, it can simply have some "backdoor" channel into the hypervisor that says "Queue request to write X to LBA Y for this VM".
Since paravirtualization requires specific drivers, it will always be detected.
- Do network adapter MAC vendor ID's make sense?
- Does the hard drive size make sense?
- Which 3D acceleration features are supported/work correctly?
- How much graphics RAM is there?
- Timing-based methods
It's a bit like detecting private/incognito mode in a browser. Everything worked great, until websites realised there are ways to detect it, then became a game of cat and mouse.
>- Does the hard drive size make sense?
not detectable through browser APIs
>- Which 3D acceleration features are supported/work correctly?
vmware workstation has 3d acceleration support targeting directx 11, so I'd imagine most features are supported and are passed through to the host gpu for execution. I doubt you'll able to detect is a vm or not based on that. In addition, resistfingerprinting (on firefox) hides this kind of stuff.
>- How much graphics RAM is there?
vmware workstation has vram selectable from 32MB all the way to 8GB, so that covers the entire range of plausible vram sizes.
>- Timing-based methods
what else can you test that is both accessible via browser api and would yield big differences between a vm and a slow computer?
>It's a bit like detecting private/incognito mode in a browser. Everything worked great, until websites realised there are ways to detect it, then became a game of cat and mouse.
not really, it's a solved problem: make a new browser profile and then delete it after you're done. I've seen a few HN commenters post their (relatively short) scripts to make a new firefox/chromium, start it, and then automatically delete it once it exits.
Why? I mean, it's possible to make a VM that's indistinguishable (except for speed), but what's the purpose of doing so?
Most people who run VMs have the purpose of "I want this application to run more conveniently than having dedicated hardware for it." For that purpose, it's useful to provide abstractions (e.g., providing dedicated access to CPUs in a way normal kernels usually don't) and usually to provide sandboxing (e.g., prohibiting disk writes outside of the VM disk), but there's generally little point in lying, unless the software you want to run won't run right without lying. And it's often counterproductive to lie, because software can adapt to the ways the abstraction is leaky if you're truthful about the nature of the abstraction. (In this case, the VMware graphics driver can achieve much better performance by cooperating with the host than a normal graphics driver expecting physical hardware could get on a software emulation of that hardware.)
It's also often pointless to lie - if you pay for a VM from Amazon EC2, and you log into it and it pretends to be a 1U physical server, are you going to believe it?
The obvious case people will think about is the security angle (by using a vm you to impersonate a consumer end user, so for eaxmple malware doesn't realize it's running in a vm). But there are other cases where murphy's law will bite you.
For example I bet some WebGL apps manage to trip themselves up over this feature string because of whitelists or buggy logic in code that tries to be clever about used features vs underlying platform.
Wouldn't every Qubes VM (whatever the underlying physical machine) return the same fingerprint? Something like VM Fedora version XXX running on Xen hypervisor.
I believe there are patches that can close those holes, but I've always found the fact that such information is exposed by default and can thus make a VM obviously not look more like real hardware is puzzling. Ideally, a VM should be indistinguishable from real hardware, and in practice that ideal is difficult to achieve --- especially with timing-based detections --- but you'd think such obvious signs wouldn't appear.
Also, the amount of information that can be gathered via JS is disturbingly immense. To me, this is just further validation of the fact that JS needs to be off by default and whitelisted only for the (very few) sites that one truly trusts.