The developers of the fingerprintjs library, which allows for passive browser identification based on indirect signs such as screen resolution, WebGL features, and lists of installed plugins and fonts, have introduced a new identification method. This method evaluates the types of applications installed by the user and works by verifying the browser’s support for additional protocol handlers. The script code implementing this method has been published under the MIT license.
The verification process is based on analyzing the bindings of handlers to 32 popular applications. For example, by identifying the presence of URL handlers like telegram://, slack://, and skype:// in the browser, one can infer the existence of telegram, slack, and skype applications on the system, using this information as a characteristic for generating the system identifier. Since the list of handlers is the same across all browsers in the system, the identifier remains unchanged when switching browsers and can be applied in Chrome, Firefox, Safari, Brave, Yandex Browser, Edge, and even Tor Browser.
This method allows the generation of 32-bit identifiers, which by themselves do not provide high precision but serve as an additional characteristic when combined with other parameters. A significant downside of this method is the visibility of the identification attempt to the user — when generating an identifier on the provided demonstration page, a small but clearly noticeable window opens in the bottom right corner where handlers are iterated for a considerable time. This drawback is not present in Tor Browser, where the identifier can be calculated discreetly.
To determine the presence of an application, the script attempts to open a link related to an external handler in a popup window. The browser then displays a dialog suggesting opening the content in the associated application if the application is present, or shows an error page if the application is not installed on the system. By sequentially checking typical external handlers and analyzing the returned errors, one can infer the presence of the checked programs in the system.
In Chrome 90 for Linux, the method did not work, and the browser displayed a standard confirmation dialog for all attempts to check the handler (the method works in Chrome for Windows and macOS). In Firefox 88 for Linux, both in normal and incognito mode, the script identified the presence of installed extensions from the list, with an identification accuracy rated at 99.87% (35 similar matches out of 26,000 tests conducted). In the Tor Browser running on the same system, an identifier was generated that matched the test in Firefox.
Interestingly, the additional protection in the Tor Browser backfired, allowing for identification to be conducted without user awareness. Due to the disabling of confirmation dialogs for using external handlers in Tor Browser, verification requests could be opened in an iframe instead of a popup window (to differentiate between the presence and absence of handlers, the same-origin policy blocks access to error pages and allows access to about:blank pages). Due to flood protection, verification in Tor Browser takes significantly longer (10 seconds per application).
Source: opennet.ru
