www.gnu.org - News: Let's Fight Back Nonfree JavaScript!

Let's Fight Back Nonfree JavaScript!

Item posted by Dora Scilipoti <dora> on Fri 12 Mar 2021 07:53:05 AM UTC.

[https://www.gnu.org/software/librejs/ LibreJS] Blocks JavaScript, But the Site Will Not Function

Here are some [https://www.gnu.org/help/help-javascript.html Guidelines and Suggestions to Fix That]

Write site-specific extensions to replace sites' JavaScript code

Many websites damage users' freedom by sending nonfree JavaScript programs to the user's browser. We invite volunteers to develop free browser extensions to replace for the JavaScript sent by particular sites (see the lists below).

Our first response to the problem of nonfree JS code was to develop LibreJS, which enables Firefox-based browsers to detect and block that code. That protects us from running a site's nonfree JS programs, but does not make the site actually function. Writing an extension for it, as we propose here, would achieve that. It would also avoid the risk inherent in running software straight off someone else's website.

We could also solve the problem by convincing the webmasters to correct their sites to function without the JavaScript code, but convincing them proves to be very difficult, since mostly they don't understand the issue, let alone care about it. Maybe recommending use of these extensions for their sites will convince them to pay attention to supporting non-JavaScript access.

Therefore we invite volunteers to pick a site and write a browser extension to make that site function, assuming that LibreJS blocks the nonfree JavaScript sent by the site.

The first thing to do is to look briefly at the licenses of the JavaScript files on the site. Some of them might actually be free software. If some of the JS code sent by the site is free, you can include it in your extension, changing it as needed.

Next, check whether the site has published an API. If so, it is best to communicate using the API, if that can do the job. Otherwise, you need to use the browser debugging facilities to figure out what data and commands the JavaScript code sends to the server—in effect, its undocumented API.

The way to avoid infringing copyright on the site's own JavaScript code is not to study the code. Not any part of it, not even once. If you did not read the code, it follows that you did not copy any of it. Look only at the licenses.

These extensions should be honest—they should not “cheat.” If the site's JavaScript asks the user for information and sends it, the extension should ask the user for that information and send it. If the site asks per (1) to check a box to agree to XYZ, the extension should ask per to check a box to agree to XYZ. The extension should faithfully pass on whatever responses the user enters. If the site sends a cookie, the extension should let it be handled according to the browser settings for cookies.

It is impossible to implement real security via JS code sent to the user, but whatever the site does to try to implement something resembling security, the extension should carry out faithfully. In particular, if the site asks the user to answer questions to prove perself not to be a robot, the extension should show per the same questions, get the answers, and send them in—thus enabling per to demonstrate that perse is human.

Jeff Carpenter's librecaptcha might be useful if the site sends a captcha. We will start a project to convert it to JS, and we will need volunteers for that, so please write to me if you are interested in helping.

Meanwhile, if the site's JS code gathers information surreptitiously, it is admirable to thwart that snooping. One idea is to ask the user what answer to return—for example, “The site is trying to find out your location. What do you want to tell it?” But it would be good to avoid asking the user frequently or repeatedly.

When you have an extension working, please mail a copy to the GNU Project at <js-extensions@gnu.org>. You can also register it in Firefox's extensions list, if you can stomach running the nonfree software to do that.

We have set up a mailing list, js-extensions-discussion where you can talk with others who are developing extensions.

Once things are going, we would like to set up a savannah.gnu.org repo where we will put the extensions that are working. To do that, we need a volunteer or two to manage it. We expect this task not to be a lot of work; the reason to have two is for redundancy.

We could also have a Savannah project which you could (if you wish) use for developing an extension; that too would require volunteers to take care of it.

Here are some suggestions for sites to write extensions for. However, if some other site interests you more, by all means go where your interests take you. Read more...