The problem

Google's "Manifest V3" ongoing API changes are severely hampering browser extensions in their ability to  block unwanted content and to enforce additional security policies, threatening the usefulness, if not to the very existence, of many popular privacy and security tools. uBlock's developer made clear that this will cause him to cease supporting Chromium-based browsers. Also EFF (which develops extensions such as HTTPS Everywhere and Privacy Badger) publicly stigmatized Google's decisions, questioning both their consequences and their motivations.

NoScript is gravely affected too, although its position is not as dire as others': in facts, I've finished porting it to Chromium-based browsers in the beginning of 2019, when Manifest V3 had already been announced. Therefore, in the late stages of that project and beyond, I've spent considerable time researching and experimenting alternate techniques, mostly based on standardized Web Platform APIs and thus unaffected by Manifest V3, allowing to implement comparable NoScript functionality albeit at the price of added complexity and/or performance costs. Furthermore Mozilla developers stated that, even though staying as much compatible as possible with the Chome extensions API is a goal of theirs, they do not plan to follow Google in those choices which are more disruptive for content blockers (such as the deprecation of blocking webRequest).

While this means that the future of NoScript is relatively safe, on Firefox and the Tor Browser at least, the browser extensions APIs and capabilities are going to diverge even more: developing and maintaining a cross-browser extension, especially if privacy and/or security focused, will become a complexity nightmare, and sometimes an impossible puzzle: unsurprisingly, many developers are ready to throw in the towel.

What would I do?

NoScript Commons Library

The collection of alternate content interception/blocking/filtering techniques I've experimented with and I'm still researching in order to overcome the severe limitations imposed by Manifest V3, in their current form are best defined as "a bunch of hacks": they're hardly maintainable, and even less so reusable by the many projects which are facing similar hurdles. What I'd like to do is to refine, restructure and organize them into an open source NoScript Commons Library. It will provide an abstraction layer on top of common functionality needed to implement in-browser security and privacy software tools.

The primary client of the library will be obviously NoScript itself, refactored to decouple its core high-level features from their browser-dependent low-level implementation details, becoming easier to isolate and manage. But this library will also be freely available (under the General Public License) in a public code repository which any developer can reuse as it is or improve/fork/customize according to their needs, and hopefully contribute back to.

What do I hope?

Some of the desired outcomes:

  • By refactoring its browser-dependent "hacks" into a Commons Library, NoScript manages to keep its recently achieved cross-browser compatibility while minimizing the cross-browser maintenance burden and the functionality loss coming from Manifest V3, and mitigating the risk of bugs, regressions and security flaws caused by platform-specific behaviors and unmanageable divergent code paths.
  • Other browser extensions in the same privacy/security space as NoScript are offered similar advantages by a toolbox of cross-browser APIs and reusable code, specific to their application domain. This can also motivate their developers (among the most competent people in this field) to scrutinize, review and improve this code, leading to a less buggy, safer and overall healthier privacy and security browser extensions ecosystem.
  • Clearly documenting and benchmarking the unavoidable differences between browser-specific implementations help users make informed choices based on realistic expectations, and pressure browser vendors into providing better support (either natively or through enhanced APIs) for the extensions-provided features which couldn't be optimized for their product. This will clearly outline, in a measurable way, the difference in commitment for a striving ecosystem of in-browser security/privacy solutions between Mozilla and other browser vendors, keeping them accountable.
  • Preserving a range of safe browsing options, beyond Firefox-based clients, increases the diversity in the "safe browsing" ecosystem, making web-based attacks significantly more difficult and costly than they are in a Firefox-based Tor Browser mono-culture.

I want you!

Are you an extensions developer, or otherwise interested in in-browser privacy/security tools? I'd be very grateful to know your thoughts, and especially:

  1. Do you think this idea is useful / worth pursing?
  2. What kind of features would you like to see supported? For instance, content interception and contextual blocking, filtering, visual objects replacement (placeholders), missing behavior replacement (script "surrogates"), user interaction control (UI security)...
  3. Would you be OK with a API and documentation styles similar to what we have for Firefox's WebExtensions?
  4. How likely would you be to use such a library (either for an existing or for a new project), and/or to contribute to it?

Many thanks in advance for your feedback!

As you may have noticed, NoScript Quantum's placeholders for blocked embeddings has an animation moving the NoScript snake icon from the center to the top left side when you hover it, in order to make the label more readable.
Some people can find this annoying, but fortunately in WebExtensions everything is made of standard web stuff, like HTML and CSS, and it's relatively easy to change the placeholder to any appearance you prefer.
In this case, to make it static and discreet, you could use the Stylus extension to create a new "Static NoScript Placeholder" with all the default settings and this content:

a.__NoScript_Placeholder__ {
    background-size: 64px !important;
    background-position: 0 0 !important;
    transition: none !important;
}

I'm pleased to announce that, some hours ago, the first public beta of cross-browser NoScript (10.6.1) passed Google's review process and has been published on the chrome web store.
This is a major milestone in NoScript history, started on May the 13th 2005 (next year we will celenbrate our 15th birthday!). NoScript on the chrome web store

Over all these years NoScript has undergone many transformations, porting and migrations:

  • three distinct Android portings (one for Fennec "classic", one for Firefox Mobile, the last as a WebExtension);
  • one partial rewrite, to make it multi-process compatible;
  • one full, long and quite dramatic rewrite, to migrate it to the WebExtensions API (in whose design and implementation Mozilla involved me as a contributor, in order to make this possible).

And finally today we've got an unified code-base compatible both with Firefox and Chromium, and in possibly in future with other browsers supporting the WebExtensions API to a sufficient extent.
One difference Chromium users need to be aware of: on their browser NoScript's XSS filter is currently disabled: at least for the time being they'll have to rely on the browser's built-in "XSS Auditor", which unfortunately over time proved not to be as effective as NoScript's "Injection Checker". The latter could not be ported yet, though, because it requires asynchronous processing of web requests: one of the several capabilities provided to extensions by Firefox only. To be honest, during the "big switch" to the WebExtensions API, which was largely inspired by Chrome, Mozilla involved me in its design and implementation with the explicit goal to ensure that it supported NoScript's use cases as much as possible. Regrettably, the additions and enhancements which resulted from this work have not picked up by Google.

Let me repeat: this is a beta, and I urge early adopters to report issues in the "Support" section of the NoScript Forum, and more development-oriented ones to file technical bug reports and/or contribute patches at the official source code repository. With your help as beta testers, I plan to bless NoScript 11 as a "stable Chromium-compatible release" by the end of June.

I couldn't thank enough the awesome Open Technology Fund folks or the huge support they gave to this project, and to NoScript in general. I'm really excited at the idea that, under the same umbrella, next week Simply Secure will start working on improving NoScript's usability and accessibility. At the same time, integration with the Tor Browser is getting smoother and smoother.

The future of NoScript has never been brigther :)

See also ZDNet's and GHacks' coverage of the announcement.

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...
10157-options.png

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.
  • "Allow xyz.com" (permanently) maps to clicking the clock-shaped icon onto the TRUSTED preset (which means "Temporary"), to disable it (and make the preset assignment "Permanent")
  • "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.

Thank you all!

« Previous Entries

Bad Behavior has blocked 1311 access attempts in the last 7 days.