Avian’s Blog

I am a long time user of NoScript Firefox extension. I find it's an effective cure for obtrusive advertisements and weird page features, plus it gives me the feeling that I can still control who can execute code on my computers. I also hate being tracked by various bugs embedded in pages and NoScript allows me to block those iframes and scripts that send information about my visit to third parties.

It's not perfect (what is on the web today?) but in my experience the domain based blocking of Javascript seems to be an effective heuristic against unwanted content. Plus in contrast to various other ad- and tracking-blocking extensions it's very simple to temporarily or partially disable the block should I stumble upon a page that absolutely requires some piece of Javascript.

Unfortunately NoScript took a path all to many software projects take. From doing a simple task of blocking script execution it grew into a giant that wants to solve all of the browser-related security problems. That by itself isn't such a bad thing, but such complexity invariably leads to problems and it's those that are starting to annoy me.

For instance, NoScript nowadays comes with some heuristical algorithms for preventing XSS. As far as I know, they have yet to save me from malicious content, but are constantly breaking legitimate scripts like Instapaper, even when I put it on all white lists I can find. Same goes for something called ABE, which constantly prevents me from following links to servers on my local network. Again, it might prevent attacks against my local routers, but security that constantly gets in your way is worthless.

These two annoyances however at least identify themselves by descriptive error messages. Lately, some web applications started to repeatably break when NoScript is enabled without as much as a warning. One thing I found for instance is that NoScript will silently block Javascript that is served as MIME type text/plain. How that could be a security risk, I don't know. But it appears a few legitimate sites have misconfigured servers that do that.

As I've been looking a bit more closely at this project, I discovered another surprising thing: while the code is indeed released under a free license, the development process is all but open. There is no public source repository. There is no bug tracker. There is even no mailing list. All you get is a web forum and a bunch of XPI files that you can decompress to get to thousands of lines of dense Javascript code. You don't get any scripts for instance that are surely used in the release process to generate some files and pack all the parts into the XPI file itself. For a security oriented project, that is quite unusual to say the least.

Now I hate to only give criticism and not offer any solutions. Unfortunately my experience with Firefox extensions is limited to some prehistoric version and I have neither the time nor will to refresh it enough to be able to look into any of the bugs I described above. I know there are many talented Javascript developers out there that are more than capable of making a better NoScript, but the closed nature of this extension makes it hard to make a fork.

So I decided to rather donate some of my time to help with that last problem. I downloaded the complete history of stable and development NoScript releases from addons.mozilla.org and committed them to a GitHub repository. Using their API I also set in place a mechanism that will automatically update the repository with new releases, hopefully with minimal maintenance from my side. I also added a simple script that can be used to create an XPI file from code in the repository that should be nearly identical to official releases (except for author's cryptographic signature, of course).

As usual, you can check it out with a command like this:

$ git clone https://github.com/avian2/noscript.git

This also has a useful side effect in that it makes the original upstream development somewhat more transparent. With a diff between two releases one click away on GitHub, you can check the changes between two releases yourself. With a tool like that undesirable changes like NoScript messing with Adblock Plus back in 2009 might have been discovered earlier.

And finally, having all of NoScript history in git means you can easily create nice graphs in a few key strokes (courtesy of gitstats). Enjoy.

Number of releases of NoScript per month (note that for releases earlier than 2007 I don't have information of their exact date hence the spike on the graph)

Number of files in NoScript XPI through time

Lines of code in NoScript through time

1) I've just tried InstaPaper, and I managed to save and retrieve 3 web pages without a single issue. If you still find any, could you please report them at http://noscript.net/forum ?

2) Strict checks on script and CSS content-types have been pioneered by NoScript and are being adopted by mainstream browsers, in order to prevent user-provided content from being reinterpreted as scripts. This obviously breaks stuff like using github as a CDN, but this is a stupid idea in first place (would you trust a site whose scripts can be uploaded by anyone?) and does not work even on recent IE versions: http://blogs.msdn.com/b/ieinternals/archive/2010/09/27/ie9-beta-google-image-search-javascript-content-type-and-nosniff.aspx

3) Regarding the ability of following links from an internet web page to LAN resources, ABE at least gives you the ability to add exceptions to its LOCAL rule for cross-zone CSRF protection (see http://noscript.net/faq#qa8_4 and following). I'm afraid Opera's built-in (and less effective) feature doesn't allow this level of control, nor will the upcoming Firefox's: https://bugzilla.mozilla.org/show_bug.cgi?id=354493

That said, feel free to fork a lighter unsafe script blocker, and keep to NoScript the tagline "The Best Security you can get in a Browser" :)

Thanks for clarifications. Instapaper has been working on and off for me during the last few Noscript releases. I'll make a note to report it to your forum the next time it breaks, but the point I was trying to make is that perhaps an approach to security that breaks so many times isn't one worth taking.

Regarding the second point, you should really provide some feedback to the user. I expect that when Noscript doesn't report an error or blocked elements the page works as if the extension isn't there. Silently breaking pages just makes for a lot of annoyance and unreproducible bug reports to web developers.

Thanks for taking the time to make this available. Code history is
valuable; I had done the same thing with Nginx releases up until the
author decided to publish an official SVN repo.