Firefox 28 restricts the enumeration of navigator.plugins[] to reduce the impact of plugin fingerprinting. A website can directly query navigator.plugins["Some Plugin Name"] to check for a plugin, but no website should need to enumerate all installed plugins just to look for one particular plugin. Unfortunately, many major websites do, so enumerating Firefox's navigator.plugins[] will reveal QuickTime, Adobe Flash Player, Adobe Shockwave Player, and Java to avoid breaking those websites.
I'd like to have more control over the Javascript runtime in the browser. Defeating this identification trick is only one of the reasons.
Suppose you had a list of options and could selectively disable, for example, monitoring of mouse movements on one site, or ajax on another. And for this in particular, something that would feed the site random values from a particular range for fonts installed, plugins installed, screen size and other such information.
Using that data in development would still work because 99% would keep the default "true" values, and the few geeks who would change them would get what they should/would expect on sites that rely on those values. But everyone should have the power to control what info they're giving out, and what Javascript is allowed to do on their own device.
They didn't use any JavaScript to get this information. Most of it is sent by your browser in the request headers, and the font detection used Flash and Java. They could have used JavaScript to detect fonts as a fall-back when Java and Flash are disabled, but it's relatively complicated to do so (requiring you to know the rendered width of a string for each font you're trying to detect), and it was not included in this example.
Sending incorrect information for Java or Flash fonts is an interesting idea, and likely would not affect user experience, as non-standard fonts are often served with the animations. Sending the wrong screen size might get you a mobile site served when you were wanting non-mobile or vice-versa. IP address and ISP are valuable bits of identifying information as well, and those are more difficult to address without using a proxy. But I would bet that randomizing your screen size for each request would break most fingerprinting code, since that would be assumed to be static.
Ah, good catch. I guess the JS navigator.plugins list is quite a bit more thorough than the plugin information sent in your request headers (which I believe is limited to Java: yes/no).
I'd like to have more control over my browser in general, and I think many here also share the same thought. The issue is that browser vendors seem to make it harder and harder to customise these sorts of things by removing configuration options etc. And requiring to install an extension/plugin to get this ability just makes it harder for the average user to become aware of and take control of this.
Forgive me if I'm wrong, but it looks like if you could install a system font on a computer then you could create a unique fingerprint for that computer that is detectable by any website?
I am uniquely identifiable out of the 3.7 million samples because of my system fonts.
Also the funny thing is you cannot be tracked by this, because whenever you install a new font, update a plugin, install a plugin etc, you change your unique data.
Their paper [1] mentions this, and suggests that ~37% of individuals who returned for repeat testing had differing fingerprints (they assessed this via a control cookie, placed by the site). Although this seems high, this was over the entire life of the experiment, with some users returning after weeks or months.
Importantly, we can assume that the fingerprint will change incrementally, and remain mostly constant (eg., upgrade plugin OR install new fonts, but probably not everything at once). Therefore, closely-spaced repeat visits could be algorithmically matched, even if the fingerprint changes. This could be especially effective when including other "unstable" (short term) information, such as IP or geolocation, something the authors did not attempt (because these are generally unstable).
From the paper (page 13):
"We ran our algorithm over the set of users whose cookies indicated that they
were returning to the site 1-2 hours or more after their first visit, and who now
had a divergent fingerprint. Excluding users whose fingerprints changed because
they disabled javascript (a common case in response to visiting panopticlick.
eff.org, but perhaps not so common in the real world), our heuristic made a
correct guess in 65% of cases, an incorrect guess in 0.56% of cases, and no guess
in 35% of cases. 99.1% of guesses were correct, while the false positive rate was
0.86%. Our algorithm was clearly very crude, and no doubt could be signifcantly
improved with effort."
I'm not sure how your conclusion follows from your premise. You are still trackable until you install a new font, update a plugin, install a plugin, etc. This may not happen for some time.
Even when you do make a change, you could still easily be tracked in many cases. If I see a new signature that I have never seen before that differs from an existing signature only by the version of a plugin, I can probably safely assume it's the same person, especially if I see that the plugin was updated between the last time I saw the existing signature and now.
I have a feeling that web developers are extra vulnerable to this type of tracking because we tend to install several useful developer extensions, and many of us have our own unique combination of extensions.
On top of that, if you use a resource that had only previously been used by your previous fingerprint, your identity can probably be smeared that way too. This is only measuring client-side entropy, but there is also server-side entropy that can be used to make inferences about clients.
If the only factor they're ever tracking you with is your fonts, then yes, you're correct.
But what if you have the same IP address, user-agent, and plugins for a week, and midway through the week your font fingerprint changed? Then they just go and tie both fingerprints, or repalce the old one with the new one.
In reality this is not going to be a problem for any web service that seriously attempts to track users, and there are multiple such companies that are doing so and don't let this stop them. Usually only one fingerprint will change at a time, which makes it easy for them to account for it.
The only good solution is to prevent them from capturing that information in the first place, and the only way to prevent it is to block Javascript and Flash, which is most easily done with NoScript.
I don't think the majority of those who track you (e.g. retargeting advertisers) would need to track you for more than a month, that is, unless you are setting up your system or tweaking your IDE, it is very unlikely that you will change your set of fonts within that time.
Also, they aren't particularly picky about keeping you, the trackee, forever uniquely-identifiable.
Consider this: when was the last time you (the non-average) or your grandmother (the average) installed a font?
That's not exactly true, but there is no public research that shows the contrary. I worked on a research project at INRIA earlier this year that focuses on that topic: http://stopfingerprinting.inria.fr/
AFAIK the project it's still active, but no definitive conclusion has been obtained.
The concept of a browser fingerprint being "unique" implies "worrying" in the sense that a user could then be tracked by their browser fingerprint.
But simply installing a font, changing screen resolutions, upgrading Java or Flash ("Browser Plugin details") or entering/leaving daylight savings time will result in the fingerprint changing.
So the browser fingerprint, as presented, isn't really a great way for websites to track users.
(And removing the aspects of the fingerprint subject to change, such as resolution and Browser Plugins etc., would then result in the fingerprint being less unique.)
This only becomes troublesome if you have a website into which you login. Any time your fingerprint changes, it can be updated provided you login to a controlled website before changing it again. This allows a fingerprint to be associated with an account or person. So facebook, gmail and this website could track the websites you visit given the fingerprint data as long as it is relatively unique.
Let's now imagine an entity that scrapes most of the internet traffic and has connections within facebook, google, etc. This company could easily figure out what pages you visit using a combination of browser fingerprint from the request header and IP. This can be tied to a person using accounts. They can even identify who within a household with the same IP visits which website.
> isn't really a great way for websites to track users.
You are quite right, this is true, however it's not really about that.
Firstly this is one technique that when combined with other information becomes more valuable.
Secondly it's not for websites to track users, it's for tracking companies to track browsers across multiple websites.
For example: A credit scoring / user tracking company that your bank uses. You log into the bank system. You visit other websites which have a tracking system. The bank gets a profile of the types of websites you visit, to better profile the types of customers it has. The tracking service has a profile of the types of users that it sees, to better place advertisements for their other customers.
Thirdly, a fingerprint of this kind is more of a multi-dimensional nature, than just a hash of the results. It allows for some variation, it will also update itself based on other information. For example "oh it looks like they have added a new font, but the other information is the same, and their behaviour across all the sites we track them is the same"...
Interestingly, I just tired this using Vidalia (the Tor browser).
> Your browser fingerprint appears to be unique among the 3,726,837 tested so far.
I may be using an outdated version of Tor. Did they reset their data at some point? I can't believe I'm the first person to have tried the test using the Tor browser in my time zone.
It's the Tor browser, so I haven't installed any extensions on it (the whole point of the Tor browser, as I understand it, is to present the same fingerprint to all browsers).
That is not the point of the Tor browser, though it is at times a goal.
That goal is absolutely impossible if you don't use NoScript, though. Tor browser includes NoScript by default, as well as many other extensions, but NoScript is initially set in "globally allow" mode which means it won't block any JS or Flash.
What are the browser makers doing to reduce the number of identifiable bits of data leaked?
Most of the bits of identifiable information listed there has a reason to leak since 99.999% of front-end developers have no reason to need that information to create an acceptable cross-browser experience for all users.
Mine is unique too, I checked Firefox, chrome and IE.
I guess it is trivial for large companies to generate unique ID numbers for these unique fingerprints and crosscheck against cookie/login databases to extract e-identity.
Is there an easy way from stopping browsers to broadcast this information?
Using the Internet anonymously is really hard these days...
EDIT: Maybe it is even better for browsers to broadcast the most common settings if EFF discloses this information.
You can account for those factors by parsing only certain bits of the User Agent string, and allowing for the addition of fonts to the list (most typically don't uninstall fonts). With the plugins, you can ignore the version number and just go by the names. There are bits like browser name, OS name, screen resolution and the presence of all previously detected fonts and plugin names that you can be pretty sure won't change for most users. As long as you can uniquely match by certain factors, it'll be enough to link you to your previous session.
For a purpose like ad tracking, the period of time you need to track people is likely pretty short, as in from when they click on a banner or text link until they complete a purchase, so you can compare lots of data points to identify them. If you need to track for longer periods, like to retarget an ad to people who have completed purchases for x, then you would need to compare fewer, more stable points and hope you find a unique match.
This just shows that even when shielding successfully against all other known mean of tracking [1], ultimately fingerprinting still can accomplish something re. tracking. Of course if a user doesn't care about other means of tracking, it's rather useless to worry about EFF's demonstration of fingerprinting.
I'm somewhat surprised to see that Chrome on my Nexus 10 shows up as unique, based primarily on user agent and screen size/color depth. Both seem to be surprisingly less common than I'd expect inasmuch as they would seem to be identical across all such devices.
You could (from the most painless to the more painful, in my opinion):
- Use an addon and change your useragent to something common (I use Firefox Nightly, so changing it to a Firefox stable release would make my browser less unique. Blender is a firefox addon that does that)
- Remove as many plugins you can (click2play won't help here, a site can still see the plugin you have installed).
- Enable click2play for the plugin that you still have installed (avoid allowing the site to fetch information with those plugins)
- Disable cookies (If you want to keep a whitelist, I suggest Cookie Controller for Firefox)
- Disable javascript (NoScript for Firefox)
Note that those could actually make your browse more unique, since most people allow cookies and javascript.
As a quick example of that, my browser has ~20 bits of information (one in 1.242.524) with Flash enabled, but ~22 bits with flash disabled (unique).
Perhaps the opposite would be better: pick a reasonable user-agent string and always return that for all users, always return the same (fake) monitor resolution, the same list of fonts, the same list of plugins, etc.
http://news.ycombinator.com/item?id=6980085
http://news.ycombinator.com/item?id=1082464
http://news.ycombinator.com/item?id=1081309
http://news.ycombinator.com/item?id=6188543
http://news.ycombinator.com/item?id=1087975