NoScript is the long-running browser extension that adds protection, not trust

The README is a business card, not a manual

The most striking thing about this repository is how little the README says about the software. It is titled NoScript Security Suite and described in one line as free open source software providing extra protection for various browsers, with a link to the project site at noscript.net. There is a licence badge, a release badge, four browser badges, and a security reporting section. There is no feature list, no configuration guide and no changelog in the README, which is unusual for a project of its age and size, and it tells you where the documentation actually lives. The site is the manual, the repository is the source, and the audience that needs to be convinced is not reading this file. The copyright header names Giorgio Maone and carries an SPDX identifier of GPL-3.0-or-later, and the project is hosted under the hackademix organisation, with the site itself at noscript.net.

Four browser targets, including the Tor Browser

The supported platforms are listed with icons rather than prose, and they are Firefox, Firefox Mobile, Chromium and the Tor Browser. The last of those is the most interesting choice, since a script-filtering extension has to coexist with a browser built to be modified as little as possible. The set also spans the two architectures of extension, with the manifest-based WebExtensions model in Firefox and Chromium, and a mobile target where the extension runs on a phone's browser rather than a desktop. The repository has a manifest.js at the root and a manifest.sh next to it, which is the shape you would expect for a project that has to emit a different extension manifest per target, and the.gitmodules file points to submodules, which is where the bundled code that is not written in this repository is likely to live.

Security reports go by encrypted mail, and the target is hours

The security policy is short and specific. The project says it strives to fix security sensitive issues in the shortest time possible, hours ideally, while protecting users, and asks for reports to be sent privately to [email protected]. The next instruction is the one that tells you how seriously the project takes the process, that to ensure confidentiality and protect users, the report should be encrypted with a PGP key, and the key fingerprint is given in the README:

3359 0391 70A3 CD9B 25CF 5A46 231A 83AF DA9C 2434

Plain text email to a security mailbox is the norm and is a real weakness, because a mail server compromise, a forwarding rule or a shared inbox exposes an unpatched vulnerability to whoever reads it. Asking for encryption is the project accepting that responsibility, and publishing the fingerprint in the README is how you check that you are encrypting to the right key. For a project with a two-decade history, a fast and confidential disclosure channel is one of the more valuable things it can offer, and it is a better argument for the extension than any feature comparison.

A release stream measured in build numbers

The release history is dense and the version numbering is unusual. The three most recent releases are 13.6.36.902 published on 2026-10-05, 13.6.36.901 on 2026-10-04, and 13.6.36 on 2026-10-01, and the last push was on 2026-10-05, the same day as the newest build. A four-part version with a trailing counter like 902 is the signature of a project that ships continuously, where the trailing number distinguishes two builds of the same browser release that differ only in packaging or in a fix applied late. The release badge in the README points at the GitHub releases page, and the browser stores are the distribution channel that matters, since a project of this kind is delivered through Firefox Add-ons, the Chrome Web Store and the Android ecosystem rather than by download. The consequence for a user is that updates are frequent and mostly invisible, and the consequence for a security researcher is that there is always a current build to test against.

The repository is build machinery, not application code

The top-level entries describe a build pipeline rather than a source tree of JavaScript modules. There is build.sh at the root, alongside manifest.sh which generates manifest.js, and optimize.js, which is a build step for the bundled assets. There is reuse.sh, and a .reuse/ directory, which is the tooling for REUSE compliance, the practice of recording every file's licence and copyright in machine readable form, and it is backed by a LICENSES/ directory and a COPYRIGHT file. That combination is how a project with a long history and contributions from many people keeps its licence metadata straight, and it explains the presence of both LICENSE and LICENSES/ at the root. There is nscl_gitsync.sh, a script for synchronising the project site content, which fits a project whose documentation and downloads live on its own domain rather than in the repository. The src/ directory holds the extension sources, tools/ holds the utilities, TLD/ holds a list of top level domains, and html5_events/ holds the page event handling.

Translations, domains and the wider context of the project

Two directories reveal the operational side. The .tx/ directory is a Transifex configuration, which is how the user interface gets translated into many languages by volunteers, and it is the mechanism behind a browser extension reaching users who do not read English, which is a large part of its audience. The TLD/ directory holds a list of top level domains, and a top level domain list is the kind of data a security extension needs, because the set of domains that can host a tracker or an attack changes constantly and cannot be written down by hand. The repository's topic tags place the project in a particular line of work, with meltdown, noscript, spectre, trust and xss among them, which is the set of browser side risks that a script and permission focused extension exists to reduce, and it connects the project to the wider history of browser side channel and cross site scripting work rather than to the content blocking category that similar extensions are usually filed under. That distinction matters when you evaluate it, because the two categories solve different problems.

Where NoScript is the wrong tool

There are three honest reasons to skip it. The first is redundancy, and it is not a small one. Installing an extension on top of the Tor Browser, which is designed to be modified as little as possible, works against its design. The second is the cost of the feature set itself. An extension that restricts what a page may do breaks sites, and a project of this kind spends a lot of its effort on per-site exceptions, which is exactly the work a general purpose blocker with a large community and a friendly interface does better. The third is the delivery channel. On Chromium, an extension of this complexity is distributed through a store with its own review, its own update delays and its own telemetry, none of which the project controls, and the Firefox and Chromium builds are therefore not the same product in practice. None of this makes the project bad. It makes it a specialist tool for people who have decided that the defaults of their browser are not acceptable and are prepared to deal with the consequences.

Editorial conclusion

NoScript is a project to watch if you care about the long tail of browser side issues, because it has been maintained continuously for two decades by one author, it ships across four browser targets including the Tor Browser, and it treats security reports as confidential work with a PGP key and a stated ambition of hours rather than weeks. It is the wrong tool if you want a general content blocker with a friendly interface, because the project has no marketing to speak of and its documentation lives outside the repository. Before adopting it, read the documentation on the project site rather than the repository, check whether the Chromium build meets your needs, since extension stores apply their own review, and test it on a browser where you can easily turn it back off.

Frequently asked questions

Official sources

1. hackademix/noscript on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases