Friday, September 22, 2017

JAEUA (Just another endangered Universal application), or, the three heads of Tutti II

On this blog, Universal doesn't mean that watered-down 32-bit/64-bit Intel nonsense. It means actually running on multiple system architectures, like 68K and PowerPC in the "fat binary" days, or PowerPC and Intel at the dawn of the OS X i386 era (as OS X has always been able to do even when Marklar was a skunkworks project thanks to NeXTSTEP).

So here's another one. I maintain an emulator of the first home computer I ever had as a kid, the Tomy Tutor, called Tutti II (the original Tutti was actually a simulator for the Commodore 64, and I wrote that too). It descends from an earlier emulator written for Windows called TutorEm which was conveniently SDL-based, so I made some endian fixes for PowerPC and ported it to OS X with some fixes and new features. Download it and play with the demo tape images on the page. It runs on any Mac that can run 10.4 or later, PowerPC or Intel. It runs just dandy on my Sierra-based i7 MacBook Air all the way down to my Tiger-based Sawtooth G4.

The point of this blog post isn't (merely) shameless self-promotion, though; there are some technical points I want to make too. Tutti II isn't just a Universal PowerPC/Intel app; it's actually a three-headed chimera. While the SDL dylib it uses is a relatively pedestrian ppc and i386 Universal library, if you run lipo on the core tutti executable itself you'll find three architectures: one for ppc750 (i.e., G3), one for ppc7400 (i.e., G4), and one for i386 (Intel 32-bit).

Why are there three versions? Because AltiVec. If you look at the source code, you'll find conditional defines for AltiVec acceleration mostly within the TMS 9918A video chip emulation which are used for bitmap splats and scales. This is part of what enables it to run well even on my 1GHz iMac G4. In fact, given that the Mach-O field for number of architectures is a 32-bit integer, you are likely to run out of file offset space (also a 32-bit integer) in a multi-architecture binary long before you run out of actual and artificial architectures to cram in it. Mac OS X looks at the binary and if your system has Intel, runs the Intel portion. If it's PowerPC and it has AltiVec, it runs the AltiVec version, and failing that, the G3 version. No runtime checking is required within the code itself. (The only reason I haven't bothered to do a ppc7450 or ppc970 version too and make it five-headed is because it runs so fast already they're not likely to yield much, if any, noticeable benefit.)

The second point is that this is made much easier because everything is 32-bit. Although Tutti II is mostly Cocoa-based internally and probably could be made to build 64-bit, Xcode 2.5 doesn't support 64-bit Intel compilation, the Universal 10.4 SDK is only 32-bit, and the specific 32-bit SDL 1.2.14 version I use occupies a narrow sweet spot where it uses CoreGraphics instead of QuickDraw for forward compatibility while still functioning on PowerPC 10.4. But, because it's 32-bit, I can build the entire app from the G5 on 10.4 with that library and everything easily descends from almost exactly the same code base. This may no longer be possible after macOS 10.14, whatever it's called (I'm hoping for "macOS Arvin"), ends the ability to run "32-bit applications without compromise." Apple doesn't say what that compromise might be, but my guess is either that the operating system will not include 32-bit components and they will be a separate download for some transitional period (like Rosetta in 10.6), or Intel Carbon applications will be entirely unsupported, as there is no 64-bit Carbon, or maybe even both. Apple may also choose to completely remove things like Intel QuickDraw at the same time, which hasn't been supported since 10.4 but does still run on current versions of macOS, and is only really meaningful for Carbon also. After these pieces are completely decommissioned, you'll have to run High Sierra or Snow Leopard in a VM, I suppose.

As I've mentioned before, this is bad for Power Macs because other than PowerPC bigots like me, what residual PowerPC application support remains is largely due to the fact it works without additional effort and it's more work to remove it than not to bother. I suspect many cross-builders have some old Power Mac or early Intel Mac in a corner with an Xcode that just happens to still build for PowerPC, and the binary it spits out still "just works" on modern Macs, so they leave it alone. Even codesigning didn't really change this much because these cross-platform builders don't like paying the Apple developer tax as much as I don't, so they don't need it (Tutti II is also not a signed application, and probably never will be). Once this is no longer possible, however, these builders will probably just remove PowerPC support entirely since it won't be compatible with newer versions of Xcode, so start preserving source code archives where you find them so you can maintain and build it yourself.

In my case, since I'm planning to move to POWER9 on Linux instead of whatever the next Mac Pro turns out to be, when 32-bit Mac apps are gone completely that will mean the end of Tutti II on current versions of macOS. There will still be a build for Power Macs, but since I'm actually looking into cross-compiling it for Windows, rather than chugging out a special 64-bit macOS build and maintaining it separately I'll just make current Mac users run the 32-bit Windows binary in WINE. That's just less work for me and satisfies my internal curmudgeon, so there.

Look for TenFourFox FPR3 final probably tomorrow or Sunday, depending on when the build cycle finishes.

Tuesday, September 12, 2017

BlueBorne and the Power Mac TL;DR: low practical risk, but assume the worst

Person of Interest, which is one of my favourite shows (Can. You. Hear. Me?) was so very ahead of its time in many respects, and awfully prescient about a lot else. One of those things was taking control of a device for spying purposes via Bluetooth, which the show variously called "forced pairing" or "bluejacking."

Because, thanks to a newly discovered constellation of flaws nicknamed BlueBorne, you can do this for real. Depending on the context and the flaw in question, which varies from operating system to operating system, you can achieve anything from information leaks and man-in-the-middle attacks to full remote code execution without the victim system having to do anything other than merely having their Bluetooth radio on. (And people wonder why I never have Bluetooth enabled on any of my devices and use a wired headset with my phone.)

What versions of OS X are likely vulnerable? The site doesn't say, but it gives us a couple clues with iOS, which shares the XNU kernel. Versions 9.3.5 and prior are all vulnerable to remote code execution, including AppleTV version 7.2.2 which is based on iOS 8.4.2; this correlates with a XNU kernel version of 15.6.0, i.e., El Capitan. Even if we consider there may be some hardening in contemporary desktop versions of macOS, 10.4 and 10.5 are indisputably too old for that, and 10.6 very likely as well. It is therefore reasonable to conclude Power Macs are vulnerable.

As a practical matter, though, an exploit that relies on remote code execution would have to put PowerPC code somewhere it could execute, i.e., the exploit would have to be specific to Power Macs. Unless your neighbour is, well, me, this is probably not a high probability in practice. A bigger risk might be system instability if an OS X exploit is developed and weaponized and tries spraying x86 code at victim systems instead. On a 10.6 system you'd be at real risk of being pwned (more on that below). On a PowerBook G4, they wouldn't be able to take your system over, but it has a good chance of getting bounced up and down and maybe something damaged in the process. This is clearly a greater risk for laptops than desktop systems, since laptops might be in more uncontrolled environments where they could be silently probed by an unobserved attacker.

The solution is obvious: don't leave Bluetooth on, and if you must use it, enable it only in controlled environments. (This would be a good time to look into a wired keyboard or a non-Bluetooth wireless mouse.) My desktop daily drivers, an iMac G4 and my trusty Quad G5, don't have built-in Bluetooth. When I need to push photos from my Pixel, I plug in a USB Bluetooth dongle and physically disconnect it when I'm done. As far as my portable Power Macs in the field, I previously used Bluetooth PAN with my iBook G4 for tethering but I think I'll be switching to WiFi for that even though it uses more power, and leave Bluetooth disabled except if I have no other options. I already use a non-Bluetooth wireless mouse that does not require drivers, so that's covered as well.

Older Intel Mac users, it goes without saying that if you're on anything prior to Sierra you should assume the worst as well. Apple may or may not offer patches for 10.10 and 10.11, but they definitely won't patch 10.9 and earlier, and you are at much greater risk of being successfully exploited than Power Mac users. Don't turn on Bluetooth unless you have to.

Very Soon Now(tm) I will be doing an update to our old post on keeping Power Macs safe online, and this advice will be part of it. Watch for that a little later.

Meanwhile, however, the actual risk to our Power Macs isn't the biggest question this discovery poses. The biggest question is, if the show got this right, what if there's really some sort of Samaritan out there too?

Sunday, September 10, 2017

Irma's silver lining: text is suddenly cool again

In Gopherspace (proxy link if your browser doesn't support it), plain text with low bandwidth was always cool and that's how we underground denizens roll. But as our thoughts and prayers go to the residents of the Caribbean and Florida peninsula being lashed by Hurricane Irma, our obey your media thought overlords newspapers and websites are suddenly realizing that when the crap hits the oscillating storm system, low-bandwidth text is still a pretty good idea.

Introducing text-only CNN. Yes, it's really from CNN. Yes, they really did it. It loads lickety-split in any browser, including TenFourFox and Classilla. And if you're hunkered down in the storm cellar and the radio's playing static and all you can get is an iffy 2G signal from some half-damaged cell tower miles away, this might be your best bet to stay current.

Not to be outdone, there's a Thin National Public Radio site too, though it only seems to have quick summaries instead of full articles.

I hope CNN keeps this running after Irma has passed because we really do need less crap overhead on the web, and in any disaster where communications are impacted, low-bandwidth solutions are the best way to communicate the most information to the most people. Meanwhile, please donate to the American Red Cross and the Salvation Army (or your relief charity of choice) to help the victims of Hurricanes Harvey and Irma today.

Tuesday, September 5, 2017

TenFourFox FPR3b1 available

TenFourFox Feature Parity Release 3 beta 1 is now available (hashes, downloads, release notes). This release has two major updates: first, a whole lot more of the browser has AltiVec in it. All of the relevant call sites that use the slower OS X memory search function memchr() were either converted to the VMX-accelerated version that we introduced for JavaScript in FPR2, or, if the code simply checks to see if a character is there but doesn't need to know where it is, our VMX-accelerated haschr(). This occurs in lots of places, including event handling, font validation and even the network stack; not all of them are hot, but all of them benefit.

The second major change is additional JavaScript ES6 and ES7 compatibility. It's not sufficient for us simply to copy over later versions of JavaScript from browser versions between 45 and 52; besides the fact they may require platform support we don't implement, they don't have our JIT, our PowerPC-specific optimizations and our later updates which would need to be backported and merged, they don't have our accumulated security patches, and they don't have some of the legacy features we need to continue to support 45-era add-ons (particularly legacy generator and array comprehensions). This hybrid engine maintains backwards compatibility but has expanded syntax that fixes some issues with Dropbox (though we still have a couple other glitches to smoke out), Amazon Music and Beta for Pnut, and probably a number of other sites. There is a limit to how much I can cram into the engine and there is a very large frontend refactor around Fx51 which will probably not be easily backported, but there should be more improvements I can squeeze in.

There was also supposed to be a new feature for delaying video decoding until the rest of the page had loaded to improve throughput on YouTube and some other sites, but YouTube introduced its new site design while I was testing the feature, and unfortunately the "lazy loading" technique they appear to be using now means the browser cannot deterministically compute when video will start competing with layout for resources. I'm thinking of a way to retool this but it will not be an enabled part of FPR3. One idea is to forge dropped frames into MSE's statistics early so it shifts to a lower quality stream for a period of time as a "fast start;" another might be to decouple the media state machine from the decoder more completely. I haven't decided how I will attack this problem yet.

In miscellaneous changes, even after desperate begging Imgur would not fix their site sniffer to stop giving us a mobile version using the default TenFourFox user agent (this never used to happen until recently, btw), even if just an image by itself were requested. I got sick of being strung along by their tech support tickets, so this version just doesn't send any user agent to any Imgur site, unless you explicitly select something other than the default. Take that, Imgur. The reason I decided to do this for Imgur specifically is because their mobile site actually causes bugs in TenFourFox due to a hard CoreGraphics limit I can't seem to get around, so serving us the mobile site inappropriately is actually detrimental as opposed to merely annoying. Other miscellaneous changes include some widget tune-ups, more removal of 10.7+ specific code, and responsiveness tweaks to the context menu and awesome bar.

Last but not least, this release has a speculative fix for long-running issue 72 where 10.5 systems could end up with a frozen top menu bar after cycling repeatedly through pop-up menus. You'll notice this does not appear in the source commits yet because I intend to back it out immediately if it doesn't fix the problem (it has a small performance impact even on 10.4 where this issue does not occur). If you are affected by this issue and the optimized build doesn't fix your problem, please report logging to the Github issue from the debug version when the issue triggers. If it does fix it, however, I will commit the patch to the public repo and it will become a part of the widget library.

Other than that, look for the final release on or about September 26. Post questions, concerns and feedback in the comments.

Friday, August 11, 2017

Time to sink the Admiral (or, why using the DMCA to block adblockers is a bad move)

One of the testing steps I have to do, but don't enjoy, is running TenFourFox "naked" (without my typical adblock add-ons) to get an assessment of how it functions drinking from the toxic firehose that is the typical modern ad network. (TL;DR: Power Macs run modern Web ads pretty poorly. But, as long as it doesn't crash.) Now to be sure, as far as I'm concerned sites gets to monetize their pages however they choose. Heck, there's ads on this blog, provided through Google AdSense, so that I can continue to not run a tip jar. The implicit social contract is that they can stick it behind a paywall or run ads beside them and it's up to me/you to decide whether we're going to put up with that and read the content. If we read it, we should pony up in either eyeballs or dinero.

This, of course, assumes that the ads we get served are reasonable and in a reasonable quantity. However, it's pretty hard to make money simply off per-click ads and networks with low CPM, so many sites run a quantity widely referred to as a "metric a$$ton" and the ads they run are not particularly selective. If those ads end up being fat or heavy or run scripts and drag the browser down, they consider that the cost of doing business. If, more sinisterly, they end up spying on or fingerprinting you, or worse, try to host malware and other malicious content, well, it's not their problem because it's not their ad (but don't block them all the same).

What the solution to this problem is not, is begging us to whitelist them because they're a good site. If you're not terribly discriminating about what ads you burden your viewers with, then how good can your site really be? The other non-solution is to offer effectively the Hobson's choice of "ads or paywall." What, the solution to the ads you don't curate is to give you my credit card number so you can be equally as careful with that?

So until this situation changes and sites get a little smarter about how they do sponsorship (let me call out a positive example: The Onion's sponsored content [slightly NSFW related article]), I don't have a moral problem with adblocking because really that's the only way to equalize the power dynamic. Block the ads on this blog if you want; I don't care. Click on them or not, your choice. In fact, for the Power Macs TenFourFox targets, I find an adblocker just about essential and my hats are off to those saints of the church who don't run one. Lots of current sites are molasses in January on barbituates without it and I can only improve this problem to a certain degree. Heck, they drag on my i7 MacBook Air. What chance does my iMac G4 have?

That's why this egregious abuse of statute is particularly pernicious: a company called Admiral, which operates an anti-adblocker, managed to use a DMCA request to Github to get the address of the site hosting their beacon image (to determine if you're blocking them or not) removed from the EasyList adblock listing. They've admitted it, too.

The legal theory, as I understand it (don't ask me to defend it), is that adblockers allow users to circumvent measures designed to "control access," which is a specific component of the American DMCA. (It is not, in fact, the case in Europe.) It might be more accurate to say that the components of adblockers that block adblocker blocking are primarily what they object to. (Uh, yo dawg.) Since the volunteer maintainers of EasyList are the weak link and the list they maintain is the one most adblockers use as a base, this single action gets them unblocked by most adblock extensions and potentially gives other ad networks a fairly big club to force compliance to boot.

The problem with this view, and it is certainly not universally shared, is that given that adblockers work by preventing certain components of the page from loading, theoretically anything that does not load the website completely as designed is therefore in violation. The famous text browser Lynx, for example, does not display images or run JavaScript, and since most ads and adblocker-blockers are implemented with images and JavaScript, it is now revealed as a sinister tool of the godless communist horde. NoScript blocks JavaScript on sites you select, and for the same reasons will cause the end of the American Republic. Intentionally unplugging your network cable at the exact moment when the site is pushing you a minified blob of JS crap -- or the more technically adept action of blackholing that address in your hosts file or on your router -- prevents the site from loading code to function in the obnoxious manner the ad network wants it to, and as a result is clearly treason. Notice that in all these examples the actual code of the site is not modified, just whether the client will process (or in the last example even just receive) and display it. Are all these examples "circumvention"?

This situation cannot stand and it's time for us independent browser maintainers to fight fire with fire. If Admiral isn't willing to back down, I'll issue the ultimatum that I will write code into TenFourFox to treat any of Admiral's web properties as malicious, and I encourage other browser maintainers to do the same. We already use Safe Browsing to block sites that try to load malicious code and we already generate warnings for sites with iffy credentials or bad certificates, so it's not a stretch to say that a site that actively attacks user choice is similarly harmful. The block will only be by default and a user that really wants to can turn it off, but the point will be made. I challenge Admiral to step up their game and start picking on people their own size if they really believe this is the best course of action.

And hey, even if this doesn't work, I should get lots of ad clicks from this, right? Right?

I'll get my coat.

Tuesday, August 8, 2017

And now for several things that are completely different: Vintage Computer Festival aftermath, I pass a POWER9 kidneystone, and isindex isdead which issad

So, you slugs who didn't drag yourselves to the Computer History Museum in Mountain View for this year's Vintage Computer Festival West, here's what you didn't see (and here's what you didn't see last year).

You didn't see me cram two dorm refrigerator-sized Apple servers and a CRT monitor into my Honda Civic,

you didn't see my Apple Network Server exhibit, complete with a Shiner HE prototype and twin PowerBook 2300 Duos and an Outbound notebook serving as clients,
you didn't see a functioning Xerox Alto,
you didn't see SDF's original AT&T 3B2,
you didn't see Bil Herd, Leonard Tramiel and other old Commodore luminaries talking about then and now,
you didn't see a replica "CADET" IBM 1620, "just as it was" in 1959 (the infamous system that used lookup tables for addition rather than a proper adder, hence the acronym's alternative expansion as "Can't Add, Doesn't Even Try"),
you didn't see a JLPGA PowerBook 170 signed by John Sculley,
you didn't see a prototype dual G4 PowerBook,
you didn't see a prototype Mac mini with an iPod dock (and an amusing FAIL sticker),
you didn't see components from the Cray-1 supercomputer,
you didn't see this 6502-based astrology system in the consignment section, of the same model used by Nancy Reagan's astrologer Joan Quigley,
and you didn't see me investigate this Gbike parked out front, possibly against company policy.
You could have, if you had come. But now it's too late. Try again next year.

But what you still have a chance to see is your very own Talos II POWER9 workstation under your desk, because preorders opened today. Now, a reminder: I don't work for Raptor, I don't get any money from Raptor, and I paid retail; I'm just a fairly intransigent PowerPC bigot who is willing to put my Visa card where my mouth is.

Currently on its way to my doorstep is a two-CPU, octocore (each core is SMT-4, so that's 32 threads) Sforza POWER9 Talos II with 32GB of DDR4 ECC RAM, an AMD Radeon Pro WX7100, a 500GB NVMe SSD and an LSI 9300 8-port internal SAS controller. The system comes standard with a case, eight SAS/SATA bays, EATX motherboard, fans for each CPU, dual 1400W redundant PSUs, USB 3.0 and 2.0, RS-232, VGA, Blu-ray optical drive, dual Gigabit Ethernet, five PCIe slots (PCIe 4.0, 3 x16 and 2 x8) and a recovery disc. It runs Linux on ppc64le, which is fully supported. The total cost shipped to my maildrop with a hex driver for the high-speed fan assemblies is $7236.

Now, some of you are hyperventilating by now and a few of you may have gone into frank sticker shock. Before you reach for the Xanax, please remember this is most assuredly not a commodity x86_64 machine; this is a different (and Power ISA successor) architecture with fully auditable firmware, the ability for you to do your own upgrades and service with off-the-shelf parts, and no binary blobs with hidden spies like the Intel Management Engine. This is a niche box for people like us who value alternative architectures, especially in a design that we can build and trust ourselves, and I always said something like this wouldn't come cheap. But let's compare and say you're in the market for a Mac Pro or something. You'll still be paying a lot, especially if you get any of the tasty BTO options, and the next Mac Pro is still months away or more. And if you were actually in the market for an AmigaOne X5000, this blows it out of the water. You could just run UAE on this and have cycles to spare!

When the Talos II arrives, I'll be sure to post some unboxing photos and take it through its paces on first boot and give you some initial impressions. My immediate goal is to get a RAID set up, get QEMU able to run a decent subset of my old Mac software (I'll probably start with OS 9, and then create a Tiger instance or clone the G5 to it), and get Firefox running with compiler settings appropriate to the CPU. Then will come the real fun of writing a JavaScript JIT for POWER9.

But don't worry: the G5 isn't going anywhere and neither is TenFourFox. I've got a lot invested in this Quad and it will still be serving workstation duty for awhile yet. Nevertheless, get your credit card and your intestinal fortitude out in the meantime and reserve a Talos of your own while the pre-order period is open. Time to get in while it's hot. This is the next evolutionary step in personal computing with PowerPC.

As we wind up our discussion of the future, however, one part of the past will soon be almost completely gone: the venerable old <isindex> HTML tag. Firefox will be removing it from 56 for technical reasons after it was already removed from Google Chrome and the Safari preview. This construct dates back to the very earliest days of the Web when early browsers didn't have form support; it was designed as an easy way of enabling the user to send search keywords or parameters to a webserver, much like Gopher servers receive queries over item type 7. Mosaic 1.x even had a little form that was a permanent part of the browser chrome with a search button, as you can see from the screenshot at the Macintosh Repository, which would be activated when the tag was seen. Later on, subsequent versions of Mosaic and most of the successor browsers turned it into a pseudo-form that functioned the same way as far as the server is concerned and some of those sites are still around. Myself I use the tag mostly as a convenience for old browsers and Lynx on the Hytelnet-HTTP gateway; the search system offers both a conventional search form and an <isindex> query, both of which work the same, and both of which can still be seen in 52ESR, 54 and the 55 beta for the time being. It goes without saying that I will not be removing it from TenFourFox, and it will eternally remain in our codebase and on my servers as a relic of the way things were and an echo of the way the early Web was.

Saturday, August 5, 2017

TenFourFox FPR2 available

As I type in what is not quite the worst hotel room in Mountain View while Rockford Files reruns play in the background, TenFourFox FPR2 final is available for testing (downloads, hashes, release notes). The original plan was not to have a Debug build with this release, but we're still trying to smoke out issue 72, so there is a Debug build as well. Again, it is not intended for general use unless you know what you're doing and why.

The only differences from this and the beta, besides the usual certificate, HPKP and HSTS updates, are some additional debug sections in the widget code for issue 72 and the remaining security and stability update backports. One of these updates fixes a bug in HTTP/2 transactions which helps reduce latency and dropped connections on some sites, notably many Google properties and some CDNs, and affects pretty much any version of Firefox since HTTP/2 support was added. As always, the plan is to go live on Monday PM Pacific.

Day 2 of the Vintage Computer Festival West is tomorrow! Be there, or, um, be not there! And that is clearly worse!