Windows DLL Blocklisting

Overview

There are many applications which interact with another application, which means they run their code as a DLL in a different process. This technique is used, for example, when an antivirus software tries to monitor/block navigation to a malicious website, or a screen reader tries to access UI parts. If such an application injects their code into Firefox, and if there is a bug in their code running in our firefox.exe, it will emerge as Firefox’s bug even though it’s not.

Firefox for Windows has a feature to prevent DLLs from being loaded into our processes. If we are aware that a particular DLL causes a problem in our processes such as a crash or performance degradation, we can stop the problem by blocking the DLL from being loaded.

This blocklist is about a third-party application which runs outside Firefox but interacts with Firefox. For add-ons, there is a different process.

This page explains how to request to block a DLL which you think we should block it as well as technical details about the feature.

Two types of blocklists

There are two types of blocklists in Firefox:

A static blocklist that is compiled in to Firefox. This consists of DLLs known to cause problems with Firefox, and this blocklist cannot be disabled by the user. For more information and instructions on how to add a new DLL to this list, see Process for blocking a DLL in the static blocklist below.
A dynamic blocklist that users can use to block DLLs that are giving them problems. This was added in bug 1744362.

The static blocklist has ways to specify if only certain versions of a DLL should be blocked, or only for certain Firefox processes, etc. The dynamic blocklist does not have this capability; if a DLL is on the list it will always be blocked.

Regardless of which blocklist the DLL is on, if it meets the criteria for being blocked Firefox uses the same mechanism to block it. There are more details below in How the blocklist blocks a DLL.

Process for blocking a DLL in the static blocklist

But wait, should we really block it?

Blocking a DLL with the static blocklist should be our last resort to fix a problem because doing it normally breaks functionality of an application which installed the DLL. If there is another option, we should always go for it. Sometimes we can safely bypass a third-party’s problem by changing our code even though its root cause is not on our side.

When we decide to block it, we must be certain that the issue at hand is so great that it outweighs the user’s choice to install the software, the utility it provides, and the vendor’s freedom to distribute and control their software.

How to request to block a DLL

Our codebase has the file named WindowsDllBlocklistDefs.in from which our build process generates DLL blocklists as C++ header files and compiles them. To block a new DLL, you create a patch to update WindowsDllBlocklistDefs.in and land it on our codebase, following our standard development process. Moreover, you need to fill out a form specific to the DLL blockling request so that reviewers can review the impact and risk as well as the patch itself.

Here are the steps:

File a bug if it does not exist.
Answer all the questions in this questionnaire, and attach it to the bug as a plaintext.
Make a patch and start a code review via Phabricator as usual.