Browser fin­ger­prints: the basics and pro­tec­tion options

Browser fin­ger­prints are not only char­ac­ter­ized by their unique­ness but there’s also an 80% success rate when it comes to rec­og­niz­ing web users - and this is without the use of cookies… For this reason, marketers and website owners are using browser-tracking more and more often in order to use the results for website op­ti­miza­tion or for designing targeted ad­ver­tis­ing.

In order to access content from a server, you need a client software. This is how you can access an email client and retrieve messages from the mail server. Access to web servers is achieved with popular web browsers such as Mozilla Firefox, Safari, or Google Chrome. Using the HTTP protocol, these ap­pli­ca­tions request data from websites and then display them in a user-friendly manner. Trans­fer­ring the contents takes place via IP packets, which contain in­for­ma­tion on the client (in addition to the user data), and which can be used on the server side to determine the browser fin­ger­prints.

There are basically two types of browser fin­ger­prints:

• Passive fin­ger­print­ing: so-called passive fin­ger­print­ing is col­lect­ing browser in­for­ma­tion without using a special ap­pli­ca­tion. This in­for­ma­tion is often contained in the header data of the IP packet by default. It always reaches the web server. This can include the IP address, the port used, and the browser type. However, basic con­fig­u­ra­tions such as the desired data types (HTML, XHTML, XML), character sets (e.g., UTF-8), or languages (usually the language of the browser or operating system) are also included. In some cases, the HTTP header also provides in­for­ma­tion about the operating system and the source page used.

• Active fin­ger­print­ing: with active fin­ger­print­ing, the browser specif­i­cal­ly queries in­for­ma­tion that isn’t au­to­mat­i­cal­ly provided when a web resource is accessed. This query can be done with JavaScript ap­pli­ca­tions or plug-ins that extend the browser’s func­tion­al­i­ty (es­pe­cial­ly Adobe Flash and Microsoft Sil­verlight). Among other things, this enables extra in­for­ma­tion to be obtained from the browser as well as more in­for­ma­tion about the operating system as well as details about the user’s screen (width, height, res­o­lu­tion). Ad­di­tion­al in­for­ma­tion includes the fonts installed or the time zone in which the user is located.

As mentioned pre­vi­ous­ly, the browser fin­ger­print is used to identify a user in order to be able to recognize them later on. By doing this, it is then possible to observe their surfing behavior in order to gain insights into the func­tion­al­i­ty and usability of a web project or to provide per­son­al­ized content. Browser fin­ger­print­ing shouldn’t be obvious to the visitor. This isn’t a problem for the passive variant since the data is trans­mit­ted anyway and is saved on the server side.

However, this au­to­mat­i­cal­ly trans­mit­ted in­for­ma­tion often lacks validity. Es­pe­cial­ly the IP address since saving it is prob­lem­at­ic due to legal reasons. The TCP ports used can’t fulfill their role as crucial features of the digital fin­ger­print for two reasons: 1. Dynamic address al­lo­ca­tion: if you connect to the internet, your access provider doesn’t receive a fixed and permanent IP address. It gets a new, dynamic IP from the pool of available addresses each time. A specific IP address can only be allocated to one device for a specific period of time. Only the user and his or her provider know when a device obtains a new internet address 2. Network Address Trans­la­tion (NAT): what’s even more prob­lem­at­ic is when NAT is used. The method connects several devices to the internet under a common, public IP address, which is shared by many users. It is used, for example, by routers that unite private house­holds in a LAN, but also by providers that control tech­nol­o­gy, in par­tic­u­lar, the mobile radio sector. Because of this, the mobile devices of two different users share the same IP address Both ad­dress­ing tech­niques are the result of a lack of available IPv4 addresses. It remains to be seen as to whether the successor protocol IPv6 solves this problem in the coming years by using dynamic addresses and NAT in the future. The TCP ports that a client uses to com­mu­ni­cate with the server are just as un­suit­able as a device’s recog­ni­tion feature. While the source port number is randomly generated for each request, network services are always provided with fixed default port numbers, which is why all clients use the same target port. For HTTP requests to a web server, this would be TCP port 80, for example.

The header of the HTTP protocol, which is used for trans­mit­ting web content, has no fixed size, unlike the TCP and IP header data. In addition to the ability to contain custom entries, several stan­dard­ized fields are required, some of which are very important when creating the browser fin­ger­print. These are the following header data:

• 'Referer': when a user reaches site A from site B, the URL of site A is passed as a referrer to site B’s server. Certain users may reach the des­ti­na­tion site from a par­tic­u­lar source site, which is just as useful for creating fin­ger­prints as the GET pa­ra­me­ters contained in the URL.

• 'User agent': with every HTTP request, the re­spec­tive client usually also provides a de­scrip­tion of itself in the 'user agent' field. In addition to the name and version number, the HTTP header also provides space for a comment, in which many browsers list the un­der­ly­ing platform or the operating system.

• 'Accept': using the accept field, the browser tells the server which content types it can process and therefore which output formats it prefers. In addition to HTML, XHTML (Ex­ten­si­ble Hypertext Markup Language) and XML (Ex­ten­si­ble Markup Language) are required. If the field is missing, it means the client supports all content types.

• 'Accept-Charset': in addition to the output format, the client can also define the desired character set to be used by the server in its response. These are primarily UTF-8 and the ISO standard ISO/IEC 8859-1.

• 'Accept-Encoding': in order to optimize the web project’s loading time, it is normal to compress web content before sending it. The browser must then unpack the com­pressed data before it can display it. The 'accept-encoding' field tells the contacted server which com­pres­sion format it supports. The list of possible pro­ce­dures created by IANA includes gzip, deflate, exi, and br.

• 'Accept-Language': using the HTTP entry, 'accept-language', clients reveal which language version they prefer. If this is available for the website that’s being accessed, the web server will deliver it. The language depends on the language of the browser or the operating system being used. Some browsers also enable you to specify other languages in the settings.

Active fin­ger­print­ing, just as the name implies, requires a web project operator to actively query in­for­ma­tion about the client. The requested prop­er­ties and data are char­ac­ter­is­tics that aren’t provided in the header data of the client packets. Because ap­pli­ca­tions have to be executed via the browser, the user can the­o­ret­i­cal­ly verify fin­ger­print­ing at any time by analyzing the outgoing data packages or the HTML or JavaScript source code. In the majority of cases, however, the process will remain hidden to visitors just like with other com­pa­ra­ble tracking methods.

For a seamless and fast data exchange between client and server, it is common to implement active browser fin­ger­print­ing using AJAX (Asyn­chro­nous JavaScript and XML) elements. This technique enables visitors to interact with a website without having to reload it com­plete­ly with every HTTP request. For this purpose, only the requested resources are loaded in the back­ground, while the user can still see and use all other elements. The in­for­ma­tion, which can be obtained using the cor­re­spond­ing scripts, can be divided into two cat­e­gories: browser in­for­ma­tion and screen in­for­ma­tion. Fur­ther­more, the browser fin­ger­print can also be extended by means of JavaScript to include in­for­ma­tion on the time zone and the con­fig­ured system colors.

Re­triev­able browser in­for­ma­tion

The prop­er­ties retrieved via the user’s browser are similar to those obtained with passive fin­ger­print­ing. Tracking is carried out using the navigator object, which is a possible property for Window objects – in other words, the window that opens in the browser. Even though the navigator object does not have a common default, it is still supported by all popular browsers. It forwards the following in­for­ma­tion to the web server:

• navigator.appName: transmits the name of the browser e.g., 'Opera' or 'Netscape'

• navigator.ap­pVer­sion: informs the server about the version of the browser and, in some cases, the operating system or even the type of the processor. For example, a possible entry could be '5.0 (Windows)'

• navigator.cook­ieEn­abled: use the cook­ieEn­abled property to check whether the browser supports cookies ('true') or whether the user has disabled them ('false')

• navigator.language: this property is used to find out the browser language. It is supported by all popular browsers (Internet Explorer version 11.0 onwards, Firefox version 1.0 onwards) and cor­re­sponds ap­prox­i­mate­ly to the HTTP entry 'accept language'. Examples of valid codes include 'en' and 'en-US'

• navigator.platform: specifies the platform being used. Possible values include Win32, MacIntel, Linux i686, iPhone, Android, and SunOS

• navigator.userAgent: with active browser fin­ger­print­ing, it’s also possible to see a detailed iden­ti­fi­er of the browser. The userAgent property does not differ from the HTTP header in­for­ma­tion and provides values such as the name, version, and browser platform in the summary. The following example shows a possible extract: 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0“

Trackable screen in­for­ma­tion

In­for­ma­tion about the site visitor’s screen can also be accessed via a JavaScript browser window. In this case, the screen object is used as a sub object, which, like the navigator object, is not specified in a standard, but is supported by all popular browsers. Up to five display prop­er­ties are passed on to the server with a cor­re­spond­ing script:

• screen.width: the value indicates the total width (in pixels) of the user’s screen

• screen.height: the property 'height' tells the server the total height (in pixels) of the user display

• screen.avail­Width: specifies the actual available display width (in pixels) that is available to the user. For this purpose, the width of the interface features, such as the Windows Taskbar, is sub­tract­ed from the total value

• screen.avail­Height: specifies the actual available display height (in pixels) that is available to the user. As with the available width, the di­men­sions of interface features are sub­tract­ed from the total value

• screen.col­orDepth: the col­orDepth property tells the web server the color depth (bits per pixel) that is available to the user for dis­play­ing images. Col­orDepth is equiv­a­lent to the pix­elDepth property, which also returns the value of the color depth, but is not supported by all browsers

De­ter­min­ing time zones and system colors 

A user’s time zone can be de­ter­mined using the JavaScript method: get­Time­zo­ne­Off­set(). Strictly speaking, this rep­re­sents the time dif­fer­ence between UTC (Universal Co­or­di­nat­ed Time) and the local time in minutes. The operating system settings are used as reference values. A simple JavaScript dialog box, which im­ple­ments the method and presents the dif­fer­ence, looks like this:

The operating system’s settings need to be accessed when tracking the system colors. However, in order for the necessary JavaScript function get­Com­put­ed­Style() to record the optics (chosen by the user) for window frames, buttons, etc., it depends on the support of CSS (Cascading Style Sheets). The Stylesheet language makes it possible to create website elements that au­to­mat­i­cal­ly take on the visitor’s system color settings. This is the color selection for these system elements in detail:

• Frame of active window (Ac­tive­Bor­der)

• Titel text of the active window (Ac­tive­Cap­tion)

• Desktop back­ground (Back­ground)

• Text on buttons (But­ton­Text)

• Border of 3D elements (Three­D­High­light)

The webserver then receives the cor­re­spond­ing color values or names of the system colors and can in­cor­po­rate them into creating the fin­ger­print.

Internet browsers have been designed primarily for dis­play­ing simple HTML documents, including in­di­vid­ual images. Over the course of time, however, the demands on client programs have increased due to web projects becoming more complex: in­ter­ac­tive elements have also become es­tab­lished in addition to media formats, such as audio and video files. In order for the browsers to be able to play back different content, the de­vel­op­ers had to extend the func­tion­al­i­ty of the ap­pli­ca­tions. This was done using plugins, which are still used today for this same purpose. With JavaScript, the plugins installed can be used to determine the browser fin­ger­print.

Adobe Shockwave Flash

The world’s most widely used plugin is Adobe Shockwave Flash, which is needed to play Flash an­i­ma­tions. In addition, Flash was the most commonly used video format on the World Wide Web. This means that the expansion – including the Flash Player - is com­pul­so­ry. Even though HTML5 is now a serious and safer al­ter­na­tive for providing and playing video content, the plugin is still installed on various browsers. The ex­cep­tions are most standard browsers on mobile devices, which do not offer a cor­re­spond­ing extension. However, a scan after in­stalling Adobe Flash (including the version number) is an important element in defining a browser’s digital fin­ger­print. A possible script, which uses a 'try…catch' command that can be used anywhere on the website looks like this:

For the first step, the JavaScript ap­pli­ca­tion attempts to create a new ActiveX object (only works on Internet Explorer), which de­ter­mines and then forwards the version number when suc­cess­ful. If it isn’t suc­cess­ful, the script accesses the mimetype object that is sub­or­di­nate to the navigator object already listed. It is also able to determine all browser-supported file formats and playback plugins (navigator.plugins). In line with the script used here, there is a response when it en­coun­ters Shockwave Flash or Shockwave Flash 2.0.

Microsoft Sil­verlight

The Sil­verlight extension from Microsoft adds functions that are similar to those of Shockwave Flash. The plugin for sup­port­ing in­ter­ac­tive elements is generally less common than Adobe Flash and is also no longer supported by many popular browsers. This can prove to be very valuable for browser fin­ger­print­ing because a browser that has this plugin installed, is clearly dis­tin­guished from many other browsers. In this context, however, a two-part script for the fin­ger­print test can be used, which in this case tries to in­stan­ti­ate an ActiveX object and inspects the navigator.plugins object if a failure should occur.

As mentioned pre­vi­ous­ly, the first part of the script attempts to use an ActiveX object to verify Microsoft Sil­verlight. For this purpose, the three current versions (as of May 2017) of the plugin are listed in the 'v' array. The col­lec­tion is the basis for the 'isVer­sion­Sup­port­ed' function, which returns either the value 'true' or 'false', depending on whether the verified client supports it or not. If ActiveX elements are not supported, the script searches the navigator.plugins object.

Check all installed plugins and supported file formats

The two existing scripts are suitable for acquiring the two most important plugins and the only way for an Internet Explorer user to determine these ex­ten­sions. However, for all browsers that support the navigator.plugins object, there is another way to not only add in­for­ma­tion about Shockwave Flash and Microsoft Sil­verlight to the browser fin­ger­print but also all installed browser plugins – with the 'try…catch' in­struc­tion:

The navigator sub object 'plugins' is therefore scanned with this script for installed plugins including name ('name'), de­scrip­tion ('de­scrip­tion') and file name ('file­name').

In the same way, all formats that are supported by the re­spec­tive client can be analyzed for browser fin­ger­print­ing. In this respect, there are dif­fer­ences, for example, on different devices, which is why the obtained values can con­tribute to spec­i­fy­ing the fin­ger­print in many cases. Instead of the 'plugins' object, the script must access the already-mentioned object 'mime­Type­s'.

As pre­vi­ous­ly mentioned, you can use CSS and JavaScript to check whether certain fonts are installed on the operating system of the client being scanned. The knowledge about the available fonts is in­ter­est­ing for a number of reasons, some of which go beyond merely de­ter­min­ing the digital fin­ger­print. Amongst other things, a look at the fonts can provide the following insights:

• De­ter­min­ing the software through which the re­spec­tive font(s) have been installed, such as Microsoft Office or Adobe Creative Cloud

• De­ter­min­ing the software with which a separate font (e.g., personal hand­writ­ing) was created

• Con­clu­sions on the pref­er­ences and interests of the client user e.g. based on party fonts, logos, or topic-specific character sets

The short list shows that fonts like these are not only useful for spec­i­fy­ing fin­ger­prints but can also be useful for creating targeted ad­ver­tis­ing campaigns. Of course, the more known installed fonts, the more accurate the analysis results will be. While only single fonts can be de­ter­mined with CSS, a Flash ap­pli­ca­tion (.swf) and the JavaScript function re­ceive­Fonts() make it possible to retrieve and list the complete font arsenal. The necessary code for the Flash object (Ac­tion­Script) is as follows:

By adding this code into the body area, you can integrate into the HTML document.

Web services like social media platforms generally require the accessing user to have a specific user account and be logged in using it. Otherwise, a large portion of the resources available from the service won’t be available to them - a cir­cum­stance that can be used to create browser fin­ger­prints. For this purpose, a service resource, which can only be accessed by logged-in users, must be known and in­te­grat­ed (as part of a DOM element) into the web project to be checked.

The type of element is of secondary im­por­tance because the crucial com­po­nents, the onload() and onerror(), can be used in numerous HTML com­po­nents such as <img />,<frame /> or <script />. There they are triggered when the linked resource is loaded or can’t be loaded, whereby the web server receives an ap­pro­pri­ate no­ti­fi­ca­tion. For example, an <img> element that verifies the login status on Twitter is generated using the following code line, but you should be aware that the URL can change at any time.

The guide shows what extensive tracking pos­si­bil­i­ties well-designed browser fin­ger­print­ing offers – and thus how fast you can be recog­nised and traced as a user even without cookies. It isn’t im­me­di­ate­ly obvious how unique your browser’s fin­ger­print is. There are various web tools such as AmIUnique or Panoptick­lick, which enable you to test how the unique­ness of your browser fin­ger­print with just one click. For example, if you want to test your browser with AmIUnique, just type in the address, amiunique.org and click on 'View my browser fin­ger­print'. What follows is a quick check of your web browser, comparing it to over 370,000 other browsers (as of May 2017).

The values shown here are not the only data that the web tool checks and which can be in­cor­po­rat­ed into the browser fin­ger­print. By clicking on 'Click here' or 'View more details', you can get a detailed overview of all the in­for­ma­tion that has con­tributed to deciding how unique your site is. Among other things, you will also find the values explained in the guidebook, such as which content types are accepted, possible com­pres­sion methods, screen res­o­lu­tion, or cookie ac­cep­tance.

It isn’t possible to com­plete­ly prevent the digital fin­ger­print of your internet browser from being found out. In the case of passive fin­ger­print­ing, the web server operator receives the char­ac­ter­is­tics au­to­mat­i­cal­ly trans­ferred in the HTTP header. However, you can try to keep your client’s recog­ni­tion value as low as possible so that the fin­ger­print is not unique and can’t be used for tracking. The simplest solution is to use a browser extension that au­to­mat­i­cal­ly blocks active content such as the JavaScript, Flash, or Sil­verlight ap­pli­ca­tions, which aren’t able to logically deliver in­for­ma­tion to the server. These plugins, which include NoScript for Firefox or Script­Block for Chrome, also provide optimal pro­tec­tion for the ever-in­creas­ing use of Canvas fin­ger­print­ing. This subtype of browser fin­ger­print­ing attempts to track the client through the use of canvas elements. The fact is that the rendering of texts in these elements varies greatly depending on the operating system, browser, graphics card, drivers, and fonts. However, if you activate plugins like these, you have to expect some web services or at least some in­di­vid­ual content to stop working. While ex­ten­sions, content, or sites can be added to filter lists to suspend script blocking, this isn’t very helpful if you aren’t sure whether the provider is trust­wor­thy or not. It should also be pointed out that using a blocker like this, in and of itself, can be directly used for finding out your digital fin­ger­print. Apart from the script blocking solution, you basically only have one other option, which is to avoid in­di­vid­u­al­iz­ing systems and browsers. Choose a commonly-used browser and access the default settings, if possible. The same also applies to the operating system being used. If you forgo the ad­di­tion­al ex­ten­sions for your client, there’s a high chance that you won’t create a unique fin­ger­print and will be harder to track. As a smart­phone user, you are still safe, es­pe­cial­ly with older models – thanks to the fact that there are currently only a few in­di­vid­u­al­iza­tion options for browsers and systems for smart­phones.