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

[Narcis Garcia]

You aren't taking into account that there are wide used CMS designed by
developers that can be receptive and influential in best-practices for
JavaScript.
Also about extensions/plugins for those CMS.


El 14/11/14 a les 08:35, Ivan Zaigralin ha escrit:
> 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:
> 
> http://www.christinasamericanbistro.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.
> 
> 
> 
> --
> http://gnuzilla.gnu.org
>