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
-- http://gnuzilla.gnu.org
