Supercookie uses favicons to assign a unique identifier to website visitors.
Unlike traditional tracking methods, this ID can be stored almost persistently and cannot be easily cleared by the user.

The tracking method works even in the browser’s incognito mode and is not cleared by flushing the cache, closing the browser or restarting the operating system, using a VPN or installing AdBlockers. 🍿 Live demo.

About

💭 Inspiration

• Paper by Scientists at University of Illinois, Chicago: www.cs.uic.edu
• Article by heise: heise.de

🌱 Purpose

This repository is for educational and demonstration purposes only!

The demo of “supercookie” as well as the publication of the source code of this repository is intended to draw attention to the problem of tracking possibilities using favicons.

📕 Full documentation

Installation

🔧 Docker

requirements:
Docker daemon

1. Clone repository

git clone https://github.com/jonasstrehle/supercookie

2. Update .env file in supercookie/server/.env

HOST_MAIN=yourdomain.com #or localhost:10080
PORT_MAIN=10080

HOST_DEMO=demo.yourdomain.com #or localhost:10081
PORT_DEMO=10081

3. Run container

cd supercookie/server
docker-compose up

-> Webserver will be running at https://yourdomain.com

🤖 Local machine

requirements:
Node.js

1. Clone repository

git clone https://github.com/jonasstrehle/supercookie

2. Update .env file in supercookie/server/.env

HOST_MAIN=localhost:10080
PORT_MAIN=10080

HOST_DEMO=localhost:10081
PORT_DEMO=10081

3. Run service

cd supercookie/server
node --experimental-json-modules main.js

-> Webserver will be running at http://localhost:10080

Workwise of supercookie

📖 Background

Modern browsers offer a wide range of features to improve and simplify the user experience.
One of these features are the so-called favicons: A favicon is a small (usually 16×16 or 32×32 pixels) logo used by web browsers to brand a website in a recognizable way. Favicons are usually shown by most browsers in the address bar and next to the page’s name in a list of bookmarks.

To serve a favicon on their website, a developer has to include an attribute in the webpage’s header. If this tag does exist, the browser requests the icon from the predefined source and if the server response contains an valid icon file that can be properly rendered this icon is displayed by the browser. In any other case, a blank favicon is shown.

<link rel="icon" href="/favicon.ico" type="image/x-icon">

The favicons must be made very easily accessible by the browser. Therefore, they are cached in a separate local database on the system, called the favicon cache (F-Cache). A F-Cache data entries includes the visited URL (subdomain, domain, route, URL paramter), the favicon ID and the time to live (TTL).
While this provides web developers the ability to delineate parts of their website using a wide variety of icons for individual routes and subdomains, it also leads to a possible tracking scenario.

When a user visits a website, the browser checks if a favicon is needed by looking up the source of the shortcut icon link reference of the requested webpage.
The browser initialy checks the local F-cache for an entry containing the URL of the active website. If a favicon entry exists, the icon will be loaded from the cache and then displayed. However, if there is no entry, for example because no favicon has ever been loaded under this particular domain, or the data in the cache is out of date, the browser makes a GET request to the server to load the site’s favicon.

💣 Threat Model

In the article a possible threat model is explained that allows to assign a unique identifier to each browser in order to draw conclusions about the user and to be able to identify this user even in case of applied anti-fingerprint measures, such as the use of a VPN, deletion of cookies, deletion of the browser cache or manipulation of the client header information.

A web server can draw conclusions about whether a browser has already loaded a favicon or not:
So when the browser requests a web page, if the favicon is not in the local F-cache, another request for the favicon is made. If the icon already exists in the F-Cache, no further request is sent.
By combining the state of delivered and not delivered favicons for specific URL paths for a browser, a unique pattern (identification number) can be assigned to the client.
When the website is reloaded, the web server can reconstruct the identification number with the network requests sent by the client for the missing favicons and thus identify the browser.

🎯 Target

It looks like all top browsers ( Chrome, Firefox, Safari, Edge) are vulnerable to this attack scenario.
Mobile browsers are also affected.

Current versions

Previous versions

⚙ Scalability & Performance

By varying the number of bits that corresponds to the number of redirects to subpaths, this attack can be scaled almost arbitrarily.
It can distinguish 2^N unique users, where N is the number of redirects on the client side.
The time taken for the read and write operation increases as the number of distinguishable clients does.

In order to keep the number of redirects as minimal as possible, N can have a dynamic length.
More about this here.

📌How to defend against?

The most straightforward solution is to disable the favicon cache completely. As long as the browser vendors do not provide a feature against this vulnerability it’s probably the best way to clear the F-cache.

• Chrome • MacOS

  • Delete ~/Library/Application Support/Google/Chrome/Default/Favicons
  • Delete ~/Library/Application Support/Google/Chrome/Default/Favicons-journal

• Chrome • Windows

  • Delete C:UsersusernameAppDataLocalGoogleChromeUser DataDefault

• Safari • MacOS

  • Delete content of ~/Library/Safari/Favicon Cache

• Edge • MacOS

  • Delete ~/Library/Application Support/Microsoft Edge/Default/Favicon
  • Delete ~/Library/Application Support/Microsoft Edge/Default/Favicons-journal

Other

🙎‍♂️ About me

I am a twenty year old student from 🇩🇪 Germany. I like to work in software design and development and have an interest in the IT security domain.

This repository, including the setup of a demonstration portal, was created within two days as part of a private research project on the topic of “Tracking on the Web”.

💖 Support the project

Spread the world!

Liked the project? Just give it a star ⭐ and spread the world!

• Bruce Schneier on schneier.com
• Matthew Gault on vice.com
• Rhett Jones on gizmodo.com
• Dev Kundaliyaon on computing.co.uk
• Barclay Ballard on techradar.com
• Discussion on ycombinator.com
• 🇩🇪 Andreas Proschofsky on derstandard.de
• 🇩🇪 Dieter Petereit on t3n.de
• 🇪🇸 ALVY on microsiervos.com
• 🇧🇷 Felipe Demartini on canaltech.com.br
• 🇧🇬 Daniel Despodov on kaldata.com
• 🇫🇷 Guillaume Belfiore on clubic.com
• 🇨🇳 study875 on cnbeta.com
• 🇷🇺 ITSumma on habr.com
• 🇷🇺 securitylab.ru
• Seytonic on YouTube