NoScript’s Migration to WebExtensions APIs

We asked Giorgio Maone, developer of the popular security extension NoScript, to share his experience about migrating to WebExtension APIs. Originally released in 2005, NoScript was developed to address security vulnerabilities in browsers by pre-emptively blocking scripts from untrusted websites. Over the time it grew into a security suite including many additional and often unique countermeasures against various web-based threats, such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) and Clickjacking.

Why did you decide to transition NoScript to WebExtension APIs?

The so-called “legacy” add-on technology which NoScript has been built with is going to be banned very soon; therefore, like too often in real life, it’s either migrate or die. Many people rely on NoScript for being safer on the Web and in some cases for their physical security too, making this transition, although quite painful, an ethical obligation not to leave them in the cold.

For a long time, I strove to maintain as much backwards compatibility as possible, in order to offer some protection to those users stuck for various reasons with older, inherently less safe, versions of Firefox. For this reason, the legacy version of NoScript contains a lot of code for working around bugs that Firefox has since fixed: this cruft can safely go away during the migration. The plan is to have a lean and mean version of NoScript available as soon as Firefox 57 is released. Some of the APIs required for full parity with the legacy version won’t land until Firefox 57. Until then, I can selectively delegate and prioritize some features to WebExtension APIs that already work by packaging NoScript as an Embedded WebExtension, which is also the best way to migrate user preferences.

On the other hand, people who need NoScript most are those who use the anonymity and security specialized Tor Browser, which is based on Firefox ESR (Gecko 54 until June 2018) where NoScript is not viable yet as a WebExtension. Therefore I’m forced to maintain two very different code bases for almost one year after the release of Firefox 57, in order to support the vast majority of my users.

Can you tell us about where you are with the migration?

NoScript already ships as a hybrid add-on, and I am in the process of moving all the code to WebExtensions APIs. Some features are even more performant on the new platform: it’s the case of the XSS filter, which takes advantage of the more asynchronous architecture of WebExtensions. The legacy XSS filter may stall the browser for a few seconds while checking very large (fortunately unusual) payloads; the WebExtensions-based version allows the browser to stay responsive no matter the load.

Have you had to use WebExtension APIs in creative ways?

NoScript 10 as a WebExtension is built mainly around the WebRequest API, which in its Firefox incarnation features some tweaks differentiating it from its Chromium counterpart. Last year I’ve been working together with the WebExtensions team to develop this enhanced API: a very pleasant experience and a welcome chance for me to contribute code on Mozilla Central again, after quite awhile. Dynamic permissions for embedded JavaScript are not natively supported by WebExtensions. Rather than requesting a new API, I am using Content Security Policies (CSP), a Web Application Security standard, to control scripting execution and other security properties of the webpage. Likewise I’m leveraging other Web Platform (HTML5) features, which were not available yet in the early NoScript days, to rebuild functionality originally based on “legacy” XUL and XPCOM technology.

What advice would you give to other legacy add-on developers?

Try to find workarounds for any missing pieces and be creative when using available APIs, not limited to just within the WebExtensions APIs boundaries but also exploring the whole Web Platform. If workarounds are impossible, ask the add-ons team for additions or enhancements.

Also, try to join and lobby the Browser Extensions Community Group hosted by the W3C. I feel that Mozilla has the most flexible and dynamically growing browser extensions platform, but it would be nice to make sure that the good ideas landing in Firefox also be available in Chrome and other browsers.

Thank you, Giorgio! Best of luck with the migration.

22 comments on “NoScript’s Migration to WebExtensions APIs”

  1. Ulf3000 wrote on

    lol

    1. BlabCapo wrote on

      LOL indeed, what a joke…

  2. Thrawn wrote on

    I think that the tone of this interview makes it clear that WebExtensions are a great opportunity, lots of potential as a way forward, but *very far from the level of maturity where we should drop all existing XUL-based extensions*.

    If even the #4 most popular extension, developed by a full-time professional programmer who feels morally driven to migrate to WebExtensions to keep millions of people safe online, still doesn’t have the necessary API support to actually complete the migration yet, then it seems quite ridiculous to suppose that we’re ready to talk about switching off the lights for XUL.

    The two-year countdown to dropping XUL should have started from the time when WebExtensions were judged mature and fully ready – for the top ten extensions, at the very least! – not when they’re still on the bleeding edge.

    1. Jan wrote on

      Flash has been killed the same way; way too soon, when the replacement was anything but ready.

      Except this time the replacement is much more ready. But still it’s tough.

    2. jwms wrote on

      Um no. It’s gone on for too long. If people aren’t willing to port their add-on, it’s time for other ideas to take their place.

      I already miss Cleanlinks and will miss DownloadThemAll but each add-on has its own situation.

      NoScript shouldn’t delay webextensions. If Giorgio pulls it off, he’s a great example of perseverance.

      1. Thrawn wrote on

        > Um no. It’s gone on for too long. If people aren’t willing to port their add-on, it’s time for other ideas to take their place.

        Nine of the top ten extensions, with millions of users, are not yet WebExtensions-ready. Do you really think such a hostile/adversarial attitude toward developers is warranted? Especially for a browser that claims to be driven, not by commercial interest and deadlines, but to “build open, innovative technologies that allow developers to work free of closed, corporate ecosystems”?

        And apparently the lack of WebExtensions APIs means that it *won’t even be possible* to fully migrate NoScript until Firefox 57, which is the very release that will switch off XUL. Where does the “gone on for too long” claim come from?

  3. kebin wrote on

    what about flashgot?
    any news

    It’s a must have and waiting for we port.
    Legacy version has seen less development of late but since WE is coming just want to know how things are shaping up,

  4. guest_2.22 wrote on

    For some unknown reason, in recent years I see Firefox highly dependent on buying new video cards and displays every few versions. Do nVidia and AMD fund Mozilla?
    First, acceleration which doesn’t work in all but latest video boards. Boards, because embedded/notebook solutions rarely work as expected. Most GeForces older than 3-4 years are not supported at all.
    To make users “democratically choose” to switch to newer video cards (and malware-filled PCs with UEFI – is that Mozilla’s “freedom”?), HTML5 video decoding is written so poor that it eats 2 cores of 2.2GHz 64-bit CPU. While even badly-written Flash uses around 60%. In the same portable, embedded GeForce is not supported… because it’s not supported, both in open and proprietary drivers. What’s wrong with these codecs? Even VLC plays it better! This heavy, resource-hogging modular program called VLC! Beating it in CPU usage is definitely worth noting as effect of Wirth’s law.
    Now WebExtensions. It’s not so bad, I found it even good, but then I found that resolution I tested it in is 4096×3072. In typical HD available in computers bought in the last year, amount of “air” between buttons and rest of toolbar makes it look like a student’s homework with loosely placed controls. This is no way professional nor useful. On older/smaller devices it’s worse. Ah, and styling it is VERY hard. It’s not that it’s impossible, but it’s very OS-dependent and version dependent.

    CSP? Is it like DNT?. Because if yes, it is compared to politely asking a robber with pistol not to rob someone. More, if a very useful NoScript would only mess with headers, how about messing them back by some script from trusted domain?

    So I want to thank Mozilla for Firefox… until it has been forked to some other version I use, hoping that Firefox will become browser for users, not advertisement consumer.

    1. mgol wrote on

      No, CSP doesn’t have anything in common with DNT, it’s a security measure enforced on the browser side. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP for more info.

  5. anonymous coward wrote on

    moving to webkit when? or should i ask, how much? clearly it will happen

  6. Daniel wrote on

    The fact that a highly professional and dedicated add-on developer like Giorgio has so much trouble and spends that amount of effort for the transition, let alone the fact that he’s even involved in the process of defining future APIs, should speak volumes. I don’t expect there to be more than a handful out of the thousands of Firefox add-on developers that could invest even a fraction of that. And still, he estimates that he’ll only be barely ready with a complete WebExtensions port on the day Firefox 57 is released, the very day that the old version would officially stop working; and he doesn’t even feel comfortable giving a guarantee for that.

    This interview shows clearly how poorly Mozilla have handled this whole issue. It quite literally states that the transition is almost impossible to do even under optimal circumstances.

    It would be a generous estimate to say that maybe 10% of the functionality that the top 40 Firefox add-ons require can be replicated in the current WebExtensions APIs. Or just look at Mozilla’s official transition documentation mapping legacy APIs to WebExtensions. The vast majority of APIs are dropped without even as much as a plan for a replacement.

    Most Firefox users browsing the Chrome extensions catalogue are laughing out loud when looking at what’s on offer there. Compared to Firefox, there’s almost no genuinely useful extensions available. And that’s not because of a lack of development effort, it’s because the APIs simply don’t support a lot of interesting applications. Even if Firefox reaches “Chrome parity”, which seems to be the new Mozilla-wide company ambition (regardless of the fact that many Firefox users will partly be using Firefox because it’s not Chrome) it would still only offer a shadow of the customisability that Firefox users want and are used to.

    Firefox and WebExtensions are simply not ready. Maybe with one or two more years of high-priority API development, it might reach a point where it’s suitable to discuss whether it’s ready to start replacing the legacy add-on infrastructure. Instead, Mozilla decided to go the way of tearing down what works before the substitution is even close to ready. I thought we left that approach behind us in the 1990s. Remember all those websites, sometimes major corporate ones, who thought it was okay to delete their current website once they started working on a new one, leaving people with a few weeks of “under construction” and “coming soon” notices? That’s how this feels. I fear it’s going to have a devastating effect on the Firefox user base, because “power users” are the ones hurt most by this, and those are the users that are most likely to not simply stick with the easy solutions of Edge, Chrome, or Safari.

    1. Thrawn wrote on

      Note also that WebExtensions will increase cross-browser compatibility of extensions.

      The theory is probably that this will mean Chrome’s large library of extensions will work on Firefox, and thus attract people to Firefox.

      The reality is more likely to be that all the power users, feeling thoroughly disgusted with Mozilla, take the few remaining extensions and move to Chrome, since they no longer have anything to lose.

      1. Nan M wrote on

        Oh I think that the writing of a shrinking deployment base has been on the wall for
        some few years already.
        Giorgio has to be respected for his principled efforts to maintain the
        faith with his own base. And I certainly trust that Mozilla’s sharing an adequate amount
        of its ad revenue with Giorgio and the Web Extensions team.
        But the modern browser truly belongs to Capital now and big business simply can’t allow runtime patching as potent as Mozilla has been affording the community for the last decade.

        NoScript arrived just at the point when the Web had become far too full of traps for easy secure browsing.
        It’s extended many people’s confidence in running out there, and I trust that whatever control Mozilla allows NoScript to preserve for client security will allow me to continue to navigate the Web on sites other than those where I have full recourse against fraudulent activity.
        Everything else in Web Extensions is I’m afraid going to be a shadow of the power that XUL
        Mozilla gave us old Addons community members.

        Thanks Giorgio for all those years and good luck for NS10! I’ll do my dummies best to support its development because without it we’re effed!

  7. mgol wrote on

    How is he going to maintain two different versions of the add-on (XUL-based & WebExtension-based) with the same add-on id so that Firefox 57+ users get the WebExtension version and Tor/Firefox ESR users get the older one but still updated?

    Especially that Mozilla warned that once you publish a WebExtension version of an add-on you can no longer publish XUL-based versions…

  8. Protimus wrote on

    I’ve already switched to Pale Moon, I simply cant use a browser without support of the extensions I need and a easy to modify UI.

    1. Thrawn wrote on

      Pale Moon is not a *terrible* option, but I’ll note that any extensions that are actually maintained, will probably migrate to WebExtensions. The only extensions that will work on Pale Moon will be those that are specifically maintained for it (not many), and those that are abandoned.

      It’s not quite the “Embrace, Extend, Extinguish” strategy, since Mozilla’s addon ecosystem predates Pale Moon, but still, Mozilla is likely to do heavy damage to Pale Moon with this move.

    2. mgol wrote on

      The truth is Pale Moon is an obsolete browser; its standards supports is years (yes, multiple) behind all mainstream browsers. I’ve known this is how it’s going to end up immediately when I read they forked the Gecko engine to their own variant. In 2017 it’s just not possible to keep up with mainstream browsers while maintaining an own engine without huge financial backing, lots of people working on it etc.

      In the past Pale Moon was able to sort-of keep up by rebasing its engine on the latest Firefox version. But it won’t be able to do that any longer as that’d mean dropping XUL-based extensions. The patches removing support for XUL extensions touch many pieces in the repository structure and reverting all those changes while keeping the rest up to date is just not going to work.

      The same applies to Waterfox that also wants to keep XUL add-ons. Both browsers still support NPAPI plugins but that was easy – first of all, Flash is still supported so lack of support for other plugins is enforced artificially, it’s easy to flip the switch. Secondly, plugins are pretty isolated from the rest of the browser while XUL extensions are deeply integrated with it.

      Another thing is Pale Moon doesn’t support WebExtensions. Most popular add-ons will migrate to this new standard so Pale Moon users will be left with older not supported versions.

      If you want to keep XUL add-ons working, using Firefox ESR is a safer choice that will work until 2018-06-26. I wonder how Pale Moon & Waterfox will cope until that date but I’m not optimistic.

      1. Thrawn wrote on

        > If you want to keep XUL add-ons working,
        > using Firefox ESR is a safer choice that will work until 2018-06-26.

        An idea I’ve seen floated before, and not a bad one, is to continue running the ESR beyond that point, but in a sandbox, using AppArmor or various other tools. Should be enough to keep safe for a while.

        OTOH, the ESR will still fall behind on standards support (including TLS updates), and extensions like NoScript will migrate to WebExtensions, so…it still won’t last.

        1. Nan M wrote on

          I’m grateful for Mozilla keeping up ESR support. Even if a client doesn’t run the last XUL-friendly version it beyond its official EOL, It’ll be vital for those of us with
          limited resources (time and expertise for figuring out bugginess) when the
          Web Extensions hammer comes down.
          This household plans to run ESR 52.x.x as a standalone on a live lubuntu disc while everyone
          gets familiar with the new order.

          1. trlkly wrote on

            So you think it’s invetible that things won’t be straightened out by Firefox 61? Because I hadn’t thought about going that far until we’re up to Firefox 60 and things are still bad.

            That said, I did move the family Windows computer to Chrome when I realized the addons could mostly be replaced with stuff the Chrome Store, but said addons didn’t work on Firefox. Rather than wait around, I decided to try moving over to Chrome, and have been mostly satisfied for non-developer work.

  9. trlkly wrote on

    I very much agree you are cutting things way too short here. I get that you want to keep your word, but why not delay part of this?

    XUL has been slated to die for a while, so getting rid of it makes sense at Firefox 57. The other API has completely surpassed XUL entirely. The only thing that might be nice is some sort of automatic conversion between an XUL options dialog and an HTML5 form or just options placed in the extensions page.

    XPCOMs should just continue to deprecated over time.

    The Jetpack API (or whatever it’s called now) should stick around in a frozen state until WebExtensions have had a few rounds of testing. Continue developing on it, but make sure the API is rock solid. It is not good to have necessary APIs actually debuting in the place where they are needed.

    I actually use Chrome as my main browser on Windows right now. Sure, that means I’m essentially using WebExtensions. But they reliably work, unlike on Firefox latest where most didn’t (as of last check). On Linux, I’m sticking with 52 ESR for as long as I can–but regular users should not have to do this. (Heck, they, unlike me, would probably have to downgrade their profiles from 56.)

    This desire to force all the changes at once to get it over with is just not good. Even this close, most addons are not WebExtension ready. Changing APIs takes TIME, and they need assurances that the APIs they want to use are mature enough to use.

    1. Thrawn wrote on

      > XUL has been slated to die for a while, so getting rid of it makes sense at Firefox 57.
      > The other API has completely surpassed XUL entirely.

      This…doesn’t seem to fit with the rest of your comment, and contradicts this very article, which makes it clear that there are APIs needed for migration that won’t even appear until Firefox 57.

      Unless by “the other API” you meant Jetpack? Which is as much a victim of this deprecation as XUL, just with many fewer casualties.