[Top][All Lists]

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

Re: [Bug-gnuzilla] A need of a paradigm shift for solving the JavaScript

From: Ivan Zaigralin
Subject: Re: [Bug-gnuzilla] A need of a paradigm shift for solving the JavaScript Trap
Date: Thu, 13 Nov 2014 23:35:24 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1

Please forgive the length and rantiness of my reply. Please understand
that I admire the effort that went into creation of LibreJS, and I hope
that many people will find it useful or at least enjoy it. Here I only
argue the merits of its inclusion by default in icecat. If you see me
yell, it's only because I care that much.

On 10/26/2014 06:37 PM, Julian Marchant wrote:
> I highly appreciate what LibreJS is trying to do, and it's better than
> nothing. But I seriously think that LibreJS is entirely the wrong
> approach to the problem of non-free JavaScript.

I completely agree with every part. However, I am also willing to argue that
LibreJS is not effective, efficient, or even high enough quality to force it
upon the users of icecat. By "force" I mean only what is being done right
now, and I know we can disable it (I did).

It being low quality is of the least concern to me, and my assessment is
based on my very modest exposure and the fact that one very rude user of
my Slackware package yelled at me. In fact, I care so little that I am
willing to yield on this front without fighting. However, I want to
mention a rather spotty record, with questionable UI choices (animation,
in-page display) and things just plainly not working. I can't really see
any tabs at the moment, and when I can, they are in the bottom of the page
for some reason. But once again, forget it, the real issue is ahead.

> Right now, LibreJS is failing because it requires a format that isn't
> recognized anywhere, but theoretically, this could be solved in the
> future, so let's suppose that it does. Let's suppose even further that
> LibreJS succeeds so much that it causes a large portion of the Web to
> release scripts under libre licenses and document the licenses in a
> format LibreJS can understand.
> So LibreJS is popular, and people are labeling their scripts and
> linking to source code. But people are still behaving the same as
> before, blindly trusting several JavaScript programs that are silently
> being installed into their browsers every day. The only difference is
> that LibreJS thinks the scripts are libre. These are still scripts
> that are updated automatically, basically completely unaudited, and
> never edited by anyone.

Read the last paragraph very carefully please, for it is very insightful.
The biggest problem with LibreJS is that it's painfully, systemically
ineffective. It is based on the false premise that the user agent checks whether
the code is free; on an explicit (and false) assumption that the presence
of some boiler-plate is equivalent to freedom. But false positives are
both incurable and unavoidable; even a slightly obfuscated code is already
non-free. And false negatives are just as enraging. For example, look at the
ENTIRE javascript code on my website:

var showAnswersP = 0;
function toggleAnswers() {
    if (showAnswersP == 1){
        var arr = document.getElementsByClassName("hidden-answer");
        for (i = 0; i < arr.length; i++) {
            arr[i].style.display = "none";
        showAnswersP = 0;
    } else {
        var arr = document.getElementsByClassName("hidden-answer");
        for (i = 0; i < arr.length; i++) {
            arr[i].style.display = "block";
        showAnswersP = 1;

This is not even copyrightable, and is trivial in every sense of the word,
yet detected as non-free. NoScript is in fact better at what LibreJS is trying
to do than LibreJS. With NS, a user can check whether the source serves free
software, and then white-list that source. And when a user whitelists, say,
fsf.org, it makes sense to load all scripts from there. White-listing is
justified not because of some boiler-plate, but because user trusts the
software source, the FSF, to serve javascript that is actually, practically
free in all four senses of that word.

And we are just scratching the surface of the problem. Read it again,
for Julian said it in the best way possible:

> But people are still behaving the same as before, blindly trusting several
> JavaScript programs that are silently being installed into their browsers
> every day.

This is the root of all evil: users are habituated to drive-by downloads
from sources unknown. If you think about it long enough, you will realize
that javascript itself is the problem. Users who value their freedom browse
with javascript off, and web designers who value users' freedom SHOULD NOT
USE javascript AT ALL unless they complement it with a commitment to audit,
document, and publish all source in a timely manner.

> I get that LibreJS is supposed to be only a first step, but I think
> it's the *wrong* first step. I think we need an entire paradigm shift
> in how we deal with the problem of JavaScript code, one which involves
> not automatic script analysis, but direct user intervention.

Again, spot on. And I will tell you right now what the solution is. It is
very simple, but you will probably think I am crazy simply because you got so
used to javascript. The said direct user intervention should consist in a flat
refusal to run javascript. Free software comes from credible sources, and
javascript is simply mis-designed. It is a platform and an ecosystem that makes
the whole issue of user freedom moot. If users want interactive web, they need
to install a free user agent that is smart enough to produce that experience
from the markup, a la HTML5. Side-loading and running dozens of
scripts, even in a virtual machine, is just stupid, no matter how you slice it.
To put it very tersely, javascript must die. It is absolutely the wrong solution
to every problem it purports to solve, from the users' point of view. If a web
user interface cannot be implemented in markup, a user should insist on it
being done server-side, it's that simple.

So that's for being ineffective. Let's talk about efficiency now, because
it's just as bad. The idea is, basically, to convince WEB DESIGNERS to comply
with A STANDARD. This is not going to work. It just won't. It's like yelling
at an ocean. Web designers is the same crowd that embraced javascript (the
root of our problem), Flash, and renting spyware space. Web designers can't
even follow HTML4 (partly because it's impossible, but that's the standard they
chose), and they won't follow XHTML, the best I can tell, because it's
"too strict". Look here, folks (please have NoScript on, disable at your
risk, this is the restaurant where my wife works), look, this is the state
of the art in industrial web design, the huge pile of cow dung a.k.a. wix.com:


These are the people whose cooperation we are trying to secure with LibreJS.
This is what they call casting pearls before the swine.

We must go to the users, for the real change can only originate with the users.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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