24Dec 2019

What is a Browser Fingerprint?

The goal of this experiment is to calculate the ”fingerprint” of a Browser using various techniques ranging from JavaScript to brute force attack.

The question is: is it possible to identify with certainty a given Browser over the internet despite the fact that it has cleaned its cookies ( and supercookies )?

Information Sent by the Browser to a Remote Server

Information Sent by the Browser to a Remote Server

During the connection to a server, the Browser sends Header information defined by the HTTP protocol. These data are not supposed to identify specifically a Browser but they may vary from Browsers to Browsers.

For instance, the ”user-agent” String will identify with certainty the type and version of the browser software.

Example of such user-Agent strings:

User-Agent: Mozilla/5.0 (Windows NT 5.2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7.

This is obviously not enough to uniquely identify a given Browser since, in our example, all the users who have downloaded this version of Chromium will share the same user-agent string.

But, looking at the other information available from the request headers, we clearly see that they provide additional information that certainly reduces the amount of the browsers all over the world sharing exactly the same request headers string:

User-Agent: Mozilla/5.0 (Windows NT 5.2) AppleWebKit/535.7 (KHTML,like Gecko)Chrome/16.0.912.75 Safari/535 .7

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Encoding: gzip,deflate,sdch

Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

We may, with all these data, identify a group of Chromium Browsers which are probably used by French people or by people using the French language. Anyway, the population of this group is certainly very important.

Nevertheless, with the use of the request headers, we have already located our Browser into a specific group. Now the question remains to know if there are other tests that may be done and if the addition of all these tests will, in the end, identify the Browser uniquely.

Not only the request headers are available. If we consider the JavaScript runtime, we have plenty of other information available to our server: the resolution of the screen, the detection of the Browser version by the use of the Browser object and the list of all the installed plugin in the navigator with their micro versions and their associated mime types by analyzing the Navigator object. This is enough to give us a lot of information about the browser.

Additionally, we may try to exploit the three main ‘popular’ plug-ins generally installed in navigators: java, flash, and Silverlight. Regarding Silverlight (and moonlight its Linux implementation ), the Microsoft plugin, most users are generally unaware of its presence. While Silverlight is officially deprecated, it’s still present and supported in several navigators – including some version of Edge.

These three plugins can detect, in theory, hardware information and the installed fonts. The amount of hardware information collected by Silverlight is impressive: video capture devices, audio capture devices and even the full list of GPUs ( Graphic Power Units ).

In addition, some test using Brute Force Attack, trying to scan the user machine to guess if some features are available or not, are possible.

For example, the CSS Font Detection brute force attack: we maintain a list of existing fonts and we try to produce a string using each font for this list, providing a given replacement font if the font is not available ( e.g. ”Arial”). Then we compare the measure of the characters produced with the measure of the same characters using the ”Arial” font. If these measures are different, we conclude that the font exists on the client PC otherwise we conclude that the font does not exist on the client PC.

While we have a wide range of characteristic parameters that can identify the browser, we still don’t know if this is enough to uniquely characterize a given navigator.

The Browser Fingerprint Experiment

The Browser Fingerprint Experiment

During our experiment, we will run a series of tests. When the tests are done, we will compute a Browser Fingerprint by making a hash of the collection of data we retrieved from the Browser. Additionally, we will store the IP address and geolocation information – while they are not part of the fingerprint.

To detect returning visitors, we will store a cookie on your PC ( to pass the test you must accept cookies from our website).

Of course, some people may delete their cookies and come back to the website, they won’t be immediately detected as returning visitors. However, we can use the IP and geolocation information plus a heuristic guess based on hardware detection information to detect returning visitors, which means that we can know with a very small error rate if someone is a returning visitor, even if the cookies we store are deleted.

We compare the likeness of the data we have collected from users to data we have collected so far, using standard string comparison algorithms, then we may be able to retrieve your previous fingerprints.

We use a ”distance” between two fingerprints as follows:

me of his parameters, like installing new fonts or installing new plug-ins and coming back to the test tracking website, then he shall get a different fingerprint ID, but we still may be able to track him using the aforementioned techniques.

Other techniques may be used such as Bayesian probabilities so that at the end of the day a ”meta-fingerprint” may be computed for each browser allowing it to be tracked even if some of its parameters have been changed.

What are the countermeasures? Using anonymizers could lead to a paradox since these anonymizers produce themselves almost perfect fingerprints ( indeed, they have not been designed to prevent Browser Fingerprinting ). To disable fingerprinting, a user may have to remove or change most of his installed fonts, disable java, flash or Silverlight but he will also have to use a browser that doesn’t expose the full list of the micro-versions of the plug-ins installed. If Browser Fingerprinting is possible, the remedies are not so simple since many websites around the world actually use the information sent by these Browsers either for debugging, either for selecting the right code to launch, etc…

In the second part, we shall realize a concept-proof application to demonstrate the browser Fingerprinting.

Acodez is a leading website design and web development company in India. We offer all kinds of web design and web development services to our clients using the latest technologies. We are also a leading digital marketing agency providing SEO, SMM, SEM, Inbound marketing services, etc at affordable prices. For further information, please contact us.

Looking for a good team
for your next project?

Contact us and we'll give you a preliminary free consultation
on the web & mobile strategy that'd suit your needs best.

Contact Us Now!
Rithesh Raghavan

Rithesh Raghavan

Rithesh Raghavan, Co-Founder, and Director at Acodez IT Solutions, who has a rich experience of 16+ years in IT & Digital Marketing. Between his busy schedule, whenever he finds the time he writes up his thoughts on the latest trends and developments in the world of IT and software development. All thanks to his master brain behind the gleaming success of Acodez.

Get a free quote!

Brief us your requirements & let's connect

1 Comment

  1. Trupti


    After a long time, I have read such an interesting
    blog, really felt good reading this. Great work !!

Leave a Comment

Your email address will not be published. Required fields are marked *