Mozilla Add-ons Community Blog

De-coupling Reviews from Signing Unlisted Add-ons

21 responses

tl;dr – By the end of this week (December 4th), we plan to completely automate the signing of unlisted add-ons and remove the trigger for manual reviews.

Over the past few days, there have been discussions around the first step of the add-on signing process, which involves a programmatic review of submissions by a piece of code known as the “validator”. The validator can trigger a manual review of submissions for a variety of reasons and halt the signing process, which can delay the release of an add-on because of the signing requirement that will be enforced in Firefox 43 and later versions.

There has been debate over whether the validator is useful at all, since it is possible for a malicious player to write code that bypasses it. We agree the validator has limitations; the reality is we can only detect what we know about, and there’s an awful lot we don’t know about. But the validator is only one component of a review process that we hope will make it easier for developers to ship add-ons, and safer for people to use them. It is not meant to be a catch-all malware detection utility; rather, it is meant to help developers get add-ons into the hands of Firefox users more expediently.

With that in mind, we are going to remove validation as a gating mechanism for unlisted add-ons. We want to make it easier for developers to ship unlisted add-ons, and will perform reviews independently of any signing process. By the end of this week (December 4th), we plan to completely automate the signing of unlisted add-ons and remove the trigger for manual reviews. This date is contingent on how quickly we can make the technical, procedural, and policy changes required to support this. The add-ons signing API, introduced earlier this month, will allow for a completely automated signing process, and will be used as part of this solution.

We’ll continue to require developers to adhere to the Firefox Add-ons policies outlined on MDN, and would ask that they ensure their add-ons conform to those polices prior to submitting them for signing. Developers should also be familiar with the Add-ons Reviewer Guide, which outlines some of the more popular reasons an add-on would fail a review and be subject to blocklisting.

I want to thank everyone for their input and insights over the last week. We want to make sure the experience with Firefox is as painless as possible for Add-on developers and users, and our goals have never included “make life harder”, even if it sometimes seems that way. Please continue to speak out, and feel free to reach out to me or other team members directly.

I’ll post a more concrete overview of the next steps as they’re available, and progress will be tracked in bug 1229197. Thanks in advance for your patience.

kev

21 comments on “De-coupling Reviews from Signing Unlisted Add-ons”

  1. Ben Bucksch wrote on

    YAHOOOOOOOOO!!!!! THANK YOU!!!!!!! 🙂

    This makes life so much easier. See https://blog.mozilla.org/addons/2015/11/25/a-new-firefox-add-ons-validator/comment-page-1/#comment-220441 for the profound importance of this.

  2. Ben Bucksch wrote on

    Besides, also thank you for implementing an upload and download API. These 2 pieces together mean that I can again automate the build process and ship signed builds to our QA, automatically.

  3. basil wrote on

    I was just wondering on an update about something. I have a lot of old addons that aren’t really updated or were fork projects- essentially things that I doubt will ever be signed. For this reason I haven’t updated past 40 and have no plans to until there is a permanent process to allow these unsigned addons to run. In 33 and beyond are you making that option available for the person who, well, knows their way around the browser and doesn’t need coddling? Or am I stuck with 40 still?

    1. Jorge Villalobos wrote on

      You have two options. Either you can use any of the Firefox versions that will accept unsigned add-ons with a pref flip (Dev Edition, Nightly, the unbranded builds), or you can change the add-on IDs (in case of forks) and submit them for signing, which should be very easy to do now.

    2. Dan Veditz wrote on

      I heartily second Jorge’s suggestion: You will be far better off running the Developer Edition and flipping the pref than staying on an old Firefox version with known vulnerabilities. And if you’re technical enough to have forked the add-ons yourself you will find it easy to get them signed under a new ID.

      1. basil wrote on

        If the developer edition has completely the same ui and literally no other changes other than the removal of addon signing, that seems like a fine option. However I have a visual condition- it’s WHY i use most addons and stylish scripts in fact. And frankly? getting that ecosystem up is a task in itself.

        And i didn’t fork them, they were done by others… who have moved on and hold no interest in updating or signing the code. So you see my issue. I can’t get an id, because it’s not my work, and I wouldn’t know where to start.

        however I’ll be happy if there’s a version of firefox that just has the security patches and none of the “improvements” you’re rolling out here. Point me the way to that.

  4. uh? wrote on

    So we are back were we started? everyone can make, redistribute and install add-ons that might contain malware, only now Mozilla is more than happy to promptly digitally sign this malware and help redistribute it on their add-ons page.
    Good job guys! This truly is the innovation age!
    I miss pre-“Chrome race” Mozilla…

    1. Adam Roach wrote on

      This policy change applies only to those add-ons that are not listed on any of Mozilla’s websites (“unlisted add-ons”). To be clear: “signing” and “distributing on the add-ons page” are two completely different operations. Signing no longer requires passing the validator. Including an add-on as part of addons.mozilla.org still requires both automated validation *and* a human review.

      In terms of the impact of removing the technical barrier to signing: the only way to use automatic validation to prevent bad actors from writing malware would be to somehow develop an automatic validator that is smarter than a human. Otherwise, given a turing-complete language like JavaScript, there are literally an infinite number of ways a malicious developer could “outsmart” any rules such a validator might contain.

      If we *could* develop a program that is smarter than a human, I doubt we would set it to task validating add-ons — even if we wanted to. There are some pretty good novels that treat this concept, but I’d start with this Wikipedia article and branch out from there: https://en.wikipedia.org/wiki/Technological_singularity

    2. manybuddies wrote on

      Sounds like it, doesn’t it. To me, it’s more like a step back than a step forward. Without addon signing, at least users have a rough understanding of the risk with installing addons.

      The more logical thing to do in my opinion is to allow all addons that passes though mozilla, but differentiate the signed ones from the unsigned ones by marking them out clearly. That way, it would be easier for everyone, end-users and developers alike, and signing would once again have the intended meaning of safety and assurance.

  5. István wrote on

    How will this change affect unlisted extensions that contain native libraries and are bundled with application installers? Will they still need to go through the full manual review process? Or will they also get signed in order to get them out to clients sooner and the review will happen later?

  6. Withheld wrote on

    And there’s the problem. Older, unsupported, must have add-ons, that force people who only know of one way to keep what they have working, staying with vulnerable versions of Firefox. Marvelous.

    Reminds me of Microsoft stopping critical updates for Windows XP, despite the millions and millions of users STILL using Windows XP. Profits before security. All that did was make the world a less safe place.

  7. Anonymous wrote on

    Please don’t remove “xpinstall.signatures.required”. It should be some way to disable this new “feature”. It is nonsense to need premission from a third-party (Mozilla) to use some codes written by myself or my trushed friend.

    If you worry malwares change the setting, make it unchangable by firefox, and only way to change the setting is using an editor to edit prefs.js directly. Or make a “readonly” file of white-list add-ons. There are many many way to protect the settings. It is very stupid to forking into two versions (branded and unbranded) for only one option.

  8. Charles Wallace wrote on

    I have been using Firefox instead of Explorer for months, but you have invariably blocked “Dashlane” saying it was unsigned. In past releases, I have been able to close your browser, uninstall Dashlane in Firefox , open and then close Firefox Browser, install Dashlane in Firefox via Dashlane extension box, and relaunch Firefox to make it work. It no longer works with the new version of Firefox. I will go back to Explorer Browser if necessary (Dashlane works there) if it cannot be corrected. Do you have any suggestions?

    1. Jorge Villalobos wrote on

      First you should check if the latest version of Dashlane still gives you problems installing the add-on. If it does, I suggest you contact the developers about getting their add-on signed, which should be fairly easy for them to do.

  9. Ron McClellan wrote on

    Not sure what all the “Yipee!” comments are here, I’m pissed. Firefox keeps eliminating my Yahoo Toolbar. I shouldn’t have to do a danged thing to “fix” this issue, it worked before Firefox . . .now it doesn’t. That is a FIREFOX issue. Make it work. Or at least directly address the issue, specifically relative to the Yahoo toolbar.

    1. Jorge Villalobos wrote on

      We hear you, and we’re investigating this.

  10. JULIO MOREIRA wrote on

    EXCELENTE

  11. Markus “Traumflug” Hitter wrote on

    U-oh, tough times for developers ahead. A while ago restart-less add-ons were introduced, easing occasional development a lot. Now these exaggerating measures. Using self-developed add-ons made a lot more complicated. In-development code (incomplete, debugging messages, confidential, …) actually forbidden.

    Did you consider that signing an add-on can not only be a safety enhancement, but also a safety exploit? I have developed an add-on here which injects personal data into certain web pages. Very useful for daily use, but also confidential information hardcoded. Works on this PC, only, expects certain files in certain locations. Signing it or (worse) having it reviewed is a no-go.

    These new ‘enhancements’ pretty much forbid in-house development. *sigh*

  12. Ken ” frustrated” Raym wrote on

    I am still trying to add yahoo toolbar to Firefox and all I get is something like… “This add on is blocked by Firefox as its not recognized” . How is the newest version of Yahoos toolbar and up to date Firefox …not recognized? Please tell me a step by step way to get the Yahoo toolbar. Thank you…

    1. Jorge Villalobos wrote on

      At the moment there’s no fix for this problem, unfortunately. What happens is that the Yahoo Toolbar add-on changes its own file, which breaks the signature verification done by Firefox. We have contacted them about fixing this. Hopefully they will make an update available that fixes this.

  13. Nita wrote on

    I have been playing movies on a website with no problems no it is saying I need to unblock adblocks which as suggested i go in under extensions & add-ons i have nothing there to unblock so what is up with that and how do I unblock adblocks if it is not showing i have anything blocked or downloaded in that area? If anyone could help me I would appreciate it. Thank You