It's baaaaa-aaack: TenFourFox Intel

A polite reminder: if you're going to link to this build, link to this post please so that people can understand this build doesn't have, nor will it ever have, official support.

It's back! It's undead! It's ugly! It's possibly functional! It's totally unsupported! It's ... TenFourFox for Intel Macs!

Years ago as readers of this blog will recall, Claudio Leite built TenFourFox 17.0.2 for Intel, which the update check-in server shows some determined users are still running to this day on 10.5 and even 10.4 despite various problems such as issue 209. However, he didn't have time to maintain it, and a newer version was never built, though a few people since then have made various attempts and submitted some patches.

One of these attempts is now far enough along to the point where I'm permitted to announce its existence. Riccardo Mottola has done substantial work on getting TenFourFox to build and run again on old Intel Macs with a focus on 32-bit compatibility, and his patches have been silently lurking in the source code repository for some time. Along with Ken Cunningham's additional work, who now also has a MacPorts portfile so you can build it yourself (PowerPC support in the portfile is coming, though you can still use the official instructions, of course), enough functions in the new Intel build that it can be used for basic tasks.

There are still known glitches in the build, including ones which may be severe, and currently Ken's portfile disables the JavaScript JIT due to crash bugs which have not yet been smoked out. (That said, even running in strict interpreter mode, the browser is still much faster than TenFourFox under Rosetta which has no JIT and must run emulated.) If you find one of these glitches, you get to deal with it all by yourself because the support level (i.e., none) hasn't changed. To wit:

• The Power Mac is still the focus of development for TenFourFox, and anything else is best effort. Don't expect any Intel-specific bugs to ever be fixed. If anything does actually get fixed on Intel, be grateful.
• The Intel version will never supersede the PowerPC version. Although I'll try not to intentionally break the Intel build, I may unintentionally do so, and if a bug crops up which requires breaking the Intel build to fix an issue with the PowerPC build, the Intel build will be broken until someone figures out what to do.
• Intel builds remain unsupported and will probably never be supported. Do not post problems with the build to Tenderapp. Don't complain to Riccardo or Ken. Definitely don't complain to me. In fact, unless you're willing to figure out how to solve a problem you're encountering, don't expect anybody to care about any problem you have running the Intel build.
• There may never be any Intel builds issued by anyone ever again except for whatever build you make for your own use. Don't complain about this on Tenderapp. Don't beg (bug) Riccardo or Ken for updates. Definitely don't beg (bug) me.

If you are allergic to actually doing work and want to mooch off someone else's (ahem), then Ken has provided a 10.5 Leopard build of FPR9 for 32-bit Intel. This version should work on 10.6-10.8 as well, but obviously not on 10.4; although the browser should still be able to be built on Tiger Intel, right now you'll have to do that yourself with the portfile or the official build instructions. You can get Ken's contributed build from SourceForge. As I said, you should not expect it to ever be updated, but if there is another future release, you can get it from the same directory whenever I get around to uploading it (which you shouldn't expect either).

As before, good news if it works for you, too bad if it doesn't, and please don't make Riccardo, Ken or me regret ever bringing the Intel build back. Again, do not report bugs in the Intel version to Tenderapp, and do not open Github issues unless you have code to contribute.

TenFourFox FPR10b1 available

TenFourFox Feature Parity 10 beta 1 is now available (downloads, hashes, release notes). This version is mostly about expanded functionality, adding several new DOM and JavaScript ES6 features, and security changes to match current versions of Firefox. Not everything I wanted to get done for this release got done, particularly on the JavaScript side (only one of the ES6 well-known symbols updates was finished in time), but with Firefox 63 due on the 22nd we'll need this period for sufficient beta testing, so here it is.

The security changes include giving document-level (i.e., docshell) data: URIs unique origins to reduce cross-site scripting attack surface (for more info, see this Mozilla blog post from Fx57). This middle ground should reduce issues with the older codebase and add-on compatibility problems, but it is possible some historical add-ons may be affected by this and some sites may behave differently. However, many sites now assume this protection, so it is important that we do the same. If you believe a site is behaving differently because of this, toggle the setting security.data_uri.unique_opaque_origin to false and restart the browser. If the behaviour changes, then this was the cause and you should report it in the comments. This covers most of the known exploits of the old Firefox behaviour and I'll be looking at possibly locking this down further in future releases.

The other notable security change is support for noopener, but using the soon-to-be-current implementation in Firefox 63. This feature prevents new windows (that were presumably unwittingly) opened to a malicious page from that page then trying to manipulate the page that opened it, and many sites already support it.

This release also now prefs MSE (and VP9) to on by default, since YouTube seems to require it. We do have AltiVec acceleration for VP9 (compare with libvpx for Chromium on little-endian PowerPC), but VP9 is a heavier codec than VP8, and G4 and low-end G5 systems will not perform as well. You can still turn it off for sites that seem to do better with it disabled.

There are two known broken major sites: the Facebook display glitch (worse on 10.5 than 10.4, for reasons as yet unexplained), and Citibank does not load account information. Facebook can be worked around by disabling Ion JavaScript acceleration, but I don't advise this because of the profound performance impact and I suspect it's actually just fixing a symptom because backing out multiple changes in JavaScript didn't seem to make any difference. As usual, if you can stand Facebook Basic, it really works a lot better on low-power systems like ours. Unfortunately, Citibank has no such workaround; changing various settings or even user agents doesn't make any difference. Citibank does not work in versions prior to Fx51, so the needful could be any combination of features newly landed in the timeframe up to that point. This is a yuuuge range to review and very slow going. I don't have a fix yet for either of these problems, nor an ETA, and I'm not likely to until I better understand what's wrong. Debugging Facebook in particular is typically an exercise in forcible hair removal because of their multiple dependencies and heavy minification, and their developer account has never replied to my queries to get non-minified sources.

So, in the absence of a clear problem to repair, my plan for FPR11 is to try to get additional well-known symbols supported (which should be doable) and further expand our JavaScript ES6/ES7 support in general. Unfortunately for that last, I'm hitting the wall on two very intractable features because of their size which are starting to become important for continued compatibility. In general my preference is to implement new features in as compartmentalized a fashion as possible and preferably in a small number of commits that can be backed out without affecting too much else. These features, however, are enormous in scope and changes, and depend on many other smaller changes we either don't need, don't want or don't implement. They also tend to affect code outside of JavaScript such as the script loading environment and the runtime, which is problematic because we have very poor test coverage for those areas.

The first is modules (we do support classes, but not modules), introduced in Firefox 60. The metabug for this is incredibly intimidating and even the first "milestone 0" has a massive number of dependencies. The script loader changes could probably be implemented with some thought, but there is no way a single programmer working in his spare time can do the entire amount of work required and deal with all the potential regressions, especially when rebuilding JavaScript takes up to 20 minutes and rebuilding the browser takes several hours or more. The silver lining is that some sites may need refactoring to take advantage of modules, so wide adoption is not likely to occur in the near term until more frontend development tools start utilizing them.

The second, unfortunately, is already being used now: async functions, introduced in Firefox 52, and really co-routines by any other name. The work to support them in the parser is not trivial but I've mostly completed it, and some of that code is (silently) in FPR10. Unfortunately, the await keyword works in terms of ES6 Promises, which we definitely do not support (we only have support for DOM Promises, which are not really interchangeable at the code level), and which extend hooks into the browser event loop to enable them to run asynchronously. You can see the large number of needed changes and dependencies in that Github issue as well as the various changes and regressions that resulted. This problem is higher priority because the feature is tempting to developers and some sites already make use of them (you usually see an odd syntax error and stuff doesn't load in those situations); the code changes needed to convert a function to asynchronous operation are relatively minor while yielding (ahem) a potentially large benefit in terms of perceived speed and responsiveness. However, there is no good way to make this work without ES6 Promise, and the necessary parser changes may cause code to run that can never run correctly even if the browser accepts it.

I don't have good solutions for these looming problems but I'll try to continue making progress on what I know I can fix or implement and we'll examine what this means for feature parity as time progresses. Meanwhile, please try out the beta and post your comments, and expect FPR10 final later this month.

TenFourFox and Hack2Win

After a diligent analysis of the test cases and our existing code, TenFourFox is not known to be vulnerable to the exploits repaired in Firefox 62.0.3/60ESR. Even if the flaws in question actually existed as such in our code, they would require a PowerPC-specific exploit due to some architecture-dependent aspects of the attacks.

Fruitfly and the Power Mac

First, some updates on TenFourFox FPR10. There are a couple of security related changes, some DOM updates and some JavaScript ES6 compatibility updates which should fix a few site glitches. However, I'm also trying to track down a debug-only regression in layout present in at least FPR9 and possibly earlier, and there are at least two major sites broken that I do not have a clear understanding of why (and are not regressions). Unfortunately, it is unlikely there will be a solution in time since FPR10 is timed to come out with the next Firefox on October 23ish.

New information came to light recently regarding Fruitfly, also detected by some antivirus systems as Quimitchin, which was discovered quietly infecting machines in January 2017. An unusual Mac-specific APT that later was found to have Windows variants (PDF), Fruitfly was able to capture screenshots, keystrokes, images from the webcam and system information from infected machines. At that time it was believed it was at most a decade old, placing the earliest possible infections in that timeline around 2007 and thus after the Intel transition. The author, 28-year-old Phillip Durachinsky, was eventually charged in January of this year with various crimes linked to its creation and deployment.

Late last month, however, court documents demonstrated that Durachinsky actually created the first versions of Fruitfly when he was 14 years old, i.e., 2003. This indicates there must be a PowerPC-compatible variant which can infect systems going back to at least Panther and probably Jaguar, and squares well with contemporary analyses that found Fruitfly had "ancient" system calls in its code, including, incredibly, GWorld and QuickDraw ones.

The history the FBI relates suggests that early infections were initiated manually by him, largely for the purpose of catching compromising webcam pictures and intercepting screenshots and logins when users entered keystrokes suggesting sexual content. If you have an iSight with the iris closed, though, there was no way he could trigger that because of the hardware cutoff, another benefit of having an actual switch on our computer cameras (except the iMac G5, which was a bag of hurt anyway and one of the few Power Macs I don't care for).

Fruitfly spreads by attacking weak passwords for AFP (Apple Filing Protocol) servers, as well as RDP, VNC, SSH and (on later Macs) Back to My Mac. Fortunately, however, it doesn't seem to get its hooks very deep into the OS. It can be relatively easily found by looking for a suspicious launch agent in ~/Library/LaunchAgents (a Power Mac would undoubtedly be affected by variant A, so check ~/Library/LaunchAgents/com.client.client.plist first), and if this file is present, launchctl unload it, delete it, and delete either ~/.client or ~/fpsaud depending on the variant the system was infected with. After that, change all your passwords and make sure you're not exposing those services where you oughtn't anymore!

For the very early pre-Tiger versions, however, assuming they exist, no one seems to know how currently those might have been kicked off because those systems lack launchd. It's possible it could have insinuated itself as a login item or into the system startup scripts, or potentially the Library/StartupItems folder, but it's probable we'll never know for sure because whatever infected systems dated from that time period have either been junked or paved over. Nevertheless, if you find a file named ~/.client on your system regardless of version that you didn't put there, assume you are infected and proceed accordingly.

R.I.P., Charles W. Moore, a fine man who liked fine Macs

A farewell and au revoir to a great gentleman in making the most of your old Mac, Charles W. Moore, who passed away at his home in rural Canada on September 16 after a long illness. Mr Moore was an early fan of TenFourFox, even back in the old bad Firefox 4 beta days, and he really made his famous Pismo PowerBook G3 systems work hard for it. Charles definitely was of the same mind I think a lot of our readers here are: "Even after going on a decade and a half, I still find them [his Pismos] a pleasure to use within the context of what they’re still good at." I'm sure most of us will agree the same is true for any classic computer in general and particularly Power Macs as a whole given how underwhelming Apple's current Mac offerings are. While later on he upgraded to a 17" Big Al, and although I admire the Pismo my favourite Mac laptop to this day remains the wonderfully customizable PowerBook 1400 (with a G3/466, thank you very much, and still looking for a solar cover!), I can think of few people who bore the standard of the classic Mac as a useful productivity device for as long as he did. Even old tools can still be the right tools when given the right job to do.

Go with God.

TenFourFox FPR9 available, and introducing Talospace

TenFourFox Feature Parity Release 9 final is now available (downloads, hashes, release notes). There are no changes from beta 3 except for outstanding security patches. Assuming no changes, it will go live Tuesday evening Pacific due to the US Labor Day holiday.

Allow me to also take the wraps off of Talospace, the new spin-off blog primarily oriented at the POWER9 Raptor Talos family of systems but will also be where I'll post general Power ISA and PowerPC items, refocusing this blog back to Power Macs specifically. Talospace is a combination of news bits, conjecture and original content "first person" items. For a period of time until it accumulates its own audience, I'll crosspost links here to seed original content (for the news pieces, you'll just have to read it or subscribe to the RSS feed).

As the first long-form article, read this two-part series on running Mac OS X under KVM-PPC (first part, second part). Upcoming: getting the damn Command key working "as you expect it" in Linux.

TenFourFox FPR9b3 available

TenFourFox Feature Parity Release 9 beta 3 is now available (downloads, hashes, release notes). This version has site-specific workarounds for Github's sudden hostility to TenFourFox (fixed using the same workaround we use for Imgur) and pages that use the new version of Cloudflare RocketLoader (by essentially defeating it). I also reduced idle time deferral for a couple rare crashes on the test systems that seemed to be from low memory and added a little tuneup for HTML5 parsing from Firefox 55.

Of the security patches that landed in this version is a specific one for an issue that affects 10.5, but not 10.4. It's more of an information leak than anything else and wouldn't seem to be very common, but I was able to exploit it on the test network, so now it's worked around. Our implementation is completely different from Mozilla's largely for performance reasons since we only have two operating system flavours to worry about.

Watch for the final to emerge this weekend sometime, for public release next Tuesday (not Monday because of the US Labor Day holiday).