Write site-specific extensions to replace sites' JavaScript code(gnu.org)
gnu.org
Write site-specific extensions to replace sites' JavaScript code
https://www.gnu.org/help/help-javascript.html
76 comments
[deleted]
This is ridiculous. GNU should be badgering those sites to open source their client JS, or funding competitors that will.
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?
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?
> 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.
In cases like youtube-dl or gallery-dl this solution works.
In cases like youtube-dl or gallery-dl this solution works.
> 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.
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.
or most of the modding community, wikipedia and much more.
Exactly. Makes me wonder what happened with userscripts lately? Is that community still going? Are there any mechanisms - technological or social - that would let me feel safe about downloading a popular userscript without doing a full-day focused audit of it?
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.
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.
> Makes me wonder what happened with userscripts lately? Is that community still going?
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.
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.
> Are there any mechanisms - technological or social - that would let me feel safe
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.
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.
> 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.
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.
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.
Modifying and improving websites this way is great, I have done it myself. But the article suggests to reject the default behavior of well working sites solely because of the license of the code, that is where the ratio of ideology to real-world benefit goes haywire.
user vs developer....users will never do it thus it will fail.
they have forgotten the users demographic of free source consumers.
they have forgotten the users demographic of free source consumers.
There are many sites out there with enhancement extensions. Sites like the Steam store, reddit, imageboards and probably many others. These things are so useful they replace the default experience. It gets to the point the only thing the sites need to provide is a JSON API for these extensions to consume. The default HTML interface is a fallback for compatibility.
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.
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.
I don't understand this 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.
"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.
> You've visited my site that I have built, you can either use it as is, or not use it - your choice
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.
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.
Because if I write specific JS for my site, that is not 'free' either.
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.
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.
> 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.
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)
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)
About your edit, that's pretty much what extensions like noscript do
I'm pretty sure you're joking, but the client's browser makes the request for a resource. If you're letting your browser request code you don't want to execute, that's on you.
Actually I wasn't joking. But you're right of course. It's on me, just as it's on me whether or not I will execute a proprietary executable on my computer. And if I don't want to, the solution is to just not do it.
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 :-)
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 :-)
> If you're letting your browser request code you don't want to execute, that's on you.
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.
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.
This is one of the things that the FSF is proposing, with a method of tagging executable code under a free license. In general, you can only check that tag after retrieving the code.
EU lawmakers don't understand that. It makes too much sense.
> 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)
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?)
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?)
I don't think it's a joke at all. A user clicking on a link usually wants to view a page, not getting sent 100's of tracking scripts (or miners, fishers, or whatever), and it's not clear at all the user has given consent or is even aware. Search engines flagging ad- and script-heavy sites would be cool, too.
But what if all those "extra" things are what keep that site alive?
Then it should shut down.
But in that case the user loses value, as he wanted what the site was offering.
That's begging the question. Advertising and tracking are not the sole business models of the web nor the ones I have any impulse to protect or cater to.
Wouldn't it be much easier to pass laws that would prohibit all these tracking scripts (e.g. GDPR) rather than writing custom Javascript for every individual website out there?
Yes, it's much easier to pass laws, but enforcement becomes a real challenge...this has been an issue for the GDPR specifically[0]:
> 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...
> 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...
There is fundamental difference of how people think about www.
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
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
They want all Javascript on your site to be free software, i.e., that it is released under a free software license or put in the public domain (and with the readable, i.e. non-compiled and non-minified source code available). That is the FSF's demand for all software that people run on their computer, including in the browser.
At least the "non-compiled and non-minified" part is easy to achieve for many websites trying to be fancy and using today's fancy packers.
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.
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.
Author is probably thinking about sites that are rendered on the server, but need a bit of JS to submit forms and such. Overall it's still silly.
If your website is sending requests to your api, then that api is effectively public.
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.
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.
The article seems to exist in an imagination of artificial concerns.
* 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.
* 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.
Thanks for the article. I agree this article may be too technical focused. However, with current JS api accessing GPU and many other hardware, I often visit site with JS turned off. It would be good to rewrite or block certain JS APIs. Maybe split JS API to categories. Stuff that change CSS color to be in group, and stuff that access GPU/WebGL and accessing hardware of the computer put that in another group. Seems like browser vendor really ought to think about that, I don't want to enable JS just so it can start accessing all kinds of stuff. But some JS to play with CSS of the page are quite nice to have around.
I'm curious what GNU considers "non free" JavaScript. If it's any JS without a "free" license, then I would imagine that the vast, vast majority of websites are non-free.
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.
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.
> I'm curious what GNU considers "non free" JavaScript. If it's any JS without a "free" license, then I would imagine that the vast, vast majority of websites are non-free.
yes.
> They expect volunteers to faithful replicate thousands of man hours of work for every single website?
yes.
yes.
> They expect volunteers to faithful replicate thousands of man hours of work for every single website?
yes.
"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"
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.
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.
> First who use the term webmaster?
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.”»
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.”»
> First who use the term webmaster?
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
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
This is a whole lotta how, and nearly no why. Nobody will adopt if there aren't clearly articulated reasons for doing so. All I've read so far indicates this is a terrible idea, but then that's all they've offered; maybe it's not, but it sure is poor marketing, which is on brand for GNU.
Also on brand for GNU, (edit)supporters who downvote but don't want to contribute to the conversation. For example, if a traffic light has no free software, how is the end user supposed to care? Am I somehow harmed by stopping at a red light? I see this similar to background scripts, who's license has no direct effect on the end user.
Making the effort to explain and defend your pitch seems like just common sense if you're trying to convert the unbelievers, no?
Making the effort to explain and defend your pitch seems like just common sense if you're trying to convert the unbelievers, no?
Seems like people may not be aware what "free" or "freedom" means with regards to Free Software: https://www.gnu.org/philosophy/philosophy.html
"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."
"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."
This is Stallman-esk far removed from reality.
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.
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.
Stallman has been proved correct so often especially after people mock him, that I now listen to what he says carefully. This might seem silly now, but in 10 years it might be what everyone is asking for.
Can you give an example of a widely mocked Stallman statement that has been proven true?
PRISM and all of the problems described in "the right to read" essay. Many other are probably easily found with a bit of research.
You have not actually suggested any concrete statements. I still have no idea what he has said about Prism, the best I got is that he linked to an article from his website.
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.
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.
> This might seem silly now, but in 10 years it might be what everyone is asking for.
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.
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 backend is someone else's. It's out of scope, because it's effectively a service.
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.
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.
In the past, I had a userscript that would just clean up the DOM document on the page (along the lines of document.body.textContent = '') and would just fetch/parse/query the website content anew via XHR and render the content as I liked.
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.
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.
Me being a person who resonates with the ideas of GNU this article seems unfinished and a bit weird. I know that there is proprietry javascript executed on my browser but it is not the same as running emacs on linux. Browser is effectively a platform that executes the code that consists of html, css, js + data. For instance html and css parts are not something that comes purely from the server these days, but is created on the fly in a library or at build time by using some bundler which will use the same library when the site is live. Javascript will actually be abstracted through some framework as well.
What I do not understand is which specific problem it talks about and tries to fix? Is it all the javascript, or beacons sending data to third parties, or a proprietry program like youtube player or google docs, or what?
This "free" approach to the scripts also hits a wall considering that front-end programmers prefer to use a MIT licence in their source, showing their total lack of concern.
I would spend my time making free gnu libraries, but at the moment the proposal is not finished for me to buy into the idea.
At what point do we draw the line between free software being beneficial and being overly ideological? If I buy a printer I'd like a copy of the driver source code so if the company goes bust I can still use my possibly expensive and still working hardware. But if I'm using a web app? Half of the source code is going to be sitting on someone else's machine anyway - making the client side free-software doesn't really change that.
elastolin(3)
Perhaps a good start would be to have a standard way to signal the licence of the JavaScript received by the browser.
At least users would be able to see it, or only allow the ones with a licence they agree with.
At least users would be able to see it, or only allow the ones with a licence they agree with.
A possible solution: .js files should be hashed and, html should indicate the hashes of the .js files it uses. The browser than could run only scripts from a allowed list.
You're describing LibreJS, referred to in the opening line of the article as GNU's "first response to the problem of nonfree JS code".
No, I'm speaking about a W3C standard, and not about a web browser extension.
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.
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.
I understand what you're talking about. The conflict here is that you don't understand the thing that I'm talking about (and rather than going to check it out, you're doubling down).
> 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.
> 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.
I don't think this project is feasible, it would be
much easier to disable all JavaScript-files except white-listed files
> but convincing them proves to be very difficult, since mostly they don't understand the issue, let alone care about it
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.
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.
What about nonfree HTML and CSS? These are not programming languages, but they are still instructions that tell the browser how to display the page. JS code is also a set of instructions that determines how the website should behave. JS is sandboxed, so things that it can do on your computer are limited, just like HTML/CSS. Perhaps the issue with JS is that it's still too powerful and it would be great if browsers could let to limit what it can do even more by allowing to set individual permissions for Web APIs.
Then what about non-free HTML, CSS or non-free media?
Most of the early negative comments here make little sense.
>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.
>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.
This seems very silly, the backend code for most websites (including sql queries, db stored procedures) are almost always proprietary too. Plus it might be running on proprietary architecture such as Windows Server, IIS, Oracle, ColdFusion, etc... So it's a very strange to focus on the JS so much. I don't see a meaningful distinction between "running locally" vs "running on the server" when everything works together to get you the result.
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).
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).
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.