Re: [Bug-gnuzilla] IceCat 38.3.0 release

[Rubén Rodríguez]

> In my humble opinion, the priorities need an adjustment. One of the
> HIGHEST priorities for web browser users is staying on top of the
> security patches, so every time the concern for the "new features"
> results in skipped releases, the users are gnashing their teeth and
> thinking about jumping ship and just customizing the heck out of the
> stock Firefox. The official goal #1 is to produce a FREE browser, but
> this goal is in jeopardy whenever the browser falls behind, since it
> almost ENSURES that MANY users will be running non-free software such as
> viruses and trojans, and that WITHOUT even knowing.

I agree, falling behind on releases is a critical issue, and I'm trying
to get better at it. That being said, this last release was a major
update (moving from v31x to v38x required many changes and testing) and
it is still just me working on the code. To mitigate the problems caused
by the extra time needed for the release I made an extra security
release for v31x.

> On the technical side, I want to bring up once more what I see as a very
> mistaken move, which is the inclusion of addons. I hope to convince if
> not the devs than at least other package maintainers like me, who
> prepare icecat for distribution within a paricular OS. Starting with
> this release, I am cutting all the addons, and I strongly urge all the
> involved parties (including devs) here to do the same. I am doing this
> precisely to improve the user experience and to make icecat and its
> signature addons more popular, and here are some reasons why including
> addons is a REALLY BAD idea.

All the addons are needed to implement the necessary features that
IceCat requires. Please do not distribute copies of IceCat with missing
features! If for technical reasons you cannot distribute IceCat with its
addons, then please do not distribute it at all.

> (1) Since gnuzilla does not test addons and occasionally gives silent
> treatment to bug reports in addons, including the ones produced
> in-house, it should not distribute them.

We do not need Mozilla to test the addons we include, and whatever
policy they may have should not affect us. The addons have been selected
carefully to provide a set of key features, and have been tested.

>  A common pattern seems to be
> when users install icecat, they immediately run into an addon bug, and
> give up. Here's my experience with a 38.3.0 and a VIRGIN profile:
> duckduckgo does not work, asks to turn on javascript.

IceCat is configured to use the non-javascript version of DDG by
default.

>  I check settings,
> javascript is on. This is already a show-stopping bug. I check LibreJS
> (and how would a NEW user know that?), enable all that page, it reloads
> and... still DOES NOT WORK, it's blank. I check librejs again,
> everything is enabled. I try google maps, and the outcome is exactly the
> same. Yes, maestro is a troll, but I think his emotional state is a
> perfectly predictable consequence of the browser JUST NOT WORKING.

For any javascript-based site, DDG or otherwise, you will find issues
caused by LibreJS. Those issues are in most cases intentional (disabling
any non-free javascript is intentional even if it breaks sites) and in
some cases bugs in LibreJS. Those bugs should be treated separately from
IceCat. Please contribute to LibreJS, it needs improvement.

> (2) Addons were intended to receive security updates independently from
> the browser or the OS, but when we package icecat into GNU/Linux
> distributions, the pre-added addons end up in the distro channel, so
> they update only when users get around updating the OS. This is
> suboptimal.

The preinstalled addons are tested to work with the version of IceCat
they are distributed with, and they get updated when IceCat does. Any
other addon installed by the user should get updates in the regular way,
so I don't see a problem there either.

> (3) Why does gnuzilla think they know best about which addons user
> should run?

As I said, we include a set of addons for the purposes of providing the
key features that IceCat *must* provide. If the users decide to disable
some, or change versions, or install more, it is up to them.

>  What if I want to run a different fork of adblock, not the
> spyblock? Not many users know these forks are INCOMPATIBLE, so
> installing a different blocker will break things.

Installing any two blockers is probably prone to break things. If you
think the prevalence of that problem is high (it is the first time I
hear of people having trouble with that) then it should be added to the
documentation.

...which btw, *nobody* is helping with:
http://libreplanet.org/wiki/Group:IceCat/icecat-help


> (3.1) Forgive me for being blunt, but whose bright idea was it to
> distribute blocklists along with spyblock?

Mine and rms's. Spyblock only blocks well known privacy trackers, and
only when they are included as third-party requests. The alternative
(and how previously IceCat was set) was to block *all* third-party
requests, which broke many more sites. That is still the default for
private-browsing-mode.

>  Do you realize you are
> censoring the web without asking for explicit consent? Notice that good
> adblockers (the addons themselves) do not do that, because USERS are the
> only ones in the position to decide what is an unwanted ad. They offer a
> choice of blocklists upon install, and taking this step out is meddling
> edging on censorship.

Since Spyblock doesnt block anything that is provided by the domain the
user is requesting, I think it is a sane enough default. It may have
some caveats, and other approaches like PrivacyBadger are possible,
although I'm not sure that wouldn't break more sites than Spyblock.

> (3.2) LibreJS in particular is basically nagware. Ostensibly, it should
> help users to nag at web designers, but all it actually accomplishes is
> nagging the users.

It accomplishes preventing non-free javascript from being executed,
which is its main goal.

>  As I explained before, it is 0% effective, since it
> cannot possibly check whether javascript code is free.

It does, by following a criteria and tagging system documented at
http://www.gnu.org/philosophy/javascript-trap.html
http://www.gnu.org/software/librejs/free-your-javascript.html

Both the policy and LibreJS itself can be improved, and for that I
suggest using the LibreJS mailing list.

>  The only good way
> to check that is to (a) authenticate the script source (b) check it
> against the list of authorized free software sources. What makes THAT
> script likely to be free is the tendency of users to put their trust in
> ethical software sources such as FSF, Trisquel, FreeSlakc, etc. The
> presence of a license boilerplate has not a JACK to do with ANYTHING,

The precense of a license notice is the way to tell what a piece of
software is licensed under, so I think it is quite important.

> (i) All currently bundled addons should go into the common directory,
> none should be installed by default.

Could you elaborate on this?

> (ii) Even in the addon directory, no adblocker should be bundled with
> blocklists.

You reverted your position on this in a different message, so nothing to
say here.

> (iii) The free addon directory which shows up at about:addons should
> contain a simple "get started" list saying which addons are essential
> for user freedom and why, and (IMHO) this list should omit LibreJS until
> it's shown to do something useful.

The free addon directory is being reworked. This is what the prototype
currently looks like:
https://trisquel.info/sites/addonlist.php

Adding advice and documentation to that pages is a good idea.