Hacker News new | ask | show | jobs
by amelius 2754 days ago
> This is also why I consider those "privacy containers" broken by design. They just operate on cookies and don't contain anything besides cookies. I would even consider them harmful because of their misleading nature.

Privacy containers could do more interesting things like:

- Connect through a VPN/proxy, so IP address changes all the time.

- Change browser characteristics (screen size, available fonts, user agent string, etc) to fool the fingerprint. I suppose that fingerprints are hashes, so you only have to corrupt one ingredient of the hash to make the fingerprint unusable.

Tor browsers do stuff like this.

3 comments

Fingerprints are not necessarily hashes, they can also be done as a collection of datapoints that combine into a probability. Here is a POC of this type of technique:

https://github.com/gulkily/browserfp

The EFF has a working one that tells you the uniqueness of your browser and how it got that score: https://panopticlick.eff.org/
"Change browser characteristics ... to fool the fingerprint."

What about hardcoding the fingerprint? So that every end user looks the same.

This doesn't deserve to be downvoted. The quickest way to combat fingerprinting is to hide in the crowd, which has value without requiring buy-in from other users; randomization as fingerprint deterrence only works once you have a critical mass of people using it.
Or if you actually randomise it, meaning "different output every time it's accessed", not "randomly set once, now it's hardcoded until you close the browser".
This is what Tor does, I believe. The problem with spoofing the fingerprint is that all the features that allow you to be fingerprinted are features that are in use by some site or another, so it would break compatibility.
Ya. I suppose you're right.

So long as the client runtime can inspect the host, inferring the fingerprint, and call back to the mothership, there's no foolproof, durable way to defeat fingerprinting.

At best, fudging the fingerprint just buys some time in the arms race.

The problem is that a 'browser fingerprint' is not some function call that can have its result be spoofed. There isn't even a single specification for what constitutes a browser 'fingerprint'

It is simply a series of attributes that are tested and compiled. Attributes that are consistent for a single browser but have some degree of variation between different computers.

Put enough of those together and you can uniquely identify someone. The exact things that are checked, however, will vary between implementations, and can always be changed in the future, so there isn't an easy way to spoof all of them to be identical.

In addition, many of these attributes that are tested need to return accurate results for normal functionality to work, so you are again limited in what you can fudge to avoid fingerprinting.

Much of the detail is irrelevant, though. There are things like languages I never use, and sofware version point-revision.
That's not a problem. Make those things normally untestable, and sites will by definition work normally without accurate information about those attributes.
A bit more than just cookies, though the other stuff is not quite as relevant. https://wiki.mozilla.org/Security/Contextual_Identity_Projec...