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. To get an idea of how to do it, you can check examples of site extensions that already exist.

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. (Some are commercial and some are not—that distinction is not significant for this issue.) However, if some other site interests you more, by all means go where your interests take you.

Sites for accessing information and publications

The initial goal is to handle anonymous access. To handle logging in, and logged-in access, is going beyond the short-term call of duty.

  • accuweather.com (for looking at its weather info)
  • pubmed.ncbi.nlm.nih.gov (for downloading papers)
  • groups.google.com (for finding and viewing postings on groups)
  • tripadvisor.com (at least to show a restaurant's full menu)
  • blogger.com (to view the blogs)
  • britishmuseum.org/collection (to view the collection)
  • pdr.net (to view the information on the medicines)
  • reiseauskunft.bahn.de (to view train schedules, at least)
  • rgs.org/about/our-collections/online-exhibitions (to view the exhibitions)
  • worldcat.org (to look up books)

    As an example, see this entry for the GNU Emacs manual. Please note on the page the heading “Find a copy in the library.” Without running the proprietary JavaScript, the only content under that heading is a loading spinner GIF and the text “Finding libraries that hold this item…” The actual library availability information for the given book is absent.

  • scribd.com (to read texts)
  • soundcloud.com (to listen to audios)
  • documentcloud.org (to view documents)
  • bandcamp.com (to listen to or download music)
  • manualslib.com (to download manuals)
  • npr.com (to listen—try using its API)
  • nasa.gov (to look at the publications, including photos and videos)
  • reddit.com (for reading, at least). At present, you can do this by using old.reddit.com.

Petition-signing sites (to let the user sign)

  • freedomunited.org (appears to “succeed” but no confirmation comes back)
  • sumofus.org (the old extension from years ago no longer works)
  • change.org (warning, this site's JS is very complex)
  • afsc.org
  • act.ran.org
  • coworker.org
  • defenders.org
  • earthjustice.org
  • amazonwatch.org
  • signherenow.org
  • moveon.org
  • publiccitizen.salsalabs.org
  • action.splcenter.org
  • secure.everyaction.com
  • amnesty.org
  • addup.sierraclub.org
  • ucsusa.org
  • engage.drugpolicy.org
  • engage.us.greenpeace.org

Other kinds of sites

  • house.gov (for viewinng pages and sending mail to representatives)
  • whitehouse.gov (for communicating with the White House and with the webmasters)
  • Disqus comments, found in various websites (for posting a comment)
  • regulations.gov (for commenting on proposed US regulations)
  • surveymonkey.com (for answering surveys)
  • coworker.org/start-a-petition (for starting a petition)
  • wetransfer.com (ideally for upload and download, but just downloading would be a good first step)
  • stripe.com (for entering payments for other sites)

Sites that people have handled in this way

  • docs.google.com (for downloading documents)
  • pay.gov (for registering a DMCA contact)
  • rsf.org (for signing petitions)
  • theonion.com (for looking at images and audio)
  • goteo.org (for payments)

Footnote

  1. The author uses the gender-neutral third person singular pronouns and possessive adjective “perse,” “per,” “perself,” and “pers.”