Browser favicons as user tracking 'Supercookies'

Favicons are those little icons on browser tabs familiar to all of us: 'Snoo' the reddit alien, the colourful M of Gmail, and of course twitters iconic blue bird. Unfortunately, these innocent branding icons are innocent no more.

A  German software developer, Jonas Strehle, has brought attention to a new method for creating ‘un-deleteable’ tracking tokens in the form of favicons. His Proof-of-Concept implementation, dubbed “Supercookie”, is based on a research paper presented by the University of Illinois.

These tracking tokens persist through cache and cookie clearing, work in incognito mode, are not affected by ad-blockers, and bypass what protection is offered by a VPN.

Jonas states on his GitHub page: “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.” (https://github.com/jonasstrehle/supercookie)

But how does this work? To understand this, we must understand how favicons are cached by the browser.
‍
To prevent downloading the favicon every time we visit a page, the favicon is cached by the browser and stored in the favicon-cache. The favicon-cache stores an entry for each unique favicon, including its domain and path. This means that a website can have multiple different favicons for each subdomain or path.

When a user visits a page the browser checks to see if the favicon is in the cache. If the favicon is cached it is loaded and displayed, else the browser makes a GET request to the server for the favicon.

This can be used to determine if a user has the favicon for a page cached. If a page request is not followed by a request for the favicon, then the user has the favicon cached.

With that understood, how can this be used to persistently track users?

When the user first visits the website, a unique bitmask can be created for that user. E.g. ‘1010’. Each bit corresponds to a page on the website. If the user has the favicon for that page cached, then the bit for that page is ‘1’ else the bit is ‘0’. This way a unique bitmask ID can be created in the favicon-cache.

To create this bitmask in the favicon-cache, the website must ensure the user caches specific favicons, but not others. To do this the website redirects the user to the page for each favicon that needs caching. If the user visits a page that should correspond to a ‘0’ in the bitmask, the server returns an invalid favicon to prevent the favicon-cache from being updated.

The main domain (e.g. foo.com) is not used as part of the bitmask, such that it can be used to test if the user has visited the website before. This is done by testing if the user has the favicon for the main domain in the favicon-cache.

On subsequent visits to the server, the server will act in ‘read mode’. The user will be redirected to every possible favicon page, to reconstruct the bitmask ID. This is again, achieved by testing if the user has the favicon cached or not (makes a GET request for the favicon). When in ‘read mode’ all favicons will return HTTP Error Code 404 (Not Found), in order to prevent the cache from being altered.

Once the bitmask ID is determined either in ‘write mode’ or ‘read mode’, it is stored as a cookie to prevent unnecessary reconstruction on each visit. The ID will not be re-constructed again until the user clears their cookies.

Now we know how the tracking cookie is created and recovered, why is it so persistent?

This is due to the unusual behaviour of the favicon-cache in browsers. Unlike other storage, the favicon-cache is shared between browser sessions, including private/incognito sessions. A favicon cached in a regular browsing session will be present in the favicon-cache for a private/incognito session. Additionally, the favicon-cache is not cleared when the user clears their cache and cookies in the browser. This behaviour is consistent across multiple browsers.

As favicons are first-party objects, ad-blockers will not prevent them from being loaded. Your IP address does not affect caching in the browser, so a VPN will not prevent this form of tracking.

The issue does not currently affect Firefox due to a bug with its caching behaviour. Firefox correctly caches favicons but does not use the cached favicon on subsequent visits, instead re-requesting the favicon. This bug has been reported to Firefox, therefore it is likely that Firefox will too be affected by this issue once the bug is fixed, unless mitigations are put in place.

The research paper presented by the University of Illinois recommends that browsers modify their caching behaviour, not sharing the favicon-cache in private/incognito browsing sessions and clearing the favicon cache when a user clears their cache/cookies. The paper additionally suggests that only caching favicons if the redirection is user initiated, may also be a potential mitigation for this issue.

The paper states that browser vendors have been made aware of these issues and potential mitigations:

“To  address  the  threat  posed  by  our  technique, we disclosed our findings to browser vendors and remediation efforts are currently underway, while we also outlined a series of browser changes that can mitigate our attack.”

Given the privacy-oriented stances of the likes of Apple and Mozilla, it’s likely we will see these mitigations placed into effect in the not-too-distant future.

‍