Updated 2017-01-25: Thanks for the feedback given on this post. To lessen the impact of this change on developers, we’ve clarified our policy and updated this post such that it applies only to new add-ons, and those that do not rely on Firefox internals. It also includes further clarification that add-ons loading binaries that depend on Firefox internals could be subject to blocklisting starting in Firefox 53.

Loading a DLL or binary component into the Firefox process is a method employed by third-party software to enable low-level interactions between Firefox and the operating environment and/or applications that run within it. Binaries can be loaded via an add-on using JS-ctypes, or injected directly into the process using other methods to enable functionality not available natively. These techniques, however useful to the developer, do not always account for underlying changes to Firefox, and are frequently the root cause of startup crashes for users running a new version of Firefox for the first time.

Over the past year, these startup crashes have resulted in the delay or revision of four Firefox releases. The crashes erode confidence in Firefox, and can render Firefox and the information it contains unusable. Users of Firefox need the confidence that their browser won’t crash on an update, and that they’ll have a positive experience using the newest and most secure version available. Firefox release managers need the confidence that they can release new versions of Firefox without worrying about crashes brought on by third-party software.

With the introduction of the Native Messaging API in WebExtensions in Firefox 50—released on November 8, 2016—extensions are able to communicate directly with a host executable running in a separate process. These executables are installed separately, and provide low-level interactions outside of the Firefox process without the possibility of crashing it. The use of Native Messaging with extensions is the supported method for third-party developers to perform interactions that are not available natively, and other methods, including using JS-Ctypes, are actively discouraged.

Starting with Firefox 53, to be released on April 18, Mozilla will introduce changes designed to discourage and/or prevent the loading of third-party binaries into the Firefox process(es) that include:

Updating our add-on policies and validation methods to reject: Any new add-ons that load binaries using JS-ctypes or other methods Any add-on that loads libraries that depend on Firefox internals.

Updating the blocklisting policy to include: Blocking of libraries that third-party software loads (or attempts to load) DLLs into the Firefox process(es) using any method Blocking of add-ons that incorporate binaries that depend on any internal of Firefox

Product changes to better protect Firefox from DLL injection

These changes will also prepare us for wider adoption of the 64-bit version of Firefox on Windows in the near future, as some existing DLLs that are injected or loaded will not be compatible.

Add-on developers who are currently using JS-ctypes should begin immediately transitioning to the Native Messaging API using WebExtensions. Documentation and examples for Native Messaging are available on MDN, and you can ask questions or share concerns about these changes in these communication channels.