Mozilla Security Blog
Categories: Announcements Firefox Security

Update on Plugin Activation

Chad Weiner

20 responses

To provide a better and safer experience on the Web, we have been working to move Firefox away from plugins.

After much testing and iteration, we determined that Firefox would no longer activate most plugins by default and instead opted to let people choose when to enable plugins on sites they visit. We call this feature in Firefox click-to-play plugins.

We strongly encourage site authors to phase out their use of plugins. The power of the Web itself, especially with new technologies like emscripten and asm.js, makes plugins much less essential than they once were. Plus, plugins present real costs to Firefox users. Though people may not always realize it, we know plugins are a significant source of poor performance, crashes and security vulnerabilities.

Developers will increasingly find what they need in the Web platform, but we also recognize that it will take some time for them to migrate to better options. Also, we know there are plugins that our users rely on for essential tasks and we want to provide plugin authors and developers with a short-term exemption from our default click-to-play approach. Today, we’re announcing the creation of a temporary plugin whitelist.

Any plugin author can submit an application to be considered for inclusion on the whitelist by following the steps outlined in our plugin whitelist policy. Most importantly, we are asking for authors to demonstrate a credible plan for moving away from NPAPI-based plugins and towards standards-based Web solutions.

Today marks the beginning of an application window that will run until March 31, 2014. Any plugin author’s application received before the deadline will be reviewed and processed before click-to-play is activated by default in Firefox. Whitelisted status will be granted for four consecutive Firefox releases and authors may reapply for continued exemption as the end of the grace period draws near.

Our vision is clear: a powerful and open Web that runs everywhere without the need for special purpose plugins. The steps outlined here, will move us towards that vision, while still balancing today’s realities.

– Chad Weiner, Director of Product Management

20 comments on “Update on Plugin Activation”

  1. Pete Boyd wrote on

    You have a typo: “Firefox releases and authors may reapply *at* for continued exemption as the end of the grace period draws near.”

    1. Daniel Veditz wrote on

      Thanks, fixed.

  2. Sören Hentzschel wrote on

    Hi,

    I sent a mail with questions related to this announcement to pluginwhitelist@mozilla.org, but I got a failure notice: Recipient address rejected: User unknown in virtual alias table [RCPT_TO]

    1. Chad Weiner wrote on

      Good catch and apologies. Please use pluginwhitelist@mozilla.com for now. Thanks!

  3. RoestVrijStaal wrote on

    Could this be turned off or will this initiate the birth of a poweruser-oriented FF-fork?

    Not every Firefox user is a grandma or 8-year old clicking ‘yes’ at every question.

    1. Georg Fritzsche wrote on

      You will still be able to set plugins to always activate per site or globally.

  4. Naseer Alkhouri wrote on

    Will this affect addons in any ways?

    Do you differentiate between plugins and addons?

    Cheers and thanks,
    Naseer

    1. Georg Fritzsche wrote on

      This will not make extensions click-to-play, only plugins.
      However, extensions that use plugins will be affected by this change (see bug 834918 for details).

      1. Powen Tan wrote on

        Hi Georg,

        Does this mean that even if my plugin is placed in the extension, the plugin will not be enabled by default?

        1. Georg Fritzsche wrote on

          At the moment, yes. But you can work around that:
          https://bugzilla.mozilla.org/show_bug.cgi?id=834918#c3
          … or use prefs to set the plugin.state.YourPlugin.

          1. Powen Tan wrote on

            Hi Georg,

            Sorry for asking again.

            I have this workaround from you in another forum.
            https://groups.google.com/forum/#!topic/mozilla.dev.tech.plugins/HlS4xPFnzZc

            And the last comment you gave is:
            “When bug 834918 is fixed, this shouldn’t be needed anymore for plugins embedded in Chrome content – hence the “for now”. ”

            From my understanding, after 834918 is fixed, I don’t need to use this workaround and my plugin in the extension should work fine (will not be affected by CtP rule).
            Am I right?

            1. Georg Fritzsche wrote on

              Yes, that is correct. Once bug 834918 is fixed you wouldn’t need the work-around anymore.

  5. YABE Yuji wrote on

    How many applicants do you think will file your requirements?

    And what is “a credible plan”?

    Plugins are to do things browsers can’t do. If “a credible plan” can be established, there is no reason to use plugins even in 2014. The ball is in your court. I’m a developer using some plugins (Flash, Unity, vr.js and others), and the only option for me is to leave the web platform. In fact, I’m playing with C++11 these days after a long interval.

    I’ve filed 30+ bugs for web browsers for two years (and I regret it now). I’m not a major contributor for the web, but maybe I’m not just a free rider. As a developer like that, let me say that the web platform and browser vendors are unreliable and untrustworthy.

    Do you refer Emscripten and asm.js? I’m use them and you must know those are completely different kinds of technologies from plugins. Security? Browsers themselves have much more security fixes than plugins. I’ve read some papers and statistics about that.

    If you want to “beat” some technologies, the only and right engineering way is to create *truly* better technologies. Don’t use politics, marketing and FUDs like this.

    1. BarleySinger wrote on

      The best choice would to go back to the old idea of the “Browser as chassis” concept, in which anything that followed the rules for a Browser COMPONENT (a thing that can interpret a given document format – like “Gopher”, etc) could be added to the the browser.

      In the old days, if there was anything in that browser you did not like, you could just buy a replacement for that part. If you needed a better Javascript engine (or one with an included ODBC database object model) you could just buy one (or get a free one). Browser were for more than just html documents.

      Unfortunately we are in a world of really bad WEB standards, fatware, and Rube Goldberg web applications. Peopel all over the world are trying to use what is *really* a DOCUMENT display markup language, to make interactive applications. What they need is a thin client Application Markup Language but they can’t have it. Right now the compromise is Java, or “.net” (both of which are horrible fat, bloated and slow) or to write in Html, javascript, php and anything else needed to make the thing run (as Rube Goldberg application).

      If the world of browser designators had not abandoned the far more elegant (and functional) “Browser as chassis” concept, we would have a thin client (sandboxed) “Application Markup Language” (probably a number of them) already well accepted and stable, and not be stuck with THICK CLIENT “.net” and “Java”.

      Just because today’s machines CAN have more memory in them and CAN run faster, does not mean that every application should be written to act as if those things are mandatory. Then again I taught myself assembly language when I was 15 (in 1978) and was compressing sound and graphics at least decade before the idea was common.

    2. Benjamin Smedberg wrote on

      Yabe, We don’t know how many applications we’ll have: at least three or four, but maybe many more? The “credible plan” might involve fixing or adding web APIs so that plugins are no longer necessary; we’ve been doing a lot of this already in support of Firefox OS on mobile platforms, and we may just need to figure out ways to expose things like USB or smart-card access to the web more generally. Part of the reason we’re doing this whitelist is so that plugin vendors can help us identify and prioritize missing web APIs.

  6. Klaus Hartnegg wrote on

    This will NOT apply to the ESR series (version 24.x).
    (source: email from Benjamin Smedberg on the enterprise mailing list).

  7. Spike wrote on

    Chad, you write as if the gradual evolution of web technologies will, soon, make all plugins obsolete. Do you have any numbers to back that up? If only 50% of the people depending on plugins can be migrated to better options, then your cheerful optimism seems more like whistling with eyes closed.
    Have you, or anybody, taken the top 20 plugins by number of users (or better yet, by estimated economic value) and checked (not guessed, actually checked) how many can *in fact* be migrated to better options?

    Look, I understand that you WANT to get rid of plugins, and you WISH the necessary replacement technologies were here or coming soon. You know what I wish? I wish you and the Chrome blog would stop writing these glowy everything’s-fine-no-worries posts from the imaginary alternate universe where you guys wanting and wishing something, makes it true.

    [This is purely a personal opinion]

    1. Chad Weiner wrote on

      Hi Spike,

      Thanks for the thoughts. When we speak of balancing today’s realities with where we want the web to go, we’re serious. It’s why, despite our deep interest in moving the ecosystem beyond NPAPI, we’re not pretending that there’s a sufficient replacement solution for everything, yet. That’s why we’re interested in an evolutionary approach, one that provides a runway for plugin authors who are still waiting for replacement technologies to mature.

      That said, we’re really pleased that some of the most commonly used plugins are indeed becoming obsolete; we’ve seen promising signs that emscripten+asm.js will eliminate the need for some things that everyone assumed would ‘always need native’. We’re committed to helping developers find what they need in the web stack so they can continue to provide users with the best possible experiences. But we agree that it won’t happen tomorrow, and this was fundamental to us as we designed the policy.

      Also, in case it’s unclear, users can still enable plugins on particular sites. If a user wants to activate a plugin it won’t require superuser status to figure out how to do it.

  8. Francesco wrote on

    Poor performance for plugins??? Have you ever tried to view live streaming from a camera without a plugin? Do you know that there are many video codec that Firefox or Chrome or IE don’t support??? PLEASE let the possibility to insert a plugin into a web page! I agree with popup that advice the user, but LET TO THE USER THE CHOICE TO USE IT!!! The browser are used to work too!!! There are a lot of company that invested a lot of resource to create a web application but they need the plugins until a browser can do ALL! (HTML 6???)

    1. Georg Fritzsche wrote on

      The user can choose to activate the plugins per site (or configure them to always activate in Tools->Addons->Plugins).