[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

From: Brian Durant
Subject: Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat
Date: Fri, 23 Feb 2018 13:47:23 +0100 (CET)
User-agent: Alpine 2.11 (DEB 23 2013-08-11)

On Fri, 23 Feb 2018, Narcis Garcia wrote:

The key word is: REPOSITORIES.
Scripts should be downloaded as software packages, and those packages
should come from a trusted repository. Each one of those scripts should
be registered accompanied with metadata: Name+Version, md5/hash, license
and features (same as F-Droid + APK).

If a web developer publishes with scripts, those scripts should include
at least Name+Version and md5/hash. First time IceCat visits that
website, it should download script from trusted repository (NOT SAME
WEBSITE). Next times, if not cached, IceCat could get user-approved
script from same website verifying recorded md5/hash matches.

If a web developer wanted a script be publicly trusted, he/she should
upload it to a repository (same as F-Droid process). There can be more
or less strict repositories on the net, same as user can trust more or
less repositories.
New script versions should have to be uploaded too.

El 23/02/18 a les 06:14, Julie Marchant ha escrit:
On 2018年02月22日 21:50, bill-auger wrote:
so its not really accurate to say that libreJS is inherently ineffective
- it is just not widely adopted enough to realize its potential - if it
becomes significantly popular enough for people to start gaming and
cheating it then surely it would also become more robust over time as
there would be more effort put into its development and maintenance
(e.g. a volunteer team of license checking monkeys)

I think this is wishful thinking. What could you possibly do, maintain a
giant list of websites that are mislabeling their proprietary scripts as

And ultimately, that's not the real problem. The real problem is that
LibreJS solves nothing. It's blocking some scripts, but not all. As I
argued here:


*Even if* these websites were serving 100% libre JavaScript, it is
still, from a practical standpoint, impossible for the user to
reasonably exercise freedom 1. You can't make any Web browser that
currently exists run modified JavaScript code (unless you manage to
convert it to user script code, which is a different syntax), and while
you can audit the script, the server is able to change to another script
without notice.

The problem here is that JavaScript, as it is used on Web pages, is,
*fundamentally*, incompatible with software freedom.

That's why I have proposed that the only way any of that JavaScript code
can *ever* be acceptable is with a fundamental rehaul of the way our
browsers handle JavaScript code, and such a rehaul would take a whole
lot of work. So I really think it would be easier to just fight against
JavaScript *entirely*.

Create a browser that shows the merits of a scriptless Web. Advertise it
as non-exploitable, because if it doesn't run scripts from random
untrusted sources, it is. Show people that this world, where just
navigating to the wrong Web page can potentially screw up your entire
system, is a world we don't have to live in. Show them that Web pages
don't have to take centuries to load. Show them that we don't have to
deal with annoying pop-up messages and bizarre, unexpected behavior when
clicking on a link.

And what's more, show them that we don't have to live in a world where
not updating your Web browser every week leaves you vulnerable.

I truly believe we can change the Web in this way. Many websites are
already there. But we need to actually be working toward it, as a group,
with a good browser backing this up. Exactly *what* JavaScript code is
being executed is merely a distraction. Let's band together and solve
the real problem, right here and now.

Some time ago, I offered a bounty to anyone who would write a certain
extension. I think it was $50? I don't remember for sure. But I am still
offering that bounty, so either $50, or if it was larger, what I said
back then. The extension I am offering a bounty for is one that does the

1. Blocks *all* JavaScript code, regardless of what it does.
2. Adds a "danger button" which allows all JavaScript code to execute
for the current page,* for a very short period of time (e.g. 5 minutes),
and then reloads the page.
3. (Optional, +$10) Adds a "super danger button" which allows all
JavaScript code to execute for any page on the current domain for the
remainder of the session. A second click on this button would revert this.
4. (Optional, +$15) Offers LibreJS's complaint feature, with the default
suggested complaint requesting the webmaster to remove all JavaScript
dependencies from their website.

* Note that this would be based on what the current page's source is,
not where the JavaScript files themselves come from, so this is
completely different from what NoScript does. For example, if
foo.com/example.html uses scripts from its own domain but also scripts
from bar.com and baz.net, *all* of these scripts would execute normally
with the "danger button", but *only* if the user is on foo.com/example.html.

I think such an extension would serve the purpose of killing JavaScript
very well because it would be a browser people would actually use (it is
not terribly inconvenient; all websites are still usable), but it would
cause no JavaScript to be the default. Users would be lured into the
extension by the fact that it keeps your browser secure, and they would
be won over by the fact that most pages work *better* without pressing
the "danger button". Watching a lot of YouTube videos? Applying for a
job? Shopping at Ebay? No worries; press the "Super Danger Button" and
be on your way.

With both optional features, that would be $75 for anyone willing to
write this.

I sympathize with these ideas, but it is important to remember that music players and other programs come in contact with JavaScript as well. While I send all my best wishes to such an initiative, the question is if it is at all feasible, given that there are other programs that come in contact with JavaScript as well. Any solution similar to the one you describe is potentially too browser specific.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]