5 ms·

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

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.

onion2k 6y ago
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.
brisad 6y ago
> 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)
- Phrodo_00 6y ago
  About your edit, that's pretty much what extensions like noscript do
- parksy 6y ago
  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.
  - matheusmoreira 6y ago
    > 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.
  - brisad 6y ago
    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 :-)
  - young_unixer 6y ago
    EU lawmakers don't understand that. It makes too much sense.
  - gpvos 6y ago
    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.
Isognoviastoma 6y ago
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 https://weboob.org [2] https://en.wikipedia.org/wiki/Progressive_enhancement https://en.wikipedia.org/wiki/Progressive_enhancement
gpvos 6y ago
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.
- megous 6y ago
  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.
5560675260 6y ago
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.
jiehong 6y ago
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.
matheusmoreira 6y ago
> 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.

onion2k 6y ago

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.

brisad 6y ago

> 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)

Phrodo_00 6y ago
About your edit, that's pretty much what extensions like noscript do
parksy 6y ago
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.
- matheusmoreira 6y ago
  > 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.
- brisad 6y ago
  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 :-)
- young_unixer 6y ago
  EU lawmakers don't understand that. It makes too much sense.
- gpvos 6y ago
  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.

Isognoviastoma 6y ago

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 https://weboob.org [2] https://en.wikipedia.org/wiki/Progressive_enhancement https://en.wikipedia.org/wiki/Progressive_enhancement

gpvos 6y ago

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.

megous 6y ago
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.

5560675260 6y ago

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.

jiehong 6y ago

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.

matheusmoreira 6y ago

> 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.