JavaScript, the Web Browser, and Computing Freedom

What is JavaScript?

JavaScript is a computer programming language which is commonly used to run programs from inside a Web browser.

How does JavaScript relate to Web browsing?

The default configuration of most common Web browsers is to automatically download and execute JavaScript referenced by a Web page document. The JavaScript is either embedded in the document or linked to from the document, using special HTML tags. In other words, when you point your Web browser at a particular Web address (URI) the Web browser will not only download a Web page, but it will also download all JavaScript code the Web page tells it to download, and it will automatically execute that code.

Your Web browser as an operating system for JavaScript

In the above scenario, which is the usual situation these days (2021) your Web browser effectively becomes a miniature operating system designed to run JavaScript programs and display the output of those programs. Your Web browser provides the code with access to your computer's memory and processing power, the ability to manipulate the structure and content of the Web document you are viewing, and the ability to communicate with other computers, such as the Web server that provided you with the JavaScript originally.

Essentially, it is the default operation of Web browsers to give control of your computer over to the JavaScript program that has been downloaded when you visit the Web site. Ideally, the Web browser puts some tight controls over what the JavaScript is and is not allowed to do, but this control occurs mainly on a low level (the API) and often has weaknesses which result in security vulnerabilities.

Why is this a problem for computing freedom?

Silent and sneaky acceptance of proprietary software

Before this model of using JavaScript became commonplace, the battle over user freedom was more straightforward: to install some proprietary software on your computer, you would usually need to deliberately install the software, e.g., by running an installation program. Then usually the program would ask you to agree to some End User License Agreement, enumerating all the rights you were giving up in order to use the program. There were word processors, games, tax software, etc.

In the new paradigm, we do more and more of our practical computing on Web sites that are really JavaScript software running in your browser. E.g., you would go to a Web site to play a game, type up a document, do your taxes, etc.

Since the JavaScript is downloaded and executed automatically, you have no opportunity to inspect the software license of the program you are running. It might be proprietary software, it might not be, or it might be some mixture of both. If the program output is not too dynamic, you might not even realize you are running a program at all.

The GNU project attempts to deal with this problem with a browser plugin called LibreJS. LibreJS inspects the incoming JavaScript to determine whether or not a free software license has been attached to the JavaScript file, and if not, blocks the JavaScript from running.

LibreJS

The Javascript Trap

No version control or package management

While LibreJS is a great tool for promoting the use of free software JavaScript[1] it unfortunately does not solve the most fundamental problem of the JavaScript/Web paradigm. In order for you to be in control of your computing, which is the fundamental goal of the free software movement, you must be able to have full control over what code is running on your computer (including inside your Web browser.) However, every time you visit a Web site, the remote Web server is given a new opportunity to provide any new version of the JavaScript code, which your Web browser will automatically accept and execute. The first time you visit a Web site, you could carefully inspect every line of JavaScript code (using your browser's page source viewer) to see what it does, and carefully inspect every license attached to the JavaScript; but next time you visited the site, some or all of the code may have changed. You are given no choice in the matter. Even when using a plugin like LibreJS, you really have no idea what code is going to be running next time you visit the site.

To overcome this problem, somebody would need to invent some kind of JavaScript package management system for Web browsers. This system would need to:

- keep track of which version of the JavaScript you ran last time you visited the Web site, either by keeping a local copy of the code, or just checksums and version numbers.

- show you the licensing attached to the new version

- ask you whether you want to load the old version or the new version (or none at all)

So far as I know, there is no project anywhere attempting to build such a package management system. Since I am not a JavaScript programmer, I also do not know clearly all the technical obstacles that would need to be overcome. I think some cooperation would be required from the remote Web server as well, so that might be an obstacle, though I think it would be better at first to have just a few Web sites utilizing JavaScript package management, than none at all.

UPDATE: There is now the Haketilo project, "a browser extension that facilitates viewing of websites while having their original JavaScript replaced by user-provided scripts".[3]

Software as a document substitute

If you choose not to run any JavaScript while browsing the Web, e.g., by using the NoScript plugin, you will quickly notice you cannot view the content of many Web pages. This is because the Web site has been set up so that, in order to view the content, you must download a JavaScript program and execute the program, and then the program will fetch the Web site content and build it into a readable Web page.

NoScript

This is terrible because, as this practice becomes more popular, the people who value freedom in computing slowly lose access to more and more information on the Internet. The World Wide Web, instead of being a place where information is easily shared and exchanged by all, becomes many walled gardens of JavaScript, where each plot is owned by some JavaScript content delivery system, possibly proprietary, possibly not. To access some bit of information you want on a Web site, even if the information itself is meant to be freely available, you must be able and willing to run the latest JavaScript program thrown at you on that day from that Web server.

This, incidentally, greatly restricts your choice of Web browsers, because you must have a Web browser that runs all the JavaScript programs correctly, behaving in the way that the JavaScript programmers expect, without exposing any security vulnerabilities, which is not trivial. This is the case even if you just want to view some cooking recipies or read a tutorial. There are very few Web browsers that can pull this off well, all of which are products of large companies requiring massive resources.[2]

A related problem is "CAPTCHAs" and similar systems which require you to run some JavaScript program in order to prove that you are human before accessing the content in it's simple HTML format.

One solution to this problem is gemtext documents (text/gemini, properly speaking). Gemtext, intended to be shared via the gemini protocol, is a simple text-based document type which by design does not allow the embedding of JavaScript, while still having critical information sharing features such as document structure, and links to media and other documents. While gemini and gemtext cannot cover all use cases of Web sites, I believe they are a suitable vehicle for at least a majority of the common use cases of simple information sharing that occur on the Web today; e.g., blogs, social feeds, news feeds, and tutorials.

Project Gemini

End Notes

[1] I am glossing over some of the practical challenges I have faced in trying to use LibreJS. Personally, I just use NoScript and block all JavaScript unless I need to enable it for a specific Web site, which I try to avoid as much as possible.

[2] The problem of Web browser complexity is partially due to the challenge of properly displaying modern HTML and CSS, which has become a massively complicated task.

[3] The future of the project seems a little unclear: currently (July 2022) there is a 2.0 release in the works, but they are planning to abandon the extension code in 3.0 and switch to using an HTTP proxy.

Haketilo Documentation

Haketilo 2.0 first pre-release (version 2.0-beta1)

License

https://creativecommons.org/licenses/by-sa/4.0/