Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In my test (umatrix, but no other preventions), the main sources of uniqueness were the fonts installed, the HTTP-ACCEPT header, and WebGL fingerprinting.

Especially the fonts installed was very interesting and I hadn't thought of that before. The JS just iterates over thousands of known fonts in a div/span and sees if the browser can render it to build a list. It's enough that you've installed a single uncommon font and together with everything else you suddenly became unique just by that.

You're not going to block all of these "dynamic" prints just by changing browser or installing a single plugin. Even if you run in a VM, unless you actually flush and reinstall that VM every session, you're eventually going to amass customizations inside the VM that can be fingerprinted.. :/



Forget webgl and fonts, content blockers also fail at blocking third-party analytics masquerading as first-party analytics. Exhibit A: https://gist.github.com/sperand-io/fc211731e31c628232abb998f...


GitHub requires logging in to view gists??


The problem is that the same font is rendered differently by different video cards, hence why your hardware can get fingerprinted.


I thought that most font rendering was still happening on CPU. Usually, characters are rather small, so the overhead of shipping the data to the GPU does not seem worth it.


Even with CPU rendering, there will be differences depending on the specific software libraries and system configuration, e.g. aliasing settings. Patches to one of the pieces of software doing rendering could create pixel level differences in rendered fonts that could be used to fingerprint.


Still, "latest Chrome on Windows 10 and an 1080p laptop screen with Intel Graphics" should be at least ... half of the users out there ?

Yet CoverYourTracks says that even my up to date Chrome User Agent is used by one in 223 browsers, which sounds hard to believe.


It's actually an interesting case study how "identical installs" often have minor config variations which produce a sort of chaos in the end result. Also, staggered downstream distribution of software updates doesn't help.

I haven't tested it much myself, but I suspect there's a lot to unpack here.


Wait, isn't font rendering client-side? Why would the server have to know how fonts are rendered on my end?


They render it to a canvas, webgl or similar, and read the pixel data using javascript.


That's correct, it's not that reliable, which is why these are paired with drawing some geometric shapes on the canvas as well.


How about a browser that has cookies etc. as different modules detachable/attachable from/to the actual _browsing session/s_, and an option to attach/detach them on the fly. I think I would get used to the overhead work involved when browsing, just like I got used to NoScript.


Looks like fonts are basically cookies with side effects (rendering characters).


windows 10 pro has "Windows Sandbox" which is a VM that runs windows 10 that is only ephemeral storage. Closing the VM and restarting it is 100% fresh again.

There's ways to do it with virtualbox and qemu as well by setting the disks to the same ephemeral style.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: