Concur on most points. I support informed consensus, insofar as it would succeed in restoring some previously built-in privacy features.
Simple voting as it's happening here and at Savannah, is not necessarily democracy, because without any proper discussion, it's often uninformed, and becomes simply a vote by majority, especially when a bad decision gets made. There are also people, who do use IceCat, but who don't vote, and who don't partake in discussions in this list and elsewhere. The same applies to users of upstream, but on a scale greater by orders of magnitude. When something wrong happens to upstream, it's impossible to turn it back, and users discover fairly late when useful functionality has been removed or when bloat has been added. There are things that should be in addons, and then there are things that should not be. For example, cookie prompt code should be returned, stay built-in, and be developed further. This would resolve an upstream regression and increase the user base. If done right, more distros would then pick IceCat as the defaut browser. Whilst NoScript is an independently-developed add-on used by other Gecko-based projects and should therefore stay as is. wrt future IceCat, then instead of any one adblocker, NoScript should be bundled, as it has a compatible license, it offers better security, and most ads are blocked along the way, too. Some distros do that bundling already. Choosing an adblocker is then up to each user and their preference. -M. 2016-11-14 21:46 GMT+02:00 Ivan Zaigralin <melik...@melikamp.com>: > This is just brain-storming, meant for comment only. > > I am not convinced voting over a bunch of small initiatives would be very > effective, at any rate, I will abstain for now. > > I think before voting we need to have a consensus on the general direction > as > we are moving forward, which is not something we can solve with just > applying > the democracy. We've got some technical problems looming for a while now, > and > they need some love and care from the few people doing the actual work. > > The terrible lag behind the upstream releases was recognized as an issue > for a > while now, and it feels to me that part of the problem is that > modifications > applied to the upstream are too invasive. May be we can separate this > project > into 2 distinct subprojects: > > (1) > > This one applies the minimal possible changes to the upstream in order to > make > it FSDG-compliant. I haven't looked very carefully, but if it's anything > like > building FSDG-compliant thunderbird, then may be the following would be > enough: > > (1.1) disable add-on page or replace it with a good page > (1.2) build without official branding > (1.3) add icecat branding, or leave it for (2) > > (2) > > Here we build the icecat proper, with all the extra privacy features. > icecat > branding can also be added at this stage, if it wasn't added earlier. I > have > nothing against putting the features inside addons, but I must insist the > way > it's being done right now is suboptimal. All these feature-imparting addons > must be made in-house, have their own distinct namespaces, and should not > replicate functionality provided by upstream addons. In particular, icecat > signature addons should not prevent the user from installing and using any > of > the general-purpose ad-blockers, https enforcers, etc. If we close our > eyes on > its philosophical issues and bugs, LibreJS is how we do it right. > spyblock, on > the other hand, needs to go. The users should be able to choose whatever > free > ad blocker they want. > > This two-pronged approach would insure that users and distributions are > getting the security updates in a timely manner. And may be we can find a > way > for the additional features to be packaged separately, and updated > independently? > > -- > http://gnuzilla.gnu.org > >
-- http://gnuzilla.gnu.org
