TenFourFox FPR1 available

TenFourFox Feature Parity Release 1 is available for testing (downloads, hashes, release notes). There are no major changes from the beta except for a couple minor efficiency updates and a font blacklist update, and all remaining applicable security issues have been backported as well.

Chris T reported that old issue 72 (a/k/a bug 641597) has resurfaced in FPR1. Most likely this bug was never actually fixed, just wallpapered over by something or other, and the efficiency improvements in FPR1 have made it easier to trigger again. That said, it has only ever manifested on certain 10.5 systems; it has never been reproduced on 10.4 by anyone, and I can't reproduce it myself on my own 10.5 DLSD PowerBook G4. For that reason I'm proceeding with the release as intended but if your system is affected, please post your steps to replicate and we'll compare them with Chris' (especially if you have a 10.4 system, since that will be much easier for me to personally debug). Please also note any haxies or system extensions as the issue can be replicated on a clean profile, meaning addons or weird settings don't appear to be a factor. If we find a fix and enough people are bitten, it should be possible to spin a point release.

The plan is for a Tuesday/Wednesday release ahead of schedule, so advise if there are any new showstoppers.

Feature Parity Release Finally Preview Ready For Persistent Readers

This blog has been pretty quiet because I've been pretty busy, but now you get to play with the first TenFourFox Feature Parity Release beta (downloads, release notes, hashes).

Internally, TenFourFox FPR1 is versioned as 45.10.0 to maintain add-on compatibility (but read on for an important caveat), and all FPRs will be based on our fork of Firefox ESR 45, though the About box and the user agent show the current parity release level. This release primarily concentrated on performance and I liberally stole backported changes from Mozilla's Quantum Flow Engineering project as many of its changes touch relatively old code, so it's still applicable to us, and if the issues they're fixing are minor but noticeable on modern systems they would certainly be more noteworthy on our older machines. Most of the speed changes occur in the user interface, layout and DOM; there are some minor improvements to JavaScript as well, but that wasn't the major focus for this iteration (another big JavaScript JIT performance initiative is planned for FPR2 or FPR3, though). The overall functionality of the UI hasn't changed, however, so it should still work the way it did before. Not every enhancement I wanted to make has made it to FPR1, including one nice speedup that unfortunately also made the browser unstable, so there will be more to come in future versions. The speed difference isn't dramatic but I hope you'll agree it's a positive improvement.

Also new in FPR1 is official support for Brotli, a more efficient compression mechanism than the gzip and DEFLATE methods we currently support. Mozilla disabled this in 45 due to bugs; I secretly backported the version from ESR52 with the bugs fixed and made the (small number of) necessary changes to the browser for 45.9, which this version now enables by default. It only operates over HTTPS and on those sites that support it, but this number is expected to grow as Chrome, Firefox, Microsoft Edge and Opera all accept it.

In addition, this release introduces several new ECMAScript 6 (ES6) features to our JavaScript implementation, including Unicode regexes and block function scoping, and the ES7 exponentiation operator. Websites are already beginning to use these features, so it was essential we implement them (eventually I would like full ES6 compatibility and as much ES7 compatibility as we can reasonably achieve), but it is possible some poorly coded add-ons may barf with these changes. The syntactic changes can't really be reversed or preffed off, and add-on support in TenFourFox was always "best effort" anyhow, but please do report any changes in site and add-on compatibility that you notice between 45.9 and FPR1 so I can evaluate them. In the next couple updates I will add more ES6/ES7 features as well as some additional HTML5 and CSS3 functions that sites are beginning to adopt in keeping with the whole "feature parity" thing.

I've also been backporting relevant security patches from 52ESR to 45ESR, and our tree is now able to accept updated TLS root certificates, pinned certificates and HSTS data from 52ESR more or less directly. Eventually I still plan to update to the NSS library in 52ESR so that we can get additional cipher and encryption support, but this suffices for now. Please note that, as threatened promised, all SHA-1-only certificates are now untrusted. Most of the ESR security patches to date have been applied to the version you will be trying out except for a couple of very large changesets that need a bit more evaluation. We will be at full security parity for all known issues by the date of release.

Speaking of release date, FPR1 will be a bit delayed as I will be taking a brief vacation and I won't be at my G5 for a little while. Mozilla's release schedule has 54/52.2 coming out on June 13, which won't give me enough time to complete my work and do internal testing (hey, I'm entitled to some time off), so my current plan is to release FPR1 on or before June 27 and then catch up for FPR2 with the release of 55/52.3 on August 8. It is possible that I may delay future FPR releases until a couple days after the main ESR is released for testing and backporting reasons, but let's see how close I can adhere to the schedule still.

For builders, now that our Github is off and running, there's no need to continue distributing changesets; future releases at SourceForge will have just a placeholder instead of a zip file for source. Instead, please kindly refer to the updated build instructions.

Oh, one more thing: it looks like someone is working on an Intel version of TenFourFox again (compatible with at least 10.6 and possibly even 10.5). I won't say whom because it may be some time before anything is available, and as I've always said, this is not a release I can personally maintain even though I am happy to support and advise someone willing to, but their early work looks promising and they appear to have sufficient expertise to make it happen. Once their changes make it back into the TenFourFox github we can consider it "officially a thing." Meanwhile, although the development is occurring more or less in the open and you can probably find it without much effort, please don't pester me or them about it since it hasn't gotten off the ground yet.

Post observations in the comments and feel free to star or watch the Github repo for updates.

The аррӏе bites back

I've received a number of inquiries about whether TenFourFox will follow the same (essentially wontfix) approach of Firefox for dealing with those international domain names that happen to be whole-script homographs. The matter was forced recently by one enterprising sort who created just this sort of double using Cyrillic characters for https://www.аррӏе.com/, which depending on your font and your system setup, may look identical to https://www.apple.com/ (the site is a proof of concept only).

The circulating advice is to force all IDNs to be displayed in punycode by setting network.IDN_show_punycode to true. This is probably acceptable for most of our users (the vast majority of TenFourFox users operate with a Latin character set), but I agree with Gerv's concern in that Bugzilla entry that doing so disadvantages all other writing systems that are not Latin, so I don't feel this should be the default. That said, I also find the current situation unacceptable and doing nothing, or worse relying on DNS registrars who so far don't really care about anything but getting your money, similarly so. While the number of domains that could be spoofed in this fashion is probably small, it is certainly greater than one, and don't forget that they let the proof-of-concept author register his spoof!

Meanwhile, I'm not sure what the solution right now should be other than "not nothing." Virtually any approach, including the one Google Chrome has decided to take, will disadvantage non-Latin scripts (and the Chrome approach has its own deficiencies and is not IMHO a complete solution to the problem, nor was it designed to be). It would be optimal to adopt whatever solution Firefox eventually decides upon for consistency if they do so, but this is not an issue I'd like to sit on indefinitely. If you use a Latin character set as your default language, and/or you don't care if all domains will appear in either ASCII or punycode, then go ahead and set that pref above; if you don't, or consider this inappropriate, stay tuned. I'm thinking about this in issue 384.

By the way, TenFourFox "FPR0" has been successfully uploaded to Github. Build instructions to follow and the first FPR1 beta should be out in about two to three weeks. I'm also cogitating over a blog post discussing not only us but other Gecko forks (SeaMonkey, Pale Moon, etc.) which for a variety of reasons don't want to follow Mozilla into the unclear misty haze of a post-XUL world. To a first approximation our reasons are generally technical and theirs are primarily philosophical, but we both end up doing some of the same work and we should talk about that as an ecosystem. More later.

45.9.0 available

TenFourFox 45.9.0 is now available for testing (downloads, hashes, release notes), a bit behind due to Mozilla delaying this release until the Wednesday and my temporary inability to get connected at our extended stay apartment. The only changes in this release from the beta are some additional tweaks to JavaScript and additional expansion of the font block list. Please test; this build will go live Tuesday "sometime."

The next step is then to overlay the NSPR from 52 onto 45.9, overlay our final stack of changesets, and upload that as the start of FPR1 and our Github repository. We can then finally retire the changesets and let them ride off into the sunset. Watch for that in a couple weeks along with new build instructions.

TenFourFoxBox 1.0.1 available

As Steven Tyler howls he's Done With Mirrors from my G5's CD, TenFourFoxBox 1.0.1 is available for testing from this totally s3kr1t download location. This is a minor custodial release that bumps the "stealth" user agent to Firefox 52 on macOS Sierra and changes the official map app to OpenStreetMap which has rather better performance. Assuming no problems, it will go live later this week, probably Wednesday Pacific time.

45.9.0b1 available

TenFourFox 45.9.0 beta 1 is now available (downloads, hashes). This version continues deploying more of the multiple microoptimizations started with 45.8, including rescheduling xptcall which is the glue used for calling XPCOM functions (use CTR instead of LR for branching, reorder instructions to eliminate register and FXU dependencies), more reduced branches, hoisting call loads earlier in code sequences, optimized arithmetic inline caches for both Baseline and Ion code generation (especially integer operations for division, min/max and absolute value), fixing a stupid bug which used a branchy way of doing logical comparisons on floating point values (this passed tests but was unnecessarily inefficient), and eliminating some irrelevant branches in font runs and graphics. While I was at it I cherrypicked a few other minor perf boosts from 46 and stuck those in as well.

Also, the font blacklist is updated (fixing Apple and Medium) along with new support for blocking ATSUI-incompatible data:font/* URLs, and there is a speculative fix for the long-running issue of making changing the default search engine stick (this is difficult for me to test because none of my systems seem to be affected). The guts for repairing geolocation are in this version too but I'm still dithering over the service; most likely we will use the Mozilla Location Service though I'm open to other suggestions. Remember that the only sensor data Power Macs can provide for geolocation out of the box is the WiFi SSIDs they see (but this is perfectly sufficient for MLS). This should be finalized by the time 45.9 goes to release.

For FPR1, the first feature I'm planning to implement is one that was cancelled for 45 during beta: Brotli compression, which on supported sites can reduce data transfer by 14 to 39 percent with little impact on decompression time. This will involve backporting the current Brotli decompressor from 52ESR and then making necessary changes to Necko to support it, but happily much of the work was already done before it was disabled (for a critical bug that could not be easily worked around at the time) and released in 46. If there is sufficient time, I'd also like to implement the "New Hot NSS" (get it?) and backport the NSS security and encryption library from 52ESR as well, both of which will also reduce the burden of backporting security fixes. That's a bit of a bigger job, though, and might be FPR2 territory. Other major want-to-dos will be some JavaScript ES6 features I predict will be commonly used in the near future like Unicode regexes and changes to function scoping, both of which landed in 46 and should be easy to add to 45.

Only one site has been reported as incompatible with our plan to shut down SHA-1 certificate support with FPR1. As mentioned, it would take a major site failure for me to call this plan off, but I'd still like as much testing as possible beforehand. If you haven't done it already, please go into about:config and switch security.pki.sha1_enforcement_level to 1, and report any sites that fail. This approach of complete decommissioning is essentially the same policy Google Chrome will be taking, and soon no major browser will accept SHA-1 certificates as trusted for TLS, so it's not like we're going out on a limb here. Please note that reversing this change will not be a supported configuration because (the security implications notwithstanding) it may be un-possible to allow doing so after the new NSS library is eventually transplanted in.

Once 45.9 comes out, we will switch to our own Github repository and the source code will be uploaded and maintained from there (no more changeset overlays!). However, pull requests won't be accepted unless they're tied to an issue already accepted on the worklist, and we will still enforce the policy that non-contributor bug reports need to be triaged through Tenderapp first. Watch for the repo's magical population shortly after 45.9's final release on April 18.

Unfortunately, I don't think there will be a Tenfourbird FPR1: it appears that our anonymous colleague in the Land of the Rising Sun has not made any builds since 38.9, and that is a real shame. :(

45.8.1 not available (also: 45.9 and FPR1 progress, and goodbye, App.net)

TenFourFox 45.8.1 is not available, because there isn't one, even though Firefox 52.0.1 is available to fix the fallout from Pwn2Own. However, the exploited API in question does not exist in Firefox 45 (against which we are based) and a second attack against Firefox was apparently unsuccessful, so at least right now no urgent TenFourFox chemspill is required. 45.9, the last release we will make at source parity against the Mozilla code base, is still on schedule for April 18th.

45.9 has more microimprovements to JavaScript, including some sections of hand-written assembly code that have been completely overhauled (especially in the inline caches for arithmetic operations) and fixing a stupid bug that caused logical comparisons on floating point operations to always hit a slow code path, some additional microimprovements to hard-coding code flow with xptcall, graphics and text runs, and then bug fixes for geolocation and the font blacklist. The last two should be done by the end of next week or slightly after, and then after I test it internally there will be a beta prior to release.

Today, though, I've been playing with Google's new Guetzli JPEG encoder, which promises higher compression ratios with great quality that any JPEG decoder can view, because you really can have "tastes great" and "less filling" at the same time, apparently. Yes, I was able to get it to compile on the Power Mac and it works pretty well on my G5 from the command line; I'm trying to package it as a drag-and-drop tool which I might release a little later if I have time. If Guetzli takes off, maybe Google will stop it with their stupid WebP fetish since this is a much better solution and far more compatible.

Finally, yesterday was the last day of App.net, fondly called "ADN" by denizens such as myself, Martin, Sevan and Riccardo. It unfairly got tarred as a "pay Twitter clone," which in fairness its operators didn't do enough to dispel, though most of us longtimers think that the service sealed its doom when they moved from a strictly pay model to a freemium model. That then destabilized the service by allowing a tier of user that wasn't really invested in its long-term success (like, say, blog spammers, etc.), and it gradually dropped below profitability because the pay tier didn't offer enough at that point.

But ADN had a real sense of community that just doesn't exist with Facebook, nor Twitter in particular. There were much fewer trolls and mob packs, and those that did engage in that behaviour found themselves ostracised quickly. Furthermore, you didn't have the sense of people breathing down your neck or endlessly searching for victims who might post the wrong thing so they can harass and "out" you for not toeing the party line. I think the smaller surface area and user base really led to that kind of healthier online relating, and I still believe that a social media service that forces a smaller number of people to be invested in the success of that service -- that in turn treats them as customers and not cattle -- is the most effective way to get around the problems the large free social sites have.

Meanwhile, most of us ADN refugees have moved to Pnut, made by another ADN denizen. Pnut is getting around the jerk problem by going invite-only. If you're not a jerk and you're interested in a better community to socially interact online, contact me and I'll get you a code.

Here are the last moments of the ADN global stream, as witnessed by Texapp, my custom ADN client. Thanks, Dalton and Bryan, and all the great ADN staff that participated over the years. It was a good ride while it lasted.