Mozilla Add-ons Community Blog
Categories: developers policy

Preventing Add-ons & Third-party Software From Loading DLLs Into Firefox

12 responses

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.

12 comments on “Preventing Add-ons & Third-party Software From Loading DLLs Into Firefox”

  1. Michael wrote on

    I’m not affected by that. Neither as an user nor as a developer.
    But did I got it right that you give developers a deadline of just 12 weeks before they will lose all (non-ESR) users?
    That’s just… wow.

    That’s even more extrem that annoucing a deadline of all non-WebExtensions add-ons by the end of 2017, while most developers still don’t know if their add-on will even be possible(!) by the end of the year with WebExtenions — and likely don’t know that for another long time.

    I can’t speak for everyone, but speaking for me and what I’m assuming is the majority of developers: We aren’t against these ideas, just against the way how Mozilla is planning the transistion, deadlines and announcements.

    I like WebExtensions, I like removing stuff which is unstable like binary components. I don’t like uncertainty (more timely announcements would be key), no existing alternatives (implement first enough WebExtensions APIs, then announce a deadline for non WebExt add-ons) and impossible deadlines (see article).

    1. Kev Needham wrote on

      Thanks for taking the time to give feedback. We’ve updated the post and policy implementation details.

  2. Wladimir Palant wrote on

    Firefox 53 is already on the nightly channel, was there really no way to announce this earlier? We are already busy enough with the WebExtensions migration, now we have to go back to the old extension and remove ctypes usage urgently (Adblock Plus loads NSS for some crypto).

    1. Kev Needham wrote on

      Updated the post and how we’ll be looking at C-Types. Thanks for taking the time to give feedback.

  3. Nail wrote on

    So you want extensions that call system functions to bundle applications which can’t be code reviewed, unlike with js-ctypes, and which might get blocked by AppLocker/SRP, also unlike with js-ctypes?

  4. Adam Niederhaus wrote on

    Shame on you and whoever else is pushing this forward without allowing much, if any voice, for the ignorant end user. I don’t like Chrome and it appears that Firefox will now forcefeed to me! Well, it was nice while it lasted. Adios!

  5. NikonMike wrote on

    As a long time user I feel uneasy about the looming “end of the world as we know it” for Firefox Add-ons. Soon to be released Fx 52 is to become the last ESR version before Fx 57 stops supporting old add-ons. With the significance/disruptiveness of this event in mind, wouldn’t it make sense to issue version 56 as an ESR release so that support can be maximized for users depending on old add-ons? Or postpone the cut-off date for old add-ons support to coincide with an ESR release?

    1. flash wrote on

      too much security

      1. Harry Birmingham wrote on

        Great job!

      2. Alya wrote on

        Yes agreed indeed!!

  6. Thomas wrote on

    “Starting with Firefox 53, […] Any new add-ons that load binaries using JS-ctypes or other methods”

    https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/ indicated that AMO will not sign ANY new add-ons starting with Firefox 53 at all. Is this plan still valid? Why do you need this extra rule of not signing new add-ons that load binaries?

    1. Jorge Villalobos wrote on

      Starting with 53 we won’t sign new legacy add-ons but will continue to sign updates to existing add-ons. You’re right that the policy is somewhat redundant, but there’s also an update to the blocklisting policy, in that we will be pursuing add-ons loading binaries more aggressively.