Hacker News new | ask | show | jobs
by jocoda 538 days ago
We have kernel level anti cheat systems for games. So how about kernel level anti tracking?

Browsers use system calls to provide the information used for fingerprinting the device, so why not intercept these calls and lie. Have all users present an identical fingerprints and we're back to pre google times. Yes, we lose some important functionality, but maybe it's a price worth paying?

Never mind the other elephants in the room that do worse than track your browsing habits...

5 comments

I see this going in the opposite direction first - TPM-backed kernel level fingerprinting. Surely you have nothing to hide…
This page only works on digitally signed supported operating systems. Please consider migrating to a supported system by Microsoft, Apple or an Android device officially supported by Google.
This is my conspiracy theory as to why Win11 made TPMs mandatory hardware.
Fingerprinting or attestation?
Attestation of working fingerprinting.
If you're running your workload on someone else's hardware (eg in the cloud) being able to attest it's not being modified is critical. From a companies perspective, when they run their software in the context of a customers hardware, it makes sense that they may similarly wish to ensure the software is running unmodified. This is how games are able to ensure there is no cheating occuring and banks can ensure malware is not tampering with the bank software unbeknownst to their customer. There are obviously ways for this to be use this for more distasteful mechanisms like fingerprinting, but that's not necessarily enough reason to abandon the technology. There are ways to achieve attestation without compromising privacy, but it does require widespread rollout of the attestation mechanism.
The outcome will be that many sites simply refuse to work on any browser that does this. Users will blame the browser for not working and switch to one that is supported. Most people are happy to trade their privacy for convenience - especially since most people don't even realize they are doing it.
How would they know? The point of returning “standard” values, is that you are indistinguishable from any number of legitimate users.
They start blocking any fingerprint that looks like you're hiding it. Similar to sites blocking known Tor exit nodes and proxies.
The point is that the fingerprint looks like “the generic fingerprint”, blocking that would be pointless, because it’d block a massive number of completely valid users.
It doesn't have to be blocking fingerprint, just whatever garbage data that works and the cat/mouse game will continue as usual.
It's more complicated than that. You can use subtle differences in hardware and GPU rendering so that syscalls aren't even relevant. And you can never really prevent timing attacks, because you can just use a network request to get the current time from the server.

I've been wondering how hard it would be to make a completely fingerprint-proof browser.

One idea would be to run it in a deterministic emulator. All machine code instructions would be guaranteed to take exactly the same amount of time to execute on every machine, as far as is observable to the browser, and threads would be scheduled in the same order every time. Zero access to the host system through fonts, WebGL etc.

This would mean a massive performance penalty, but modern computers are fast enough that it might be usable for many sites. You could have a small number of discrete speed tiers, where you use the fastest tier that your computer is capable of.

I first read it as a joke, but come to think of it...this would be actually quite awesome for malware isolation and sandboxing. Giving software/apps different fake profiles that look like different identities on the filesystem would be quite the feature.

You would have to have some kind of launcher where you can select the isolated chroot/sandbox you want to run that specific program in.

Implementation-wise this could actually be done with eBPF, as most if not all syscalls can be intercepted and "farbled" (Brave's terminology) there. Features-wise this would probably be a separate filesystem for each program context, plus the things that firejail implements in userspace. Shared libraries would have to be loaded separately into memory, and glibc would have to be changed to not use any environment variables or debugging related function calls.

Welp, maybe docker+xorg is easier.

This is what the Tor Browser is designed to do, and it does it very well (all in userspace no less). The main drawback is that some sites don't render as nicely and occasionally a site simply doesn't work.
The most important anti-tracking feature Tor has other than IP masking is disabling JavaScript by default. That's a complete non-starter for the modern web.