Software Freedom Movement challenge: The Javascript Trap

9 réponses [Dernière contribution]
koszkonutek
Hors ligne
A rejoint: 03/19/2020

Hi,
For some time I am having what I think are some good thoughts on challenges of Software Freedom Movement and I decided to start writing it all down here (since I don't have a blog) and see if I manage to start some useful discussions.

So, the first rant will be about javascript.

RMS already wrote about this problem in "The JavaScript Trap"[1].
Sites keep using more and more js. Some years ago websites owners at least cared about them being accessible for users who don't run scripts. Then, as time passed, javascript support in web browsers (including mobile ones) improved. At some point sites creators noticed, that over 99% of users are now able to execute js and made their pages rely on it, even for simple things like drop-down menus.

And that's how we got where we are now - many sites will fail to display anything if we disable js on them. And what's terryfying, is that this trend continues. Size and complexity of js programs grew so big, that parties involved created WebAssembly to be able to put even bigger stuff on their websites. Sure, this technology can also be used for good things - I'm just using it here as an example of World Wide Web's evolution.

So at the end of the day - I'm unable to perform most of the tasks other do on the web, because I refuse to run nonfree js and it seems, that it's only going to get worse.

Honestly, I think most websites overuse js. A lot of interactive page content can actually be created using solely CSS and HTML. And it's usually more efficient and less buggy than implementing the same functionality with js. Even if there weren't/aren't any freedom issues, we should complain about poor design...

Let's, however, go to the main point - nonfreenes of the js. When js is free, we (software freedom folks) don't complain. Unfortunately, in most cases it isn't free. I think the problem is that webmasters, as well as the rest of society, don't realize and/or don't care about nonfree js. If you think about it - most organizations/individuals would not lose a penny if they put a free license on their javascript (+ provided unobfuscated version of it). But they won't do so, because they're afraid, they don't see the need to or they simply don't know they should.

So, what are the remedies?

Obviously, blocking the js. Some ppl (like me) use NoScript, some use LibreJS recommended by FSF, some use Ublock, and some just disable the scripts at the browser level... All this boils down to blocking all the nonfree js and maybe letting some free code execute.

And I really think we should do this. But this is not all. The whole idea of free software is that users can modify it and use/redistribute the modified version. If some javascript's license is free, then we can do that... from legal point of view. But from practical point of view - we don't have the means to. Just look at those IceCat extensions for enabling the use of some sites with free JS. One extension for one site. Perhaps it's useful as a temporary workaround, it just isn't how we're going to free the web. There ought to be some tools to allow the user to easily replace website's javascript with self-provided code. Then, we could execute our four freedoms just as we do with traditional programs. But until we get such tools, freeness of on-site scripts is almost purely virtual :/

What saddens me, is that RMS wrote about it as early as in 2009 (judging by the copyright notice at the bottom of "The JavaScript Trap"[1]). And he talks about this exact need throughout one of the paragraphs. Now it's 2020 and I still don't see even a simple ff extension, that would *both* block the site's js and load user's own. Perhaps someone has some homebrewed solution, but if there was anything real for the job, I'd probably see ppl on this forum mention it - and I don't.

If what I've written up until this point seems dull to You, then You're right - because I've been more or less just summing up what was already known and what RMS wrote in The Trap. Now, I'm going to present some thoughts on my own.

One of the first things that comes to mind is "this is impossible". Possible arguments are (not sorted in any specific order):
1) There are too many websites on the internet, You won't be able to store all the needed scripts.
2) There will be too much load on "site for sharing changes" once people start using it.
3) You'll get sued.
4) There are too many websites on the internet, You won't be able to write free js for all of them.
5) A website might change it's workings at any moment, You won't be able to keep up writing free js for it every time.

First I thought I'd go through all the points above and explain why I think it shouldn't stop us. But instead, I decided to write all the chances I see and note which of the problems each one relates to.

So, the idea of replacing pages' scripts with libre ones is not really attractive to most ppl. There are probably too few freesw enthusiasts who would like to spend their time freeing others' websites. That's point 4). I admin, at the beginning it has to be like this. But I believe the thing could grow.
Think about it: there are many people, who hate, what "Web" has become. Who don't want to be tracked, don't want fancy content to slow everything down and don't want security holes in their browsers to be exploited (which is mostly done through javascript). But they're not devoted to software freedom enough to reject the scripts, that are required to make some sites work. I believe, that if they see an opportunity to change that, they will help with the thing.
And now imagine, that once we have a base of free javascript replacements for many websites, ppl who completely don't care about freedom could start using it for solely practical reasons. Why? Because there are many things, custom scripts can improve on websites. I guess that's why Greasemonkey and simillar extensions exist...
Now add to this, that FSF and GNU would be happy to recommend the tools we're talking about, as long as the services we create for sharing scripts "are dedicated to free changes only". Perhaps other supporters would also appear.
So, chances are, 4) would not be a problem.

And finally, the biggest thing - if we have an infrastructure for sharing changes, we can impose some policies on what substitutes are accepted. Of course, we'd require that all javascript is free (whether to use FSF's definition of free or something tighter would need to be decided). We should also require it doesn't track users. But what if we require, that js for a given website blocks all ads, UNLESS the website cooperates, makes its javascript free and uploads it to our service? I leave it for You to guess what outcome I expect

koszkonutek
Hors ligne
A rejoint: 03/19/2020

[continuation of the first post]
Of course, some websites would still not like the idea and fight to make it impossible to write free js for them, I admit. But I think most would not deliberately try to become harder to view for users, so this won't be a major issue - take that, 4) and 5)!

And even if I'm too optimistic here and the thing doesn't spread that much, it's still worth doing, to have at least some sites liberated :)

As I mentioned policies, I have to clarify: one can only control its own servers. The service would obvoiusly be free software, so others could and would run their own instances under different policies, even allowing nonfree js to be hosted there. Perhaps You don't like it? I understand, yet, there's no other way - freedom 0 requires, that software can be used for any purpose, even if that purpose is hosting nonfree software...
But hey, the ability for averyone to run their own infrastructure is actually a good thing! What if the service goes down for some reason? Technical failure, lawsuits, anything. Federated approach is what makes Invidious possible right now :)
Btw, lawsuits might happen, but it would be quite hard for a company to find something illegal in hosting javascript replacements. I guess that helps with 3).

So, I hope we agree, federation is cool. Still, to provide a reliable service, especially when it grows big, one needs to deploy multiple servers. There's also need to let people create accounts and post comments, rate scripts, and of course - upload scripts! There are surely some laws that interfere with that, so the entire thing (like, the main instance) would ideally be run by an organization. Would an existing one, like FSF, like to step in, or would a new one need to be created? Idk, for now I'm just stating, that sooner or later the service could become big and serious, which could be difficult for a single person to operate.
Now, how would an organization deal with 1) and 2)? I believe this boils down to having enough money for setting up servers. The organization could accept donations, or it could find a way to monetize the thing. Why not a programming service of developing ethical websites? Web development tends to be overpaid, anyway. Or maybe running an ethical ad network - one, that doesn't track? This idea probably deserves ahother rant. Anyway, before we get to that point, we'll hopefully find means to earn for 1) and 2).

You know, what? A cool thing is that once we have a good infrastructure with proper API, we'll not be limited to a single browser extension. The infrastructure, code base and community is what is going to matter. It should then be very easy to write an extension for another browser or device a local proxy, that would allow arbitrary http clients to access the free version of any site (provided it has already been liberated).

Another important thing to realize is that many (perhaps I should say "most") javascript libraries are free software. I often see sites, that include jquery, bootstrap and some other permissively-licensed libraries and then add a bit of their own code, that achieves something practical using those libraries. This is good for us, since to make using a site with free js possible, we would only need to replace that custom code, not everything, which should make dealing with 4) easier.

On some websites, js is already fully free. I mostly mean federated free software services like Invidious, Etherpad, Mastodon, but not only. Javascript, that makes them work, should also be uploaded to the service. This way, users would no longer need to trust that websites really serve the scripts, they seem to be serving. There will be no danger of going to, say, malicious website pretending to be running unmodified Searx and unknowingly mining crypto for it :P

Now, did You think what else a free js movement with proper infrastructure could help with? Imagine, that if we could modify websites to run free js, we could also modify them to be, for example, more accessible. Make sites easier for visually impaired people to read. I suppose that could boost popularity of the service.
Have You, by any chance, read this[2] forum post by chaosmonk and this[3] blog post linked there? To me - the "Web" is simply broken. And I think at some point even Gaagle will realize that. Big amount of bloat won't benefit any1 in the long term. How does this relate to our issue? We could promote use of some narrower standard, that is simple and lean.
And how about also allowing service users to flag sites with flags like "porn". Parents or schools could wish to use a proxy, that filters the sites based on that.
At the end, broader usage should increase popularity of the thing (good for 4))... I guess, however, that using it for parental control would not make it popular among kids, so maybe we should drop that one idea...
Anyway, if it got popular enough, the service could itself help promote software freedom :)

To sum up what I've written so far - the "Web" is horribly broken and keeps rolling down the hill, which too few ppl seem to notice. But, however bad it is, I see it as a chance for freesw folks to step in and do something good, even if there are risks along.

I'll now mention some minor details, that might deserve discussion.

How to actually verify, that js uploaded by random person meets the requirements? As number of ppl submitting free javascript for websites grows, the number of those judging it should also grow. Hence, we need to make users able to rate and flag code submitted by other users. But then someone could just create 100 accounts and take over the service... I think Wikipedia deals with some very similar problems to ones discussed here. And there editor is permitted to do more or less depending on the number of their past editions. If this solution works there, it should work here as well.

Btw, at early stages a service could just store links to scripts.

How to provide integrity of served scripts? After reading some things about SSL/TLS[4], I wouldn't want to use it for this job. It would be better if all scripts served were signed and the client (browser extension or proxy) came with service's public key bundled with it. I recall, that NaCl has a port to browser (and possibly some other crypto libs do as well). This would also enable ppl to create third-party relays for service's main instance :)
If one wanted to also use scripts served by another instance, they would have to add it manually, together with its public key.

It'd be cool if users could quickly edit the source code in their browsers. In case of simple javascripts this is not a problem. But what about bigger javascript programs, that are typically minified to save resources? What about other languages, that get compiled to js or Wasm? For now, I don't see any solution, that would enable ALL of those to be modified in-browser.

How to distribute the system once it grows? I a hierarchical manner, like DNS (with the difference, that here the entire "tree" would be operated by a single entity)? Or is there another way? That requires investigation...

After writing this lot, it'd be good to actually do something in this direction. I need to say, I wanted to start making a ff extension with this in min a few times. Problem is, this is a bit of a new field to me (I know C better, gah). I also never seem to have free time for stuff like that. At some point I thought "There're some freetards like myself on Trisquel forum. Why not write there and see if some of them would like to join forces. No need to do everything alone". So I did.

What are your thoughts on the topic? Should I clarify some of what I wrote? Or maybe You're aware of some similar attempt made by some1 in the past? End, finally - would you like to try hacking this issue? :)

Btw, if we are to re-use some other extension's code, LibreJS seems to be waaay more readable than NoScript. However, it seems to fully rely on the webRequest API[5] that's specific to HTTP(S) and for example doesn't block scripts on file:///, which NoScript does (through CSP, it seems?). I'm assuming newer ff here (sorry, Hyperbola folks). Haven't looked into Ublock's implementation yet.

[1] https://www.gnu.org/philosophy/javascript-trap
[2] https://trisquel.info/en/forum/iridium-and-brave-browsers#comment-150954
[3] https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html
[4] http://michael.orlitzky.com/articles/lets_not_encrypt.xhtml
[5] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest

PrimeOrdeal
Hors ligne
A rejoint: 09/15/2019

Thanks for your brain dump essay which certainly discusses some interesting points but for many readers like myself could be too many/difficult to fully grasp. I'm not a js-programmer or analyst of js but presumably an automated check could veto execution of potentially non-free code items. If the free js runs okay but pages with non-free js get a flag saying "In order to protect your freedoms this browser refuses to run potentially non-free js" isn't that sufficient? Then users who don't wish to protect their freedoms can sacrifice them with another browser/set up and js programmers who don't want to exclude users who care about freedom might alter their code in order to avoid triggering this non-free veto.

As you mentioned collaboration and clearly have a lot to say I'm wondering whether it might be better to break down your discussion into smaller topics for the forum to handle one at a time. However you might well take the position that your target audience are those with greater mental capacity to process long essays which is fair enough.

I'm also wondering whether long essays could be developed into published literature, perhaps collaborating with relevant co-authors where appropriate. What peer reviewed academic computing journal(s) can be recommended for free conmputing enthusiasts, for articles whether technical or philosophical/sociological, and/or perhaps legal/ethical?

[update: I decided the question of free computing journal could be reason for a new thread elsewhere so I have added https://trisquel.info/en/forum/what-academic-computing-journal-can-be-recommended-free-computing-articles ]

koszkonutek
Hors ligne
A rejoint: 03/19/2020

> your [...] essay [...] for many readers [...] could be too many/difficult to fully grasp.

Or too boring. Thanks for pointing it out :)

Actually, another problem is that I assume ppl read stuff I link to. And then it turns out they don't...

> presumably an automated check could veto execution of potentially non-free code items. If the free js runs okay but pages with non-free js get a flag saying "In order to protect your freedoms this browser refuses to run potentially non-free js" isn't that sufficient?

This kind of sounds too me like what LibreJS is doing. The main problem is - this freeness check is impossible to automate. Website could disguise nonfree malicious js as free, truly free js would not always get flagged as such, etc. We discussed this problem very thoroughly not that long ago in this thread: https://trisquel.info/en/forum/umatrix-development-has-ended
Actually, that discussion itself might be too long for You to be willing to read it...

Also, don't think simple veto is enough, but that's already covered in my essay and also in RMS' essay I linked to in mine (I don't mean I'm angry with You because You didn't read it all - I'm just saying it's there)

Magic Banana

I am a member!

Hors ligne
A rejoint: 07/24/2010

I guess that's why Greasemonkey and simillar extensions exist...

I have not understand why you do not consider them solutions to the problem. I mean with a repository that would only accept user scripts distributed under free software licenses.

calher

I am a member!

Hors ligne
A rejoint: 06/19/2015

On 8/22/20 1:47 PM, name at domain wrote:
> I mean with a repository that would only accept user scripts distributed
> under free software licenses.

https://openuserjs.org/

--
Caleb Herbert
KE0VVT
(816) 892-9669
https://bluehome.net/csh

Magic Banana

I am a member!

Hors ligne
A rejoint: 07/24/2010
koszkonutek
Hors ligne
A rejoint: 03/19/2020

Greasemonkey indeed "comes close to do the job" - as RMS noted in The Trap. But he also pointed out, that it fails to fully block the site's scripts. I haven't come across any source, that would state that has changed in the meantime, so I'm just assuming it hasn't (correct me, if I am wrong here).

It should still be possible to use Greasemonkey together with NoScript to achieve the result (NoScript's FAQ claims they won't bite). Yet, it's a bit uncomfortable - a single extension is what is needed.

The fact that Greasemonkey doesn't block site's nonfree scripts (as long as I'm right it doesn't) is not the main problem here. We could modify it to do that. The thing is - this extensions has been created for another purpose. To "customize the way a web page displays or behaves, by using small bits of JavaScript". And user scripts flying around seem to reflect that. We instead want to replace all page's nonfree scripts with free ones. That's a little bit different and a huge bit more ambitious. Greasemonkey might still be useful to take some code from it, tho :)

Actually, what I'm proposing here is something in-between NoScript, LibreJS and Greasemonkey. None of those three fully solves the nonfreeness issue, although all three are somehow related to solving it.

Btw, Greasemonkey doesn't load user scripts into the page. It runs them inside a separate sandbox and they are recommended (for security reasons) to use Greasemonkey's APIs to modify the page (actually, the reason for that safety measure is to prevent page's own scripts from interfering with the extension). And it's probably a rational thing, given what this extension is meant for.

I believe our solution should place "user scripts" inside the page, so they have the same restricted privileges websites' scripts usually do and so that they can use the same APIs websites' scripts can. This reason for the first should be quite obvious (security). The second is important to make it easy to create free substitutes for ppl who already know web programming and to make it straightforward to re-use those free bits of javascript that are already present :)

Having that said - good to know they enforce licenses :D

That's better than maven, quicklisp, pip and whole lot of other language-specific package managers/repos :d
I respect OpenUserJS for that (sad their site seems unaccessible to me right now...)

commodore256
Hors ligne
A rejoint: 01/10/2013

This is why I suggested we might as well go back to flash, at least the web was usable when you blocked flash and you set it up so you could only run flash scripts with the User's consent. I think we need a libre successor to flash, it would be way better than Javascript.

https://trisquel.info/en/forum/flash-most-underrated-technology

andyprough
Hors ligne
A rejoint: 02/12/2015

> I think we need a libre successor to flash

We had one called "gnash". Last official release was in 2012, but there have been some sporadic commits since then.
https://github.com/strk/gnash

There is a fork with some commits as of 2 years ago, that an Arch AUR user recently reported is stable and usable:
https://github.com/shunonymous/gnash

Build instructions are in the comments section here: https://aur.archlinux.org/packages/gnash-git/