Archive for the WebExtensions Category

Dec 18th 2017 Update

NoScript 10.1.6 reimplements the "Export" button functionality in a more convoluted way, which doesn't require the "downloads" permissions anymore though :) Enjoy!

It seems some users are really upset with NoScript 10.1.5.7 asking for an additional "downloads" permission.
This surprised me a bit. Not just because NoScript 5, which everyone loves to praise in order to bash 10, was all-mighty: like any other "legacy" add-on, it could even format your hard-disk, not before having sent all its content to a remote server in Siberia. But especially because they already granted NoScript 10 itself (like all the other content-blocking WebExtensions, including all the popular adblockers) plenty of much scarier permissions, such as the ability of monitoring and filtering all your network traffic, which I find the scariest of all but, quite obviously, is mandatory for the task you use NoScript for.

Unfortunately the WebExtensions permissions asking prompts don't let authors to explain in advance what a certain permission is used for (yet I did provide this info in the support forum since first release), but for those who couldn't figure it out from the changelog: the "downloads" permission just gives access to the downloads WebExtensions API, which NoScript uses to implement the "Export" feature and let you save a configuration file somewhere on your disk. Because, unlike "legacy" add-ons, WebExtensions cannot interact with your filesystem directly and so must make you "download" the file.

Notice also that instead, just like "legacy" add-ons, and unlike Chrome extensions AFAIK, Firefox WebExtensions are still reviewed at AMO by a trusted staff of experienced add-ons developers, whose job is much easier now because of the simplicity of the new API and, guess what?, because of the explicit permissions: the first thing they do with a new version is looking at the code differences and checking that those permissions are used in a legitimate way. Rob Wu, the reviewer which filtered 10.1.5.7 even suggested alternate ways to implement the Export functionality without the new permission, but we tried those and they just didn't work.

Anyway, if you can't trust with this (modest) power NoScript, a component of the Tor Browser (one of the most scrutinized software pieces on the planet by security experts all over the world), I wonder if it makes sense even trying to complete the WebExtension migration of FlashGot, which is much more frivolous but completely centered around this ultra-frightening "downloads" permission...

Someone seems to be still convinced that changing our beloved NoScript UI has been a whimsical (and suicidal) decision of mine, entirely avoidable.

The ones who know better about recent history of Firefox and of its add-ons ecosystem are aware, though, that the UI couldn't stay the same simply because the technical foundation (XUL/XPCOM) for the "old" one is not there anymore, and NoScript has been forced into being completely rewritten as a WebExtension (and therefore its UI as pure HTML) or just die.

Since it was anyway impossible to replicate exactly the well known user experience provided by NoScript 5.x (which, BTW, is still actively maintained and available here), I've tried to find a silver lining in the forced rewrite, taking it as a chance to incorporate user feedback collected over more than 12 years, especially about making the permissions system more customizable.

And indeed, the old concepts are all still there, but the way they are implemented is more flexible and amenable to customization, albeit admittedly less discoverable and, for long time users, surely confusing at least initially.

Bugs aside, I think the biggest problem with the transition, which I'm truly sorry for, is me not having found the time yet to write any proper user-oriented documentation for NoScript 10; but maybe we can start here by providing a minimalistic overview, mapping the new "Quantum" UI onto the "Legacy" (I actually prefer to call it "Classic") one:

In the NoScript 10 we've got 3 presets (DEFAULT, UNTRUSTED and TRUSTED): you can assign one of them to any site, and the sites with the same preset share the same set of (configurable) permissions

For sites that don't fit in any of the 3 aforementioned presets, you can choose to use CUSTOM permissions: CUSTOM is not a preset, but a way to give very specific permissions to a site, applying to that site only

Back to presets, DEFAULT is the set of permissions that any unknown site has. So if you don't touch NoScript, beside a handful of websites (the "old" default whitelist) pre-assigned with the TRUSTED preset, all the sites on the Web have the permissions of the DEFAULT preset (i.e. almost none).

"Temporary allow xyz.com" maps to clicking the TRUSTED preset on the xyz.com row.

"Forbid xyz.com" maps to clicking the DEFAULT preset, which actually means deleting the site from the internal "whitelist". In facts, if you do it in the general Options panel, next time you open the panel (or refresh it) the site is not even listed there anymore. It doesn't disappear right away for convenience, to give you the chance to change your mind or correct mistakes.

"Mark xyz.com as untrusted" maps to clicking the UNTRUSTED preset, which contains no permission at all and is meant to collect and remember the "known bad sites" in a permanent blacklist.

And then CUSTOM, which is new to NoScript 10 and lets you fine tune just a certain website with its own specific permissions, either more restrictive than DEFAULT or more permissive than TRUSTED ; this tuning is either permanent (by default, the clock shaped icon in this case comes disabled) or temporary, by additionally clicking the clock-shaped icon.

Each and all the presets can be freely customized to your own needs, with the convenience constraint that you cannot remove the "script" permission from TRUSTED, and you cannot add it to UNTRUSTED. However, the factory presets are very similar to the "old" NoScript experience.

What about the "Match HTTPS only" green/red lock toggle? If green (locked), the toggle makes base domain entries (e.g. "..google.com") match themselves and all their subdomains, but only if their protocol is HTTPS (and therefore the traffic encrypted and not easily tampered with). Otherwise, if red and unlocked, both HTTP and HTTPS match: this has bad security implications especially on "hostile" networks where injecting malicious scripts directly in the unencrypted traffic is relatively easy, but is unfortunately needed for some sites to work. NoScript tries to gives you the "smartest" default for each site, i.e. green if the page is already served on HTTPS, red otherwise.

A lot more needs to be written yet, but these are the bare bones.
If you find bugs or need support, rather than using in the blog comments or, even worse, the AMO review system as a way to communicate with developers, please submit to the support forum here.

And if you want to help me with development, please install latest development build, which is released even more often than the stable and ships earlier both bug fixes and new features. And please keep providing feedback, as especially the UI is still a work in progress and I'm eager to make it better than before, by merging as much as possible of your valuable contributions.

Later today In a couple of days, if everything goes fine, and definitely by the end of this week, NoScript 10, the first "pure" WebExtension NoScript version, will be finally released for Firefox 57 and above, after years of work and months NoScript 5.x living as a hybrid one to allow for smooth user data migration.

NoScript 10 is very different from 5.x: some things are simpler, some things are improved, some are still missing and need to wait for WebExtensions APIs not available yet in Firefox 57. Anyway, whenever you decide to migrate, your old settings are kept safe, ready to be used as soon as the feature they apply to gets deployed.

If you're not bothered by change, you're ready to report bugs* and you're not super-paranoid about the whole lot of "NoScript Security Suite" most arcane features, NoScript 10 is worth the migration: active content blocking (now more configurable than ever) and XSS protection (now with a huge performance boost) are already there. And yes, Firefox 57 is truly the most awesome browser around.

If, otherwise, you really need the full-rounded, solid, old NoScript experience you're used to, and you can't bear anything different, even if just for a few weeks, dont' worry: NoScript 5.x is going to be maintained and to receive security updates until June 2018 at least, when the Tor Browser will switch to be based on Firefox 59 ESR and the "new" NoScript will be as powerful as the old one. Of course, in order to keep using NoScript 5.x outside the Tor Browser (which has it built-in), you have to stay on Firefox 52 ESR, Seamonkey, Palemoon or another pre-Quantum browser.Or you can even install Firefox 58 Developer Edition, which allows you to keep NoScript 5 running on "Quantum" with the extensions.legacy.enabled trick. Just please don't block your updates on Firefox 56, it would be bad for your security.

Let me repeat that: your safest option for the next few days is Firefox 52 ESR, which will receive security updates until June 2018.

So, for another half-year you there will be two NoScripts: just sort your priorities and choose yours.

Update 2017-11-15

As you probably noticed, yesterday's today has gone away in most time zones and we're not ready yet (Murphy law and all) :(
But we're definitely on track for the end of this week, and in the meanwhile your awesome patience deserves a couple of preview screenshots...

It's a story of FUD and sensationalism, which got reported in such a careless way that now makes explaining and correcting readers' perception an uphill battle.
They've just demonstrated that rather than invoking a low-level function directly, like any installed add-on could do anyway, a malicious Firefox extension that has already been approved by an AMO code reviewer and manually installed by the user can invoke another add-on that the same user had previously installed and perform the low-level tasks on its behalf, not in order to gain any further privilege but just for obfuscation purposes.

It's like saying that you need to uninstall Microsoft Office immediately because tomorrow you may also install a virus that then can use Word's automation interface to replicate itself, rather than invoking the OS input/output functions directly. Or that, for the same reasons, you must uninstall any Mac OS application which exposes an AppleScript interface.

BTW, if you accept this as an Office or AppleScript vulnerability, Adblock Plus is not less "vulnerable", so to speak, than the other mentioned add-ons, despite what the article states. It's just that those "researchers" were not competent enough to understand how to "exploit" it.

And I'm a bit disappointed of Nick Nguyen who, rather than putting some effort in rebutting this cheap "research", chose the easier path of pitching our new WebExtensions API, whose better insulation and permissions system actually makes this specific scenario less likely and deserves to be praised anyway, but does not and could not prevent the almost infinite other ways to obfuscate malicious intent available to any kind of non-trivial program, be it a Chrome extension, an iOS app or a shell script. Only the trained eye of a code reviewer can mitigate this risk, and even if there's always room for improvement, this is what makes AMO stand out among the crowd of so called "market places".

Since last time I wrote about WebExtensions, a lot has been going on: for instance, I used to link a Mozilla Wiki article, and as you can see now I'm linking a full featured MDN entry :)

In the meanwhile, I've been among other things hacking the WebExtensions code itself to make it suitable for eventually porting my own extensions, NoScript and FlashGot, and all those which share similar requirements.

The key WebExtensions API needed by adblockers (one of the most popular browser extensions category), by anti-trackers like Ghostery and, of course, by security add-ons like NoScript, is WebRequest. Its first implementation as a JavaScript module (still the foundation of the current one, which is a thin wrapper over it) even predates WebExtensions themselves: genius e10s hacker Bill McCloskey started it as a brave experiment to see how realistic could have been migrating Adblock/Ghostery/NoScript to the still just rumored "next thing" in add-on development.

Unfortunately, the way this API was originally implemented imposed harsh limitations, both in Chrome compatibility and, more annoyingly, in suitability for the very kind of add-ons it was meant to support. But we've got good news: I've recently landed a couple of patches (after a long time spent away from Mozilla's code repositories), paving the way to the removal of the remaining Chrome incompatibilities and for the addition of new divergent features required by NoScript & Co. which by the way, if ever borrowed in Chromium, could even finally make a NoScript porting on Google's browsers and derivatives possible.

An "origin" property, which is required not just by many features of NoScript's but also by other add-ons such as RequestPolicy.

I'm very satisfied with the work done so far, and as soon as the 3 features above are completed, I'm ready to take on other areas where the Chrome extensions API (hence, for obvious reasons, WebExtensions in their present state) are severely lacking, such as script execution control and fine-tuned content blocking, which still prevent NoScript from migrating.

During the past weeks I've grown intimate with the WebExtensions API source code and familiar enough with the "modern" Firefox development workflow. I'm sure this incoming spring will be a most interesting time, and I'm confident that summer will come with a brand new NoScript, reborn as a WebExtension :)