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.

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.

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.

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.

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.

The post NoScript’s Migration to WebExtensions APIs appeared first on Mozilla Add-ons Blog.