Open Source

31719 readers

126 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Posts must be relevant to the open source ideology
No NSFW content
No hate speech, bigotry, etc

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago

MODERATORS

[email protected]

FOSS JS extension? (blocking by default non-FOSS JS) (lemmy.ml)

submitted 4 months ago by [email protected] to c/[email protected]

10 comments fedilink hide all child comments

I am a long-time NoScript extension (https://noscript.net/) user. For those who don't know this automatically blocks any javascript and let you accept them (temporarily or permanently) based on the scripts' origin domain.

NoScript as some quality-of-life option like 'accepting script from current page's domain by default' so only 3rd parties would be blocked (usefull in mobile where it is tedious to go to the menu).

When I saw LibreJS (https://www.gnu.org/software/librejs/) I though that would be a better version of NoScript but it is quiet different in usage and cares about license and not open-source code (maybe it can't).

Am I the only one who thought about checking for open-source JS scripts filtering (at least by default)? This would require reproducibility of 'compilation'/packaging. I think with lock files (npm, yarn, etc) this could be doable and we could have some automatic checks for code.

Maybe the trust system for who checks could be a problem. I wanted to discuss this matter for a while.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 3 months ago

When one asks if something is free software (a.k.a. FOSS) the concern isn't so much trust but rather can one view, modify, and share the program. Sandboxes solve a different problem.

In the case of a javascript bundle, in order for a user to exercise the Four Freedoms they must at minimum be provided with corresponding source code for each component in the bundle, and preferably some way in the browser for the user to inspect and modify it. In other words, it must be treated like any other compiled binary program. A lock file with specific versions probably isn't necessary (and server configuration and source code definitely isn't).

You are right in that this would require cooperation from the service provider to provide this metadata, and most definitely would not do this. Therefore, such an extension as OP suggests would have the effect of blocking the vast majority of javascript on the web today. LibreJS tries to some extent but I don't know how well it can handle bundled javascript files.