Haketilo

# Comparison with other extensions

The functionality of Hachette partially overlaps with that of other extensions. None of those, however, is sufficient for our goal of liberating the web and hence the need to create a new one.

{{toc}}

## LibreJS

Of existing extensions this seems to be the only one with a software-freedom-oriented goal. It inspects sites' scripts in search of license notices in a specified format. If it decides a given script is libre software, it allows it to run.

### Minor shortcomings

LibreJS supports Firefox-derived browsers. It uses Mozilla-specific WebExtensions APIs, so it is not portable to other browser families.

One sad issue is that many webmasters fail to properly tag the libre scripts they use and due to that LibreJS also fails to allow them to run. This is, however, the fault of those who don't want to cooperate, with some blame perhaps going to the fact that the FSF's message is unappealing to most of them. The extension has also been accused of being too much of a hassle for web developers to comply with.

Another problem is LibreJS' failure to block scripts on pages opened from `file://` and `ftp://`, and perhaps other protocols. This is because it relies on webRequest API to rewrite document contents and webRequest only works with HTTP(S).

### Concept issue

The shortcomings described so far do not yet disqualify LibreJS. What does is its concept. Unfortunately, surprisingly many people still think LibreJS' approach is the right one and consider the extension a proper measure against proprietary scripts. You will do good if you present LibreJS advocates with the following argument.

The approach of allowing scripts based on just license notices is not sufficient. The current state of technology does not yet allow for "freeness" to be verified automatically. LibreJS' strategy of judging scripts based on a license notice fails for example when someone takes an X11-licensed js library, modifies it and serves a minified version of the modified lib on their site. LibreJS will allow this script to execute, even though the modifications are obviously nonfree.

We could theoretically and with great effort cope with that by always (for minified scripts) checking whether a non-minified version is available and then verifying that it corresponds to the minified version that was served. That would of course require the minification process to be reproducible because verification of programs' equivalence is not solvable in general. This would result in even more burden on webmasters who never wanted to cooperate anyway. And existence of other languages that compile to javascript makes the problem even more complex. One *partial* solution is to collect hashes of known minified libre javascript libraries and allow these to execute. This, however, does not by itself help the situation.

So, even though minified scripts by themselves are not unethical, we're reaching the conclusion that they are problematic. One solution would then be to only allow non-minified and non-obfuscated scripts to run. Are we able to automatically determine whether a script is minified or not? Maybe. Whether a script is obfuscated in some other way? No chance.

A significantly bigger problem is the fact that bypassing LibreJS' countermeasures - if the extension ever gets popular enough for it to be worth doing - would be trivial for a malicious website. The site could just put a GPL license string on an arbitrary piece of malicious js just to get it executed on one's computer.

Additionally, a website could be for example mining crypto in users' browsers using fully libre js. Even when that's not illegal, we still want to be able to block the miner. This issue is not as severe as it's only a missing feature in LibreJS and could be solved by installing some adblocker along it. However, it might be worth mentioning. In general, executing all scripts from unknown sites is a bad idea, even when the scripts are libre. Let's assume we have a GNU/Linux distro that allows everyone who owns a domain to add packages to it. Without any human verification. Would it be a secure, stable and modular distro? Would one like to use it? Would FSF recommend such distro? (thanks to Trisquel forum user Chaosmonk for coming up with the distro allegory) That's more or less what LibreJS is doing right now, with the exception that browser's sandbox makes it a little more secure... But having in mind Meltdown and Spectre, and also the fact most browser vulnerabilities these days rely on js, we shouldn't consider sandbox a solution.

Last but not least, as RMS also noted in his essay, the freedom resulting from being granted a license to use, modify and share a script is only a theoretical one. As long as there is no facility to run a modified version of the script instead, the freedom LibreJS tries to provide is on paper only. This might also be the reason some people, and among them the uncooperative webmasters, disregard LibreJS. Because they realize this, some maybe even unconsciously.

### Potential usefulness

Despite what has been said, not everything concerning LibreJS is bad. It is still important to call for website operators to release their js as libre software and flag it as such, this would later make it easier to integrate such scripts with our extension. Having webmasters follow a strict procedure of indicating javascript licenses is fortunately no longer relevant for our extension as it used to be with LibreJS.

Also, LibreJS code responsible for allowing just the trivial js to execute could be worth re-using. It is worth noting that LibreJS' codebase is small and relatively easy to understand.

## NoScript

NoScript is an extension often used as a content blocker, but it actually does a bit more and is more properly described as a security suite. It can be used to block scripts on per-site basis and works with both Firefox- and Chromium-derived browsers. NoScript author, Giorgio Maone, has also worked on LibreJS as an FSF contractor.

NoScript, while sometimes useful for the task of blocking nonfree javascript, is not by itself fully freedom-oriented and for example has youtube.com in its default site whitelist. NoScript's codebase is rather complex and hard to read.

## uBlock Origin

Often abbreviated as "UBO", uBlock Origin is a selective content blocker. It gives quite fine-grained control over what kinds of elements are allowed to load, including the possibility of blocking third-party resources on a per-domain basis. Both Firefox and Chrome are supported.

UBO is able to load and apply adware and spyware blacklists from several sources, which makes it able to function as an ad-blocker. However, what's more relevant for people who want to block all nonfree javascript is that UBO's codebase, although big, is rather clean and readable.

## uMatrix

This extensions is UBO's twin. Developed by the same author, these 2 share part of their codebase. While UBO can be used rather easily, uMatrix was a content blocker aimed at more advanced users. Unfortunately, uMatrix is unmaintained as of 2021.

## Greasemonkey

The extensions discussed so far have all been content blockers. Greasemonkey, on the other hand, makes it possible to execute custom scripts on websites. These are usually referred to as "user scripts" and there are even sites (well, at least one) for sharing these between users. Greasemonkey only supports Firefox-derived browsers. While a compatible extension called Tampermonkey exists that works on Chrome, it has been proprietary since 2016.

People often point at Greasemonkey as a possible solution when told about the need for a facility to replace sites' native javascript. Indeed, Greasemonkey could be used to achieve that. The fact that it doesn't block the original scripts is a small problem, giving the necessity of running some content blocker next to it. While generally suboptimal, this setup would be acceptable as a temporary solution. What makes Greasemonkey unsuitable in the long term is the fact it doesn't execute user scripts in the context of a page but rather in the more privileged context of WebExtensions content scripts. This has security implications and leads to incompatibilities with scripts failing to execute the way they would in the usual context.