Re: [Bug-librejs] LibreJS really needs to be as convenient as NoScript

[Loic J. Duros]

Thanks for your feedback. I agree with much of what you describe.
I would tell you to volunteer and help but since you already mentioned
you do not have any interest in taking up this or learning JavaScript in
order to do so, I guess there's no need for me to ask you to volunteer :). 

I'll take a close look at the scripts and xul/css used for the UI in
NoScript, and maybe take some of this and merge it into
LibreJS. But ultimately LibreJS works differently than NoScript. NoScript
blocks scripts at the request level, that makes it a very different beast.

But yes, if we can come up with a list of improvements to make (Zak
Rogoff and other folks at FSF have already sent me quite a few
suggestions I'm working on), then we are half way there.

In the past few versions, LibreJS started using SHA1 hashes across the
board to cache whether a script is free or not, whether the script is
inline or external. This means that only now do we have the possibility
to whitelist/blacklist a single script, as you suggest. The toughest
part is done and we're almost out of the woods and on our way to make
the improvements we suggest.

Anyone willing to volunteer is of course, more than welcome to do so.

Let's try to get LibreJS 6 to fulfill what most of you expect and hope
for.

Loic

Julian <address@hidden> writes:

> I used to use LibreJS, but I switched to NoScript and haven't looked
> back. I would like to use LibreJS, but I found it to be horribly
> inconvenient and, ironically, encouraging me to run non-free
> JavaScript code.
>
> First thing's first: LibreJS has a lot of false positives for
> proprietary JavaScript code. This is understandable; there is no truly
> reliable way to find out whether or not something is free
> automatically, and false positives are a lot better than missing
> proprietary JavaScript code and allowing it to execute.
>
> With this in mind, a core focus of LibreJS really ought to be making
> it easy and convenient for users to manually take care of these
> inevitable false positives. There should be a button, or something
> similar, next to every script in the list of blocked scripts that
> says, "You are mistaken, LibreJS. I reviewed this script and have
> found it to be free software. The license is this free software
> license, and the source code is at http://the.website."; This should
> add the script to a whitelist of scripts LibreJS thinks by its
> analysis are non-free, but that the user has assured it are in fact free.
>
> But LibreJS doesn't offer such a mechanism. All LibreJS offers, in the
> event of a false positive, is to just tell LibreJS, "I don't care
> about freedom, just execute all the scripts on this page."
>
> Even worse, the whitelist feature of LibreJS isn't a whitelist of
> scripts, but a whitelist of domains where you want LibreJS to just
> blindly allow all scripts to execute.
>
> So what is the result of this? Back when I used LibreJS, and still
> today, almost no sites use the special comment tags required for
> LibreJS to automatically detect if they are free or not. So all I
> could do was build up a big whitelist of domains: the domains I
> visited most often, basically. In effect, LibreJS taught me to just
> trust web sites to not only make all of their code free, but to at the
> same time never use any third-party non-free software.
>
> This, and a bug that I've mentioned somewhere where forum posts and
> other text fields get extra newlines thrown into them, is why I
> stopped using LibreJS. NoScript doesn't have the nifty feature of
> showing me a list of all the scripts on the page it's blocking, but it
> at least gives me more control over what is blocked and what isn't
> blocked, and that at least makes it possible for me to carefully think
> about who I am trusting to send me scripts. That's still not very
> good, but it's a lot better than what LibreJS currently offers.
>
> Since I'm no JavaScript developer, this is an appeal to anyone who
> develops LibreJS or is capable of doing so: please improve this
> situation. (And fix that bug with the extra newlines; that's annoying.
> But it's less important than the other one.)