TenFourFox FPR20b1 available

TenFourFox Feature Parity Release 20 beta 1 is now available (downloads, hashes, release notes). Now here's an acid test: I watched the entire Democratic presidential debate live-streamed on the G5 with TenFourFox FPR20b1 and the MP4 Enabler, and my G5 did not burst into flames either from my code or their rhetoric. (*Note: Any politician of any party can set your G5 on fire. It's what they do.)

When using FPR20 you should notice ... absolutely nothing. Sites should just appear as they do; the only way you'd know anything changed in this version is if you pressed Command-I and looked at the Security tab to see that you're connected over TLS 1.3, the latest TLS security standard. In fact, the entirety of the debate was streamed over it, and to the best of my knowledge TenFourFox is the only browser that implements TLS 1.3 on Power Macs running Mac OS X. On regular Firefox your clue would be seeing occasional status messages about handshakes, but I've even disabled that for TenFourFox to avoid wholesale invalidating our langpacks which entirely lack those strings. Other than a couple trivial DOM updates I wrote up because they were easy, as before there are essentially no other changes other than the TLS enablement in this FPR to limit the regression range. If you find a site that does not work, verify first it does work in FPR19 or FPR18, because sites change more than we do, and see if setting security.tls.version.max to 3 (instead of 4) fixes it. You may need to restart the browser to make sure. If this does seem to reliably fix the problem, report it in the comments. A good test site is Google or Mozilla itself. The code we are using is largely the same as current Firefox's.

I have also chosen to enable Zero Round Trip Time (0-RTT) to get further speed. The idea with 0RTT is that the browser, having connected to a particular server before and knowing all the details, will not wait for a handshake and immediately starts sending encrypted data using a previous key modified in a predictable fashion. This saves a handshake and is faster to establish the connection. If many connections or requests are made, the potential savings could be considerable, such as to a site like Google where many connections may be made in a short period of time. 0RTT only happens if both the client and server allow it and there are a couple technical limitations in our implementation that restrict it further (I'm planning to address these assuming the base implementation sticks).

0RTT comes with a couple caveats which earlier made it controversial, and some browsers have chosen to unconditionally disable it in response. A minor one is a theoretical risk to forward secrecy, which would require a malicious server caching keys (but a malicious server could do other more useful things to compromise you) or an attack on TenFourFox to leak those keys. Currently neither is a realistic threat at present, but the potential exists. A slightly less minor concern is that users requiring anonymity may be identified by 0RTT pre-shared keys being reused, even if they change VPNs or exit nodes. However, the biggest is that, if handled improperly, it may facilitate a replay attack where encrypted data could be replayed to trigger a particular action on the server (such as sending Mallory a billion dollars twice). Firefox/TenFourFox avoid this problem by never using 0RTT when a non-idempotent action is taken (i.e., any HTTP method that semantically changes state on the server, as opposed to something that merely fetches data), even if the server allows it. Furthermore, if the server doesn't allow it, then 0RTT is not used (and if the server inappropriately allows it, consider that their lack of security awareness means they're probably leaking your data in other, more concerning ways too).

All that said, even considering these deficiencies, TLS 1.3 with 0-RTT is still more secure than TLS 1.2, and the performance benefits are advantageous. Thus, the default in current Firefox is to enable it, and I think this is the right call for TenFourFox as well. If you disagree, set security.tls.enable_0rtt_data to false.

FPR20 goes live on or about March 10.

TenFourFox FPR19 available

Due to a busy work schedule and $REALLIFE, TenFourFox Feature Parity Release 19 final is just now available for testing (downloads, hashes, release notes). This version is the same as the beta except for a couple URL bar tweaks I meant to land and the outstanding security updates. If all goes well, it will go live tomorrow Pacific time in the evening.

Since the new NSS is sticking nicely, FPR20 will probably be an attempt at enabling TLS 1.3, and just in time, too.

TenFourFox FPR19b1 available

TenFourFox Feature Parity Release 19 beta 1 is now available (downloads, hashes, release notes). I was originally going to do more iteration on Reader mode in FPR19, but in a possible recurrence of the issue that broke SourceForge downloads temporarily, a user reported on Tenderapp they had a site that was failing in the same way.

On the test system I was able to reproduce the problem and it was due to the selected cipher having insufficient cryptographic strength to pass HTTP/2 TLS profile validation. The selected cipher was one I added as a stopgap for FPR7 to fix another site which was still working (and did not use HTTP/2, hence it didn't exhibit the issue). Disabling that cipher restored the new failing site, but caused the site I put the workaround for in FPR7 to fail, so in no situation could I get both sites to be happy with the set available. Although I didn't really want to do this, the only real solution here was to upgrade NSS, the underlying cryptographic library, to add additional more modern ciphers to replace the older one that now needed to be reverted. With this in place and some other fixes, now both sites work, and this probably fixes others.

The reason I was reticent to update NSS (and the underlying NSPR library) was because of some custom changes and because I was worried changes in cipher coverage would break compatibility. However, there wasn't a lot of choice here, so I manually patched up our custom AltiVec-accelerated NSPR to a current release and spliced in a newer NSS overlaid with our build system changes. I tested this on a few sites I knew to be using old crypto libraries and they still seemed to connect fine, and as a nice side benefit some of the more modern ciphers are more efficient and therefore improve throughput a bit. It also makes the likelihood of successfully updating TenFourFox to support TLS 1.3 much higher; if this sticks, I may attempt this as soon as FPR20.

There are a couple sundry minor changes to be implemented at final release, mostly minor bug fixes, but I want to get this beta in testing as quickly as possible within the shrinking rapid release timeframe. I have otherwise intentionally limited the scope of FPR19 to mostly just the crypto upgrade so that we have a clear regression range. If you notice sites have stopped being accessible in FPR19, please verify they are working in FPR18 (people say "I remember it worked," but sites change more than TenFourFox does, so please check and save us some time here), and if it does indeed work in FPR18 report it in the comments so I can analyse the problem. I am very unlikely to revert this change given that it's necessary going forward and probably the best of the available options, but if I can add exceptions that don't compromise overall security I'm willing to do so in the name of supporting backwards compatibility with sites the browser used to be able to access. FPR19 goes final parallel with Firefox 73 and 68.5 somewhere around February 11.

TenFourFox not vulnerable to CVE-2019-17026

After doing some analysis late last night and today to determine if we need a chemspill build, I have concluded that TenFourFox is not vulnerable to CVE-2019-17026, or at least not to any of the PoCs or test cases available to me. This is the 0-day that was fixed in Firefox 72.0.1 and 68.4.1. Though a portion of the affected code exists in the TenFourFox code base, there doesn't seem to be a way to trigger the exploit due to various other missing optimizations and the oddities of our JIT. (Firefox 45-based browsers using our patches as upstream should bear in mind this may not be true for other architectures, however.) Absent evidence to the contrary it will be nevertheless patched as part of the standard security fixes in FPR19.

The new Overbite Android (works with Firefox Android too): Gopherspace on your mobile Android device

Since this blog is syndicated to Planet Mozilla and I periodically post Mozilla- and Firefox-relevant posts, here is another: if you still dwell in Gopherspace and use OverbiteWX and OverbiteNX on desktop Firefox, Overbite Android has been updated to full Android Q compatibility so you can use it with Android Firefox as well. Instead of an add-on, just sideload the .apk, and whenever you tap a Gopher URL in Firefox it will automatically load in Overbite Android so you can seamlessly jump back and forth. (Or Chrome, I guess, but who uses that?)

Naturally Overbite Android works just fine as a standalone application and responds to any gopher:// intent sent by any other activity, including Firefox. However, this latest version has been updated specially for Android Q support, including dark theme:

I also purged a lot of the old API usage, replacing it with a more Material Design-style UI, an actual address bar you can edit for a change, and a dynamic menu off a floating action button (as opposed to the old school Menu button menu, support for which was removed from Android Q). There are also fixes to scrolling and zooming, and you can still generate and drop shortcuts on your Android launcher as bookmarks.

Now that I've gotten off my butt and converted it to Android Studio, I suppose I should start working on download support again but everything else (including searches) functions just dandy.

Overbite Android is offered to you under the BSD license and supports 4.0 (Ice Cream Sandwich) through 10 (Q). You can get it, the Android Studio project and source code, and all the rest of the Overbite gopher client family from the Overbite website or directly from Gopherspace.

TenFourFox FPR18 available (and the classic MacOS hits Y2K20)

TenFourFox Feature Parity Release 18 final is now available for testing (downloads, hashes, release notes). There are no other changes from the beta other than to update the usual certs and such. As usual, assuming no late-breaking critical bugs, it will become final Monday evening Pacific time.

Meanwhile, happy new year: classic Mac systems prior to Mac OS 9 are now hit by the Y2K20 bug, where you cannot manually use the Date and Time Control Panel to set the clock to years beyond 2019 (see also Apple Technote TN1049). This does not affect any version of MacOS 9 nor Classic on OS X, and even affected versions of the classic MacOS can still maintain the correct date until February 6, 2040 at 6:28:15 AM when the unsigned 32-bit date overflows. If you need to set the date on an older system or 68K Mac, you can either use a CDEV like Network Time, which lets you sync to a network time source or a local server if you have one configured (as I do), or you can use Rob Braun's SetDate, which allows you to manually enter a date or time through the entire supported range (and even supports System 6).

One other note is that all HFS+ volumes regardless of operating system version have the same year 2040 limit on dates -- that includes Intel Macs using HFS+ filesystems. You have 20 years to think about how you want to fix this (during which you should replace the PRAM batteries in your classic Macs, too).

And now for something completely different: The dawning of the Age of Apple Aquarius

An interesting document has turned up at the Internet Archive: the specification to the Scorpius CPU, the originally intended RISC successor to the 68K Macintosh.

In 1986 the 68K processor line was still going strong but showing its age, and a contingent of Apple management (famously led by then-Mac division head Jean-Louis Gassée and engineer Sam Holland) successfully persuaded then-CEO John Sculley that Apple should be master of its own fate with its own CPU. RISC was just emerging at that time, with the original MIPS R2000 CPU appearing around 1985, and was clearly where the market was going (arguably it still is, since virtually all major desktop and mobile processors are load-store at the hardware level today, even Intel); thus was the Aquarius project born. Indeed, Sculley's faith in the initiative was so great that he allocated a staff of fifty and even authorized a $15 million Cray supercomputer, which was smoothed over with investors by claiming it was for modeling Apple hardware (which, in a roundabout and overly optimistic way, it was).

Holland was placed in charge of the project and set about designing the CPU for Aquarius. The processor's proposed feature set was highly ambitious, including four cores and SIMD (vector) support with inter-processor communication features. Holland's specification was called Scorpius; the initial implementation of the Scorpius design was to be christened Antares. This initial specification is what was posted at the Internet Archive, dated around 1988.

Despite Sculley and Gassée's support, Aquarius was controversial at Apple from the very beginning: it required a substantial RandD investment, cash which Apple could ill afford to fritter away at the time, and even if the cash were there many within the company did not believe Apple had sufficient technical chops to get the CPU to silicon. Holland's complex specification worried senior management further as it required solving various technical problems that even large, highly experienced chip design companies at the time would have found difficult.

With only a proposal and no actual hardware by 1988, Sculley became impatient, and Holland was replaced by Al Alcorn. Alcorn was a legend in the industry by this time, best known for his work at Atari, where he designed Pong and was involved in the development of the Atari 400 and the ill-fated "holographic" Atari Cosmos. After leaving Atari in 1981, he consulted for various companies and was brought in by Apple as outside expertise to try to rescue Aquarius. Alcorn pitched the question to microprocessor expert Hugh Martin, who studied the specification and promptly pronounced it "ridiculous" to both Alcorn and Sculley. On this advice Sculley scuttled Aquarius in 1989 and hired Martin to design a computer instead using an existing CPU. Martin's assignment became the similarly ill-fated Jaguar project, which completed poorly with another simultaneous project led by veteran engineer Jack McHenry called Cognac. Cognac, unlike Jaguar and Aquarius, actually produced working hardware. The "RISC LC" that the Cognac team built, originally a heavily modified Macintosh LC with a Motorola 88100 CPU running Mac OS, became the direct ancestor of the Power Macintosh. The Cray supercomputer, now idle, eventually went to the industrial design group for case modeling until it was dismantled.

Now that we have an actual specification to read, how might this have compared to the PowerPC 601? Scorpius defined a big-endian 32-bit RISC chip addressing up to 4GB of RAM with four cores, which the technical specification refers to as processing units, or PUs. Each core shares instruction and data caches with the others and communicates over a 5x4 crossbar network, and because all cores on a CPU must execute within the same address space, are probably best considered most similar to modern hardware threads (such as the 32 threads on the SMT-4 eight core POWER9 I'm typing this on). An individual core has 16 32-bit general purpose registers (GPRs) and seven special purpose registers (SPRs), plus eight global SPRs common to the entire CPU, though there is no floating-point unit in the specification we see here. Like ARM, and unlike PowerPC and modern Power ISA, the link register (which saves return addresses) is a regular GPR and code can jump directly to an address in any register. However, despite having a 32-bit addressing space and 32-bit registers, Scorpius uses a fixed-size 16-bit instruction word. Typical of early RISC designs and still maintained in modern MIPS CPUs, it also has a branch delay slot, where the instruction following a branch (even if the branch is taken) is always executed. Besides the standard cache control instructions, there are also special instructions for a core to broadcast to other cores, and the four PUs could be directed to work on data in tandem to yield SIMD vector-like operations (such as what you would see with AltiVec and SSE). Holland's design even envisioned an "inter-processor bus" (IPB) connecting up to 16 CPUs, each with their own local memory, something not unlike what we would call a non-uniform memory access (NUMA) design today.

The 16-bit instruction size greatly limits the breadth of available instructions compared to PowerPC's 32-bit instructions, but that would certainly be within the "letter" spirit of RISC. It also makes the code possibly more dense than PowerPC, though the limited amount of bits available for displacements and immediate values requires the use of a second prefix register and potentially multiple instructions which dampens this advantage somewhat. The use of multiple PUs in tandem for SIMD-like operations is analogous to AltiVec and rather more flexible, though the use of bespoke hardware support in later SIMD designs like the G4 is probably higher performance. The lack of a floating-point unit was probably not a major issue in 1986 but wasn't very forward-looking as every 601 shipped with an FPU standard from the factory; on the other hand, the NUMA IPB was very adventurous and certainly more advanced than multiprocessor PowerPC designs, something that wasn't even really possible until the 604 (or not without a lot of hacks, as in the case of the 603-based BeBox).

It's ultimately an academic exercise, of course, because this specification was effectively just a wish list whereas the 601 actually existed, though not for several more years. Plus, the first Power Macs, being descendants of the compatibility-oriented RISC LC, could still run 68K Mac software; while the specification doesn't say, Aquarius' radical differences from its ancestor suggests a completely isolated architecture intended for a totally new computer. Were Antares-based systems to actually emerge, it is quite possible that they would have eclipsed the Mac as a new and different machine, and in that alternate future I'd probably be writing a droll and informative article about the lost RISC Mac prototype instead.