A method for preventing browser extension fingerprinting

Much has been done in the past decade to make cookie-based tracking of users across the Web harder. However, websites may still use a technique called browser extension fingerprinting (side note: Apparently LinkedIn does it.) to identify individual users and infer sensitive information about them, such as their religion, sexual orientation and medical issues.

In short, browser extension fingerprinting is possible because many extensions make extension-specific modifications to the DOM. A web page can observe these modifications and generate a “fingerprint” for the set of extensions a user has installed.

This paper presents the notion of DOM reality shifting, which aims to address this problem by running extensions in a version of the DOM (an alternate reality, so to speak) that is hidden from the web page itself.

The researchers present Simulacrum, an experimental browser extension that provides a first implementation of DOM reality shifting.

Simulacrum’s core strategy is to create a split reality between what a user experiences when browsing a page and what the page itself can observe. The user’s reality (the user DOM) contains the page and all DOM modifications performed by extensions, while the page uses a parallel DOM that does not contain any of the modifications. Simulacrum makes use of JavaScript’s language features (prototype-based inheritance and function overriding) to transparently replicate changes and route messages between the user and parallel DOMs.

As soon as the browser has received and parsed the HTML, it fires a DOMContentLoaded event. When this happens, Simulacrum instantiates a parallel DOM by cloning the real (user) DOM. To make sure that its code will execute before all other code, Simulacrum sets a run_at: "document_start" in its extension manifest and uses a neat trick that allows it to take precedence over all other extensions that also run at document_start.

Simulacrum continuously synchronises changes between the two DOMs while preventing the propagation of extension-driven changes to the parallel DOM. This is achieved by wrapping and overriding standard JavaScript functions that retrieve data from or apply changes to the DOM, such as cloneNode, querySelector, append, and scrollTop. These are just a few examples – if you want to know more about how this works and everything you need to take into account, go read the original paper (it’s open access and accessible).

I have previously written about Carnus, a system that was shown to be capable of identifying 5,793 different extensions based solely on their DOM fingerprints.

To evaluate the effectiveness of Simulacrum, the researchers visited Carnus’s specially crafted honeysite using a browser that included the Simulacrum extension for each of the 5,793 extensions. They found that Simulacrum prevents Carnus from detecting 5,553 (almost 96%) of all extensions. A few extensions slip through the cracks. This is often due to the use of poor design patterns, such as injecting <script> tags during document_start, which causes them to be included in the parallel DOM.

The researchers also measured the impact of Simulacrum on the user experience, specifically on page load times and functional impact.

They found that the majority of JavaScript API calls do not interact with the DOM and are thus not affected by Simulacrum. The interception of the calls that do interact with the DOM generally results in an overhead of less than one second, which shows that this approach is both feasible and practical. Simulacrum’s memory overhead is negligible, as the average increase in memory usage is just 0.25%.

When tested on 50 randomly selected websites among Alexa’s top 100 websites, Simulacrum caused major issues on 6 websites (12%), including crashes on login pages and missing content. The anti-fingerprinting extension also causes minor issues that don’t affect functionality on 5 websites (10%).

One might similarly expect Simulacrum to hinder extensions’ functionality, but this does not appear to be the case: the researchers tested Simulacrum with 50 randomly selected extensions, and all worked just fine.

Now what does all of this mean for you? Probably not much. If you develop browser extensions, this paper contains some advice on things you should not do if you want to protect the privacy of your users. But most of the advice appears to be targeted towards browser vendors who may implement these ideas natively.