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