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

But it's not just a matter of "open"/"close". It's more like signal/noise. Much of the signal is legit: source IP is needed to deliver response, screen resolution, audio/video codec support, transfer protocol, cache headers are all needed to render the page correctly and as quick as possible.

Unfortunately, much of that signal persists across sessions as well as websites and can therefore be aggregated into a hash that works as a "super cookie". The signal is based on the device, the connection, not so much the HTTP/HTML you're looking at.

The best approach to mitigate is therefore: adding noise: add random gibberish to User-Agent, tunnel IP though VPN/NAT, lie about codecs or screen resolution.

While that degrades user experience, it give no guarantees to actually preventing fingerprinting. So, the good news, if that fingerprinting is hard too, and doesn't work as well as is usually claimed!



Randomization works if you opt in everyone without their consent. If your addon or minority browser randomizes data you're adding a signal.


Yes, but that's a poor signal. If only two users add "enough" noise to their signal, fingerprinting will only be able to proof a user added noise, but not which user did so. For a single site doing the fingerprinting.

Compare that to tracking users across multiple sites for proper signal without randomization.


Yeah but if it's opt-in for privacy concerned users there may well be two users in the world with identical basic metadata (browser version, platform, etc) who have this enabled. And telling you it was one of two users but not which is pretty shite anonymization.

Regardless it's still adding an extra bit of information leaked, so you may as well forge a common value rather than make something new up.




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

Search: