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