hackademix.net

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.
• "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!

Just released 10.1.5, and its changelog start to taste familiar, with names already well known in NoScript's development history, likw Masato or Mario:

v 10.1.5
=============================================================
+ [XSS] Added "Always block requests from ... to ..." in XSS
  warning prompt
x [XSS] Fixed url decoding bug (thanks Masato Kinugawa for
  reporting)
x Fixed some blocked items not reported in the UI (thanks Bo
  Elam for reporting)
x Changed the CSP internal report URI to noscript-csp.invalid
  (thanks Tom Schuster  Mario Heiderich for RFE)
- Removed unused MSE detection code (thanks Rob Wu for
  reporting)

From an usability standpoint, the biggest new is that now you can silence the XSS filter not just whitelisting ("Always allow requests from... to...") but also blacklisting ("Always block...").
Of course, much more to come in the next days and weeks...

NoScript Quantum 10.1.4 is out, and while it might seem a fairly minor release, it does fix some performance issues under the hood and a quite annoying bug making maximized windows "jump down" when you open the NoScript UI. Talking of which, now that these back-end cleanup is done, I can finally give some more love to all the suggestion about improving usability that you kindly provided so far.

Starting with the XSS popup, which unfortunately cannot be an "old style", interactive but out of your way, notification anymore because of limitations in the WebExtensions (I cannot even open the NoScript menu programmatically, it must be reacting to user's input); but can, for instance, include an "always block requests from a.com to b.com" to make it less noisy.

Thank you also for all the UI prototypes and wireframes you've sent, I'm gonna start trying merging some of these ideas right away :)

You may have noticed I'm rapid-firing NoScript updates to steer the new UI toward most reasonable directions emerging from your feedback.
Unfortunately (or not, in time) it couldn't ever be exactly the same as before, simply because the underlying "legacy" Firefox technology (XUL/XPCOM) is not available to extensions developers anymore. But it can become even better than before, with some patience and some.
Now to the pains.
This morning version 10.1.3rc2 has been available for a couple of hours, with some important fixeds but an even more annoying regression: it erased all permissions from the TRUSTED preset except for "script" (so no objects, no media, no fonts, no background loads and so on). Worse, the checkboxes to restore them were disabled. Since then I've released 10.1.3RC3 which fixes the disabled checkboxes issue, but you still need to restore the TRUSTED permissions (I suggest to check everything, like in the screenshot before, in order to make TRUSTED sites behave as if NoScript wasn't there).
Sorry for the inconvenience, and please keep the suggestions coming, thank you.