They revealed a technique to be able to identify the browser through the Favicon

A new technique used to identify an instance of a browser. The method is based on the image processing features of Favicon with the help of which the site determines the icons that are displayed in bookmarks, tabs and other elements of the browser interface.

Browsers save Favicon images in a separate cache, which does not overlap with other caches, is common to all modes of operation, and is not cleared by standard cache and browsing history cleaners.

This function allows to use the identifier even when working in incognito mode and makes it difficult to remove. Authentication using the proposed method is also unaffected by the use of VPNs and ad blocking plugins.

The identification method is based on the fact that on the server side it is possible to determine whether the user has previously opened the page by analyzing the information about the Favicon load if the browser did not request the Favicon image specified in the parameters of the page, then the page was loaded earlier and the image is displayed from the cache.

Since lBrowsers allow you to configure your own Favicon for each page, useful information can be encoded via sequential forwarding from the user to multiple unique pages.

The more redirects in the chain, the more identifiers can be determined (the number of identifiers is determined by the formula 2 ^ N, where N is the number of redirects). For example, 4 users can address two redirects, 3-8, 4-16, 10-1024, 24-16 million, 32-4 billion.

The downside of this method is the long delays- The higher the precision, the longer it takes for the redirects to open the page.

32 redirects generate identifiers for all Internet users, but cause a delay of about three seconds. For a million identifiers, the delay is approximately one and a half seconds.

The method involves working in two modes: writting and reading:

  • Writing mode generates and stores an identifier for the user who first accessed the site.
  • Reading mode reads a previously stored identifier.

The choice of mode depends on the request of the Favicon file for the main page of the site: if the image is requested, the data is not cached and it can be assumed that the user has not accessed the site before or the content is cached. outdated. According to the researchers, by specifying the HTTP Cache-Control header, it is possible to achieve the Favicon in the cache for up to one year.

In reading mode, when opening a site, the user is chained to predefined pages with their Favicons and HTTP server parses which Favicons are requested from the server and that are shown without accessing the server from the cache. The presence of the request is coded as "0" and the absence as "1". In order for the identifier to be preserved in future calls, a 404 error code is displayed in response to Favicon requests, that is, the next time you open the site, the browser will try to load these favicons again.

In write mode, in the redirect loop for pages encoding "1", the correct answer of the Favicon is returned, deposited in the browser cache (when the cycle is repeated, the Favicon data will be returned from the cache, without accessing the server), and for pages encoding "0" - error code 404 (if you repeat the redirect cycle, the page data will be requested again).

The method works in Chrome, Safari, Edge and partially in Firefox. In Firefox for Linux, the use of Favicons as Supercookies is hampered by a feature that prevents the browser from caching the Favicon.

Interestingly, the authors of the authentication method notified the Firefox developers about this feature about a year ago, noting that there was an error in the cache, but not mentioning their work and that correcting the error would lead to the possibility of user identification.

Source: https://www.cs.uic.edu


The content of the article adheres to our principles of editorial ethics. To report an error click here!.

Be the first to comment

Leave a Comment

Your email address will not be published.

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.