A toolkit has been published with an implementation of a method for detecting add-ons installed in the Chrome browser. The resulting add-on list can be used to increase the accuracy of the passive identification of a particular browser instance, in combination with other indirect cues such as screen resolution, WebGL features, lists of installed plugins and fonts. The proposed implementation checks for more than 1000 add-ons to be installed. An online demo is offered to test your system.
The definition of add-ons is made through the analysis of the resources provided by add-ons available for external requests. Typically, add-ons include various accompanying files, such as images, which are defined in the add-on's manifest by the web_accessible_resources property. In the first version of the Chrome manifest, access to resources was not limited and any site could download the provided resources. In the second version of the manifest, access to such resources by default was allowed only for the add-on itself. In the third version of the manifest, it was possible to determine which resources can be given to which add-ons, domains and pages.
Web pages can request resources provided by the extension using the fetch method (e.g. "fetch('chrome-extension://okbβ¦.nd5/test.png')"), which returns false usually indicating that plugin not installed. In order to block an add-on from determining whether a resource exists, some add-ons generate a verification token that is required to access the resource. Calling fetch without specifying a token always fails.
As it turns out, access protection to add-on resources can be bypassed by estimating the execution time of the operation. Although fetch always returns an error when requesting without a token, the execution time for the operation with and without the padding is different - if the padding is present, then the request will take longer than if the padding is not installed. By evaluating the reaction time, it is possible to accurately determine the presence of a supplement.
Some add-ons that do not include externally accessible resources can be identified by additional properties. For example, the MetaMask add-on can be defined by evaluating the definition of the window.ethereum property (if the add-on is not set "typeof window.ethereum" will return the value "undefined").
Source: opennet.ru