Re: [Bug-gnuzilla] IceCat 38.3.0 release

[Ivan Zaigralin]

I think we can all agree we are dealing with a very complicated
situation here, with significant ethical, technical, and political
challenges, so I am not claiming I got all the right answers, or any
right answers, but I can't resist pointing out what I think are obvious
flaws, and how they can be improved. Hopefully, this discussion will
prove to be productive and beneficial to our users in the end.

>> 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.

Wait a second... Up until now I've been distributing a version that is
basically broken on arrival (broken so badly that users curse at us),
and you want me to stop distributing it rather than distributing a
version that works on arrival? How's that going to help?

It is with very heavy heart that I am cutting out the bundled addons. It
would be much much better if you did it, and I didn't have to. But I
simply see no other way forward in my situation. I think "working on
arrival" is a more important feature than anything provided by any of
the bundled addons, and this feature is missing from the stock package.

But more importantly, I don't think you are hearing what I am saying
about the distribution channels. The real reason why I cannot ship the
pre-bundled addons is not even because some of them are fubar, but
because they are not OS-specific. Up until now the users of my package
were stuck with UNREMOVABLE addons which MAY EASILY INTERFERE with
addons users may want to install. Note that disabling addons is of no
help, since we can fully expect collisions inside the config. Note also
that a package like that totally screws the user who wants to run a
different VERSION or fork of https-everywhere or spyblock. What I am
saying is that if you want your features to propagate through the OS
channel, they cannot be in form of addons. As it stands, my package is
broken by design: the addon part of it anyway.

Look at how we are mangling adblocking: we basically decided which
adblocker the user will run, and made all other options a pain. Running
any other fork of AdblockPlus is probably impossible, and even running
something like ublock is probably not a good idea, unless spyblock is
disabled. So we just took away the users' freedom to choose an
adblocker. Same for https-everywhere and html5-vid.

Another sticky point here is that you tied extra features to an
adblocker. Are additional features in spyblock essential? If so, they
absolutely do not belong in an ad-blocker, unless they are in form of
blocklists (yeah, I am taking 180 on that one). Now if the user wants to
use a different adblocker, they will lose your essential features. This
is broken.

Finally, I concede that users who get your binary packages are basically
OK, aside from having to deal with LibreJS. Their addons are removable,
so the technical issue does not exist there. I would still go with
unbundling, though, for reasons explained at the very end.

>> (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.

No it does not. It cannot possibly detect either non-free or free code.
If a program is to make a substantiated claim that some code is free,
there is only one way:

(1) check the crypto signature on the code or the domain it came from
(2) match the signature against the white list of benevolent code
distributors

As long as LibreJS is not doing that, it doesn't really do anything. How
can I make my point clearer? Tags don't make software free. Presence of
a license does not make the software free. For javascript, being
properly licensed AND in fact readable AND in fact maintainable is what
makes it free. But a computer cannot check that, can it? So
authenticating the script distributor is the only way, since it creates
a real assurance (a very high probability) that the script is free.
Automatic checking of tags does nothing. It checks that the tags are
there, I guess.

Here's why LibreJS is ineffective in principle: suppose everyone is on
the same page, and everyone is aware of tagging, and let's suppose all
web users, 100% of them, refuse to run untagged or non-free javascript,
so we know webmasters are tuning in. And NOTHING will change. The
trustworthy webmasters like FSF will continue to serve all free code,
because anything else would make them untrustworthy. And untrustworthy
webmasters will simply slap your tags onto the 300 KiB of spaghetti code
that rapes your computer. While properly licensed, that code will remain
unreadable and unmaintainable, and therefore non-free, just as it is now.

Here's why LibreJS is ineffective in practice: webmasters and web
designers could not care less about standards. They relish breaking
them. The only thing they care about is ratings. So the only practical
way to modify their behavior (short of legislation) is to convince users
to start boycotting anyone and anything having to do with non-free
software. Any direct appeal to web designers is doomed to fail.

And so while this is definitely just my private opinion, I believe I
argued it pretty well: LibreJS in its present form is not essential for
anything.

>> (i) All currently bundled addons should go into the common directory,
>> none should be installed by default.
> 
> Could you elaborate on this?

Since your features are in form of addons and they break the OS
packages, icecat cannot be packaged for redistribution within an OS in
its present form. And I think the following solution, while not perfect,
is better than what we have now. You could unbundle all addons and greet
the new users with a friendly message telling them about addons you
think are essential, with quick easy links to install them. This can be
done, for example, by creating a custom chrome home page.

Here's what I am actually going to do. I'll create a documentation file
saying, addons have been unbundled, and users should install them the
USUAL way, and only if they want to. Then I'll give them a list just
like this:

spyblock:
  in-house Adblock Plus fork with extra privacy features
Https-Everywhere
  blah blah blah
Html5-video-everywhere
  blah blah blah
LibreJS:
  blocks javascript unless it's tagged as free software [EXPERIMENTAL]
AboutIceCat:
  blah blah blah [COSMETIC]

I really think this is a better solution even for your own binary
package, since instead of holding your user's hand, you will immediately
explain to them what they are getting in terms of addons and why. It
will also make the stock package much more robust, stable, and
predictable. It will be just Firefox with bad stuff cut out, and in just
6 or so easy clicks users will get the extra features, but only if they
want them. Can you handle letting your users decide whether they want
AdblockPlus or ublock? (I just switched by the way.) As devs, you will
also be washing your hands when it comes to bugs in third-party addons,
whereas now you are directly responsible. This is very fair, and it
frees your hands for doing other stuff.

Once again, cheers, and thanks a bunch for making web-browsing free.

signature.asc
Description: OpenPGP digital signature