Hacker News Reader

Comment by bennyp101 | Hacker News Reader

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.

View on HN

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

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

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

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

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.

About your edit, that's pretty much what extensions like noscript do

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

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

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.

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.

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.

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

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.

Reply on news.ycombinator.com