[conspire] (forw) [DNG] Life After Firefox 56
Paul Zander
paulz at ieee.org
Thu Feb 23 22:11:44 PST 2017
Thank you for the advance warning. Having once used Netscape, I have typically installed both Seamonkey and IceWeasel | Firefox. I wish the the composer feature of Seamonkey had more support, but it much better than the IceWeasel | Firefox.
Somehow the reasons for the change in Firefox seem to parallel the thinking of many millennials. Since smart phones have a clock ap, there is no need for stand-alone wristwatchs. Never mind that a watch can be highly optimized for the its purpose: you can check the time without pushing any buttons, you don't have to reach for it in a pocket. Is there any phone that is water-proof to even 10 meters?
From: Rick Moen <rick at linuxmafia.com>
To: conspire at linuxmafia.com
Sent: Thursday, February 23, 2017 3:20 PM
Subject: [conspire] (forw) [DNG] Life After Firefox 56
The forwarded post's segue from an antecedent discussion about creeping
'lockdown' (in Desktop Environments, notably GNOME3) is something I
might get into separately, but there's a big story about Web browsers
alluded to in his post: At the end of 2017, Firefox will undergo a
wrenching change: XUL (XML User Interface Language) and XBL (XML
Binding Language) will be dropped after Firefox version 56.
Most important consequence: current Firefox extensions will break,
because they're written in XUL and communicated with using XBL.
(Disclaimer: I'm writing this on the fly concerning a complex topic,
and hope I get all this right but make no promises.)
XUL has been, IMO, the foundation of what makes Firefox special, namely
its vast extensions ecosphere. Problem is, XUL is slow, and has never been
adopted anywhere but Firefox & workalikes + Thunderbird (despite hopes
it would become the 'programming language of the Web'). It also makes
Web browser security weak (in the sense that misbehaviour affecting an
extension has widespread effects that are difficult to contain[1]) and
stands in the way of the longstanding goal of letting each browser tab
run as a separate process (https://lwn.net/Articles/576564/)[2]. So,
it's getting killed -- along with (unless rewritten from scratch)
thousands of XUL-based extensions.
The aim is to make Firefox faster / more responsive and more secure, but
doing his with a multiprocess model is a mixed bag: Currently, Firefox
is relatively light on RAM and CPU compared to Chromium / Google Chrome,
believe it or not. What may be achieved is preventing individual tabs
from blocking (or crashing, or security-compromising) the rest of the
browser at the expense of dramatically greater RAM usage and lower
responsiveness overall.
In place of XUL, Firefox has developed a new external interface called
WebExtensions, based on Javascript[3] {retch}, deliberately very similar to
the way extensions are implemented in Chromium (+ Google Chrome) and
Opera Web Browser. Moreover, Mozilla, Inc. intends for Firefox to
enforce a requirement that all extensions be cryptographically signed
by Mozilla, inc. or Firefox will reject them. The latter change will
actually happen sooner: Starting with Firefox 41, scheduled to be
released on Sept. 22nd (my wedding anniversary), 2017, Firefox will
refuse to load _any_ extension[4], XUL or WebExtensions, that hasn't been
crypto-signed by Mozilla, Inc. via a signing process to be implemented
via addons.mozilla.org.
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
Stated policy is that Mozilla, Inc. will not withhold signing to impose
'censorship' of extensions, or enforce copyright, government demands,
etc., only 'to protect users from malicious add-ons', in accordance with
guidelines at
https://developer.mozilla.org/en-US/Add-ons/AMO/Policy/Reviews . (It's
a fair point that if Mozilla, Inc. were to stop honouring those
guidelines, people would notice and beat them up over it.)
You might be thinking 'Er, why not _also_ let local admins self-sign
extensions and let Firefox be able to trust their certs?' Why, indeed?
The moment this central-signing plan was announced two years ago
(https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/),
dozens of people have been raising that objection -- see comment section
at preceding URL. So far, Mozilla, Inc. has absolutely refused as to
release and beta Firefox-branded builds. If it's called Firefox (except
for Nightly and Developer Edition), then nothing Mozilla, Inc. hasn't
signed will be permitted.
I hope and expect unbranded Firefox will make an immediate comeback in the
Linux community for that reason.[5] The rebirth of Iceweasel may be a Web
browser exactly the same as Firefox 41, except with a different name and
artwork, plus support for the user's own WebExtensions cert.
Essentially I concur with this comment at blog.mozilla.org, except I see
it as A Good Thing and necessity for Linux and open source, rather than
something to deplore:
I fear this could lead to an enormous disagreement between the open
source community, that Firefox is supposed to represent, and Firefox
itself. To the point where a fork could end up being created – one that
would follow Firefox’s code closely but would remove this requirement
about signed extensions. This wouldn’t be good for anyone involved, yet
it is what will happen if this decision comes to pass.
https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/comment-page-3/#comment-213364
That sounds like exactly the right and desirable thing, to me -- a
persistent close fork, Iceweasel Mark II. Because corporate walled
gardens in open source sound like to me an automatic 'No thanks.'
As this starts blowing up on us in mid-year, be aware of two interim
refuges that retain the ability to run (most or all) existing XUL
extensions, without mandatory code-signing, while we wait for the dust
to settle:
o Waterfox: https://en.wikipedia.org/wiki/Waterfox
o Pale Moon: https://en.wikipedia.org/wiki/Pale_Moon_(web_browser)
o SeaMonkey: https://en.wikipedia.org/wiki/SeaMonkey
There are no current plans to enforce this code-signing regime on
extensions for any of those three Firefox siblings, nor on Thunderbird.
[1] In corporate-speak, Mozilla, Inc. refers to this issue as one of
'protection against malware'. Corporate spokesman Jorge Villalobos
wrote: 'Well, add-on malware is currently an uncontrollable mess, which
is why we feel the need to take action.' (I don't mean to sound
unsympathetic. There is a real perceived security problem, especially
in the corporate MS-Windows market where users feel without
justification that they can trust any extension from addons.mozilla.org
and similar places, with predictably bad consequences.)
[2] The beta of this functionality, already seen in Nightly, Aurora and
Beta builds, has been something called Electrolysis, often referred to
in shorthand as 'e10s'.
[3] I'm just a little unclear on the future shape of extensions, because
some articles like
https://arstechnica.com/information-technology/2015/07/big-changes-are-coming-to-firefox-to-win-back-users-and-developers/
suggest native HTML5-UI implementation is likely to win out.
[4] Themes, dictionaries, language packs, and plugins don't need to be
signed. Just extensions. https://wiki.mozilla.org/Addons/Extension_Signing
This is also as good a place as any to add that I'm discussing in this
post primarily the main desktop edition of Firefox. Mozilla's rules for
Firefox for Android will differ somewhat, and I'm not addressing them
here. As a small _future_ thaw in the otherwise resounding 'no', Jorge
Villalobos of Mozilla, inc. did say this at
https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/comment-page-3/#comment-213302 :
'We have a different solution for non-public extensions that we will
announce in the future.' To my knowledge, this has not yet been
elaborated on, one year further on from the comment -- but perhaps we
shall see movement on that before September. Villalobos also clarifies
in another comment that 'the current system only supports one [code
signature cert]', which may be why there's been no response to requests
for honouring of a local signing cert in addition to Mozilla's official
one.
[5] Unbranded
builds will also be available from the continuous integration builds on
archive.mozilla.org.
https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded_Builds
----- Forwarded message from golinux at dyne.org -----
Date: Thu, 23 Feb 2017 10:01:50 -0600
From: golinux at dyne.org
To: Dng <dng at lists.dyne.org>
Subject: [DNG] Life After Firefox 56
Lockdown/branding is not just happening to the desktop. We've known
for some time that the Firefox we've loved for over a decade is about
to suffer a similar fate. Those that like to pimp out their browser
(like me) will find this Mozillazine thread useful.
http://forums.mozillazine.org/viewtopic.php?f=7&t=3027638
Unfortunately, there's no perfect solution to the direction corporate
decisions are taking us. How will we respond? Do we want to keep
Firefox as the default browser in ascii? Or jump ship? Time to start
testing browser options and sharing experiences . . .
golinux
_______________________________________________
Dng mailing list
Dng at lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
----- End forwarded message -----
_______________________________________________
conspire mailing list
conspire at linuxmafia.com
http://linuxmafia.com/mailman/listinfo/conspire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20170224/f3fb42e3/attachment.html>
More information about the conspire
mailing list