Write site-specific extensions to replace sites' JavaScript code
gnu.org
gnu.org
I understand the issue perfectly, it's just that you and your needs are not that important to me. Of course you're free to open my website without JS, you're free to crowdsource a bootleg JS package for my website. It's my fault if your bootleg JS package breaks my database, because I should've done better server-side validation. Everything else is your fault and I won't provide any support at all.
"Many websites damage users' freedom by sending nonfree JavaScript programs to the user's browser."
Eh? I'm assuming it means libraries like jquery or alpinejs or analytics etc? Because if I write specific JS for my site, that is not 'free' either.
"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"
Erm, no? You've visited my site that I have built, you can either use it as is, or not use it - your choice - but don't start trying to mess about with it and sending stuff, I might be terrible at writing backend side and sending things wrong blows up a server.
Very strange article.
Note that the article is talking about licensing. Whether or not your JS code is 'free' depends on the license you've applied to it. In the case of sites that use things like Angular or React the user knows that code isn't using a permissive, open license, so the folk at GNU are attempting to block the code coming from the server, inject their own code that does the same thing but more freely, and still have a working version of your site. It's an interesting idea albeit perhaps incredibly not-useful if you don't care deeply about software licenses.
Just because it's your site, you shouldn't assume that you have the exclusive rights to decide what executable code that should run on my computer. If you don't want uses to mess with that, the code should be kept on the backend, because that's "your" computer and you can decide what to run there.
EDIT: Perhaps there should be a required banner for every JS-using site, telling the user that it sends you executable code, and you need to press a button to confirm that you indeed want to let the browser do that. (joke)
Indeed. We can run blockers to get rid of user hostile javascripts but we can't get rid of the web site's own code since that's likely to break everything. That's why we'll eventually have to replace them with free software.
It is still my opinion though, that if you let your browser request the resource, you should have complete control of what code should be permitted to be executed or not. Or if you want to, you should be able to mess with it freely. Because it is your computer, and you should be in control what it executes or not executes.
But the law is not with me on that in many places in the world I believe. And therefore I am happy we have free software :-)
IIRC, this was exactly what we had in the old days of IE4/IE5. Also for cookies, even earlier than that.
(We sort of got cookie popups back, thanks to it being easier to throw a popup than to actually obey the spirit of GDPR and be a good web citizen. I wonder if at some point same will happen with JS?)
> This means that at the time of writing this report, over a year and a half after the complaints were launched, a decision on the complaints is still far off and it is unclear when such a decision could be expected. Meanwhile, Google continues to spy on the comings and goings of millions of European consumers. Moreover, since the complaints were launched, the company has even carried out a (misleading) public PR campaign to portray itself as company that respects privacy and highlight that users are in control of their personal data.
[0]: https://www.beuc.eu/publications/beuc-x-2020-074_two_years_o...
For some, it is execution environment for Web Apps, where backend-frontend split and communication over network is accidental, basically internal for App. Either run in latest version of one-three of top browsers or go away. Logic and security checks can be implemented in frontend in order to save server's electricity, because it will be run in browser anyway.
For some, it is Protocol which is implemented by User Agents to fetch resources exposed by Servers and display it to them. User Agent can be unmodified or heavily customized top browser, lynx, dillo, curl, telnet, specialized tools[1]. JS should be optional nearly always. It is them who is controlling what his computer is executing. From this thinking goes aversion to 30-seconds loading sites, lack of Progressive enhancement[2] going to the point of requiring JS to load blog post, emphasis on server-side validation.
From this difference come many misunderstanding and sometimes conflicts.
[1] https://weboob.org [2] https://en.wikipedia.org/wiki/Progressive_enhancement
You can get their map files and with a simple 10 line php script grab the almost original source code, in tha almost original directory structure. (incl. typescript code, react JSX, original commnets, etc. etc.)
And have fun looking at how, multi-million $ companies, approach frontend code. Sometimes this is a good way to get to view their full backend API surface, if they have it well abstracted in their frontend code.
If you have poor backend code, you’re assured to get weird traffic whose purpose is to break it at some point. It’s only up to you to make your backend resilient. If you don’t, too bad for you.
People's choices aren't so limited. They can do any number of things to your web site. After it leaves your server and arrives in other people's computers, there's no way to control what they do with the data.
> but don't start trying to mess about with it and sending stuff, I might be terrible at writing backend side and sending things wrong blows up a server.
Don't leave your APIs exposed if you don't want people to use them. Anyone can look at your javascript source code and figure out where the information is coming from. People can and will simply request it directly from your server. I already do this with curl.
The website I work on has been in development for 3 years with more than a dozen engineers. The source code is proprietary, i.e., not free as in speech.
The app is React, so blocking all non-free JS would render the site as a blank page. An extension would have to replicate the entire front-end.
They expect volunteers to faithful replicate thousands of man hours of work for every single website? It appears to me that in making this request they didn't think through the difficulty of the task.
yes.
> They expect volunteers to faithful replicate thousands of man hours of work for every single website?
yes.
"Free software means that the software's users have freedom. (The issue is not about price.) We developed the GNU operating system so that users can have freedom in their computing.
Specifically, free software means users have the four essential freedoms:
(0) to run the program,
(1) to study and change the program in source code form,
(2) to redistribute exact copies, and
(3) to distribute modified versions."
Trying to encourage people to enter into an endless game of Whac-A-Mole fixing and re-fixing browser extensions to work with sites as they update isn't a solution.
Who here is going to spend countless hours on that thankless task?
Eh, I assume a lot of people? That's basically what the entire open source space is about! (the person one, not the "corporate open source" that is gaining traction lately)
Don't forget that by "spending countless hours on a thankless task" is how we initially got tools like docker, ansible, bootstrap and more.
I agree with your first part though, that there is probably a better, more efficient solution that carries chance of more sustainable results.
I know this can be made to work - modding communities are a perfect example, you can have people dealing with crap and unexpected breakage on a timely basis and releasing trustworthy, high-value code for free. I just feel it didn't happen with userscripts for some reason.
Oh yes, I still run userscripts from time to time. I've started using JS bookmarks more and more though, to control the triggering of user JS code whenever I want, rather than having something to run on each page load.
But I think the new webextension stuff that Chrome initially released, and now supported by every major browser, ate the lunch of userscripts.
Yes: if FSF/GNU (or a similar organization in that orbit) ran their own repository of user scripts, in the vein of distros' package repos.
Sure it is. This is called adversarial interoperability and it is great:
https://www.eff.org/deeplinks/2019/06/adversarial-interopera...
People are going to fix bad websites whether or not their owners want them to. This is exactly how ad blockers work and they solve so many problems with the web it's not even funny. I've posted many times about how we should just stop trusting hostile website javascripts and start writing custom free software scrappers or clients for all of them. I suppose GNU had the same idea. Awesome!
> Who here is going to spend countless hours on that thankless task?
I spent quite some time writing my own JS code for my school's portal because the default site was unusably bad. The results were pretty good and lasted until months after my graduation. If everyone did this, the web would be fixed in no time.
Why should we allow companies and web developers to have the ultimate say in how their sites work? The javascript is running on our computers and we can totally replace it if we want. We are in control and it is time to start exercising this power.
they have forgotten the users demographic of free source consumers.
All GNU needs to make is a browser extension that collects custom javascripts for all kinds of sites. One person goes and fixes a popular site? All they need to do is contribute that to the GNU repository. The extension will automatically load the new code when users visit the site.
In cases like youtube-dl or gallery-dl this solution works.
* Whether the JavaScript is free, as in beer, isn’t something most users care about.
* It isn’t that site owners don’t understand or care. It’s that they want to make money by hoarding analytics from stalking users and everything else is trivial.
The goals of the article aren’t invalid or misplaced though. They just need a slight realignment to match real world concerns.
* Users somewhat care about privacy. Privacy is largely misunderstood and educating users is painful but it’s still more productive than forcing a non-concern.
* Users detest poor performance. Spyware for money is frequently bloated and poorly written swelling bandwidth and CPU usage.
The best solution to this, both technically and from user concerns, is to separate logic from content. If web content were largely without application logic, such as turning off JavaScript, everything gets faster and privacy gets better. If web applications were void of content there are fewer data points to associate and stalk against user concerns. That separation is what GNU should focus upon to achieve their goals of libre JavaScript.
The css and html are proprietary too, sure they are not executing, but I don't see how that is a meaningful difference, html, css, and js all work together to tell the browser how to render the page. It's a package deal. Beyond that, websites are chock full of proprietary images, fonts, and videos.
When literally the entirety of a website is proprietary, it makes zero sense to "fix" it with making just the Javascript free (as in freedom).
>Who here is going to spend countless hours on that thankless task?
If someone wants to and feels that it is worth their time that is great.
>You've visited my site that I have built, you can either use it as is, or not use it - >your choice
A lot of people are doing this already.
Depending on source between 27% to 58% of users use som form of adblocker.
This is already changing the website from what the owner wanted.
Then you have various features of browsers to modify the page to be easier to read, easier to print.
There are also security products that will modify content for various reasons.
Then you have user script via Greasmonkey, Violentmonkey and such, I dont think many people use them, but you cuold write a user script that does what is suggested in the article.
My philosphy is that you wish to run code I have no reason to trust on a computer I own, I should have the ability to limit what it can do.
We have reached the state than just trusing and running Javascripts is getting closer and closer to someone emailing you an exe and ask you to run it.
I get the argument (also I think it nonsense) but what will rewriting a sites Javascript do about the server side? That would still be non-free. Or is the argument here that the backend and the API is not important because it's only generating HTML/Json/whatever and that's only "data" so you don't care about it. If so, I would turn that argument around and argue that the non-free Javascript is only an extension of the server side and is only generating data - the DOM.
The Right to Read is certainly interesting, maybe not the best written short story, and it is still quite far from having come true. But it is a nice bucket list of things to be aware of while shaping the future, so points for that one.
You may be on to something. Initially I thought the concept was silly, but then I started thinking about Wasm binaries and it starts to become less silly.
The frontend code executes in your browser, on your machine. It's in scope of GNU/FSF interest, because the end-users of that code would benefit from the four freedoms. A lot of people who strongly believe in the value of the Four Freedoms try to minimize the amount of non-free code they run, hence the desire for free frontend replacements.
The way I see it, this concern meshes nicely with a more general desire to be able to substitute your own frontend for the one that's served to you. If you imagine a world where people develop and exchange alternative frontends, the users would benefit from these frontends being "free as in freedom".
Of course we're pretty far from that world - but it's not impossible; the term of art is "adversarial interoperability" and I'm a great fan of it.
It worked pretty well. And if you keep using some common helper functions, it would not even be that much code. A few tens of lines, or something like that.
You're also within the browser and the origin, with all the cookies and stuff handled for you by the browser, and a ton of platform API at hand, so it's fairly easy to even make your own forms and submit data to the server.
It's also a way to not be accused of creating a derived work from some proprietary CSS/JS that might have been on the website, if you ever publish the userscript.
At least users would be able to see it, or only allow the ones with a licence they agree with.
I want a website to say <script licence="MIT"></script> in the html, so any browser can use it, and let the user decide.
LibreJS is just a allow-list extension on a per-website basis.
> LibreJS is just a allow-list extension on a per-website basis
No, it's not. Now you're making things up.
> say <script licence="MIT"></script> in the html
Like LibreJS.
As an example, I have added folders/category tags to my YouTube subscriptions.
While it's a security issue, I would love the ability to inject content scripts via bookmarks or URLs so I could use these enhancements on my mobile devices. Perhaps making certain websites installable web apps and enhancing their UI to fit better on mobile browsers.
Making the effort to explain and defend your pitch seems like just common sense if you're trying to convert the unbelievers, no?
First who use the term webmaster? Second implying that a target audiences of your product is too stupid to understand the importance of what you selling doesn't seem like a great start to me.
That's a little old-fashioned, but nothing like «The author uses the gender-neutral third person singular pronouns and possessive adjective “perse,” “per,” “perself,” and “pers.”»
well, for example the rfcs[1]. and yes, you should use them.
[1] a pair of examples are https://tools.ietf.org/html/rfc2142 and https://tools.ietf.org/html/rfc1945