Thursday, April 20, 2017

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 (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.

Monday, April 17, 2017

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.

Sunday, April 9, 2017

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.

Saturday, March 25, 2017

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. :(

Friday, March 17, 2017

45.8.1 not available (also: 45.9 and FPR1 progress, and goodbye,

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, 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.

Saturday, March 4, 2017

45.8.0 available

TenFourFox 45.8.0 is now available for testing (downloads, hashes, release notes). As usual it will go live Monday PM, likely when I get to my conference in the Bay Area. This includes everything in the beta plus some additional fontblocked URLs and a last-minute tweak to the font spacing kludge for certain wacky but otherwise valid fixed width webfonts.

For 45.9, there will be some additional performance improvements to xptcall (better scheduling of the PowerPC assembly language glue that links XPCOM calls), additional work on Operation Short Change, better hinting of branches the JavaScript JIT emits, additional marginal improvements to text run generation and more font blacklisting. Chris noticed geolocation has been broken since at least TenFourFox 24, so we'll fix that, and I'm also toying with a concept where a garbage collection cycle is automatically run whenever a tab closes to recover the memory deterministically instead of random pauses later.

After incorporating a number of suggestions from you, there is now a semi-official archive of compatible addons for TenFourFox. This is not to say only these addons are supported; it's just to make convenient finding ones of significance that do work. If you have other recommendations, please advise. I'm still studying the right way to directly install from this folder without opening up a security hole.

Watch for the 45.9 beta in about two or three weeks.

Saturday, February 25, 2017

Farewell to SHA-1 and hello to TenFourFox FPR1

The long-in-the-tooth hashing algorithm SHA-1 has finally been broken by its first collision attack (and the broken SHA-1 apparently briefly broke the WebKit repository, too). SHA-1 SSL TLS certificates have been considered dangerous for some time, which is why the Web has largely moved on to SHA-256 certificates and why I updated Classilla to support them.

Now that it is within the realm of practical plausibility to actually falsify site certificates signed with SHA-1 and deploy them in the real world, it's time to cut that monkey loose. Mozilla is embarking on a plan of increasing deprecation, but Google is dumping SHA-1 certificates entirely in Chrome 56, in which they will become untrusted. Ordinarily we would follow Mozilla's lead here with TenFourFox, but 45ESR doesn't have the more gradated current SHA-1 handling they're presently using.

So, we're going to go with Chrome's approach and shut the whole sucker down. The end of 45ESR (and the end of TenFourFox source parity) will occur on June 13 with the release of Firefox 54 (52.2 ESR); the last scheduled official 45ESR is 45.9, on April 18. For that first feature parity release of TenFourFox in June after 45.9, security.pki.sha1_enforcement_level will be changed from the default 0 (permit) to 1 (deny) and all SHA-1 certificates will become untrusted. You can change it back if you have a server you must connect to that uses a SHA-1 certificate to secure it, but this will not be the default, and it will not be a supported configuration.

You can try this today. In fact, please do switch over now and see what breaks; just go into about:config, find security.pki.sha1_enforcement_level and set it to 1. The good news is that Mozilla's metrics indicate few public-facing sites should be affected by this any more. In fact, I can't easily find a server to test this with; I've been running with this setting switched over for the past day or so with nothing gone wrong. If you hit this on a site, you might want to let them know as well, because it won't be just TenFourFox that will refuse to connect to it very soon. TBH, it would have to cause problems on a major, major site for me not to implement this change because of the urgency of the issue, but I want to give our users enough time to poke around and make sure they won't suddenly be broken with that release.

That release, by the way, will be the end of TenFourFox 45 and the beginning of the FPR (Feature Parity Release) series, starting with FPR1. Internally the browser will still be a fork of Gecko 45 and addons that ask its version will get 45.10 for FPR1 and 45.11 for FPR2 and so on, but the FPR release number will now appear in the user agent string as well as the 45.x version number, and the About box and site branding will now reference the current FPR number instead. The FPR will not necessarily be bumped every release: if it's a security update only and there are no new major features, it will get an SPR bump instead (Security Parity Release). FPR1 (SPR2) would be equivalent, then, to an internal version of 45.10.2.

Why drop the 45 branding? Frankly, because we won't really be 45.* Like Classilla, where I backported later changes into its Mozilla 1.3.1 core, I already have a list of things to add to the TenFourFox 45 core that will improve JavaScript ES6 compatibility and enable additional HTML5 features, which will make the browser more advanced. Features post-52ESR will be harder to backport as Mozilla moves more towards Rust code descended from Servo and away from traditional C++ and XPCOM, but there is a lot we can still make work, and unlike Classilla we won't be already six years behind when we get started.

The other thing we need to start thinking about is addons. There is no XUL, only WebExtensions, according to Mountain View, and moreover we'll be an entire ESR behind even if Mozilla ends up keeping legacy XUL addons around. While I don't really want to be in the business of maintaining these addons, we may want to archive a set of popular ones so that we don't need to depend on AMO. Bluhell Firewall, uBlock, Download YouTube Videos as MP4 and OverbiteFF are already on my list, and we will continue to host and support the QuickTime Enabler. What other ones of general appeal would people like added to our repository? Are there any popular themes or Personas we should keep copies of? (No promises; the final decision is mine.)

The big picture is still very bright overall. We'll have had almost seven years of source parity by June, and I think I can be justifiably proud of that. Even the very last Quad G5 to roll off the assembly line will have had almost eleven years of current Firefox support and we should still have several more years of practical utility in TenFourFox yet. So, goodbye SHA-1, but hello FPR1. The future beckons.

(* The real reason: FPR and SPR are absolutely hilarious PowerPC assembly language puns that I could backronym. I haven't figured out what I can use for GPR yet.)