And now for something completely different: Rhapsody revisited (to go)

My favourite Mac laptop of all time remains the PowerBook 1400, the first laptop I ever owned (I don't count the Commodore SX-64, which would be more likely to damage your lap) and my faithful companion for about five years as a hand-me-down from my brother-in-law, who had recently bought a snow iBook G3 and said that if I could fix the 1400, I could keep it. It turned out to need a new inverter board and LCD, so I just bought a whole new top case for $140 and his 1400c/117 lived again. Since then it picked up an Ethernet card (Nate had already installed a modem card), a new battery, an 8-bit video out card, a full 64MB complement of memory (supplemented by RAM Doubler), a 4GB hard disk and a 333MHz G3 and later a 466MHz G3 CPU board. I eventually transplanted most of it to a new logic board when the old one got flaky, and this reincarnated version still works great where it gets lots of weird looks at the local coffee shop because I put biohazard stickers on the clear cover. The 1400 has the best keyboard of any Mac laptop ever made, the highest marks for modularity and upgradability, and who doesn't like installing a different cover to match your mood?

(By the way, the only major upgrade I'm missing for it is the hard-to-find solar cover, which I've sought for years. If you've got one and your 1400 is dying a slow moldy death in a closet, send me an E-mail. I'm willing to deal.)

Evolutionarily, though, the NuBus architecture in the 1400 made it a dead end and I jumped directly from there to an iBook G4, so I never got to try anything between 9.1 and 10.4 on the road; in fact, I didn't move to OS X until the Jaguar days when I bought the last of the MDDs so I could still boot OS 9. (Ironically, I wound up with Nate's iBook G3 too. It's in a bag waiting for a new backlight.) I never really got to play with Rhapsody back in the day, and when I found a set of Mac OS X Server v1.2 CDs on sale, I knew I had a use for another PowerBook I'd picked up along the way: a PowerBook G3 Wallstreet II, also known as the PDQ.

This one was a university castoff from up in the Bay Area, where it was ending its days acting as a sync station for a Newton that had long since found another home. It was quietly leaked to me, where I refurbished it, cleaned up the case, got it a RAM upgrade and a new battery, and then put it in the closet and forgot about it until I discovered the Wally G3 was the best portable Rhapsody workstation ever made. Consider: it's bootable (hardly guaranteed with Rhapsody), it supports 24-bit colour at 1024x768, and it supports all the standard internal devices that Rhapsody did, including the optical drive and network. Previous G3 PowerBooks (and the 2400c, 3400c and clamshell iBook) only run at 800x600, and not only does the Lombard only work at 256 colours, you have to swap optical drives to get it to install and discs to mount if you have a DVD-ROM unit. And you can forget about the Pismo or any G4 PowerBook -- it won't boot at all.

Rhapsody really is the closest thing to pure NeXTStep that ever ran on a PowerPC-based computer (NeXT never ported it to the Power Mac back in the day), but as you can see from the screen shot (besides the 2014 date which I swear is not Photoshopped; the OS apparently puts the current year in the copyright string) it does so with a not-quite-100% veneer of Platinum. I say it's not 100% because it puts a dot in the close gadget when a window is dirty, like NeXTStep and OS X both do but OS 9 never did; there is no true Finder in the Classic sense (certainly not the lovely spatial one we loved); and their Charcoal font has some peculiarities from the nice regular version in the real OS 9. But it makes the OS seem so clean and beautiful that I can almost forgive the ugly huge desktop icons.

Having a mobile Rhapsody is great from a computing archaeology perspective. I don't have to dedicate a seat to it and I can throw it on a project table if I want to work with it. I theorize that the Apple developers wanted to do their work on a laptop too and snuck partial support in so that they could, and at least with respect to Rhapsody 5.6 (v1.2), it works well enough for that purpose.

It hasn't aged completely well, though. Some older file archive sites have Rhapsody-compatible software, but there's not a lot of it. OmniWeb 3 is appallingly old by modern web standards, mostly Netscape Communicator 4-era in terms of what it supports (no CSS of any kind), and the only compiler is Apple's hacked gcc 2.7.2.1 -- which doesn't build modern Cocoa software because not all the libraries are there, and doesn't build old Carbon software because Rhapsody doesn't have Carbon! Classilla does run ... but only within the Blue Box emulation layer, which is both better and worse than Classic. It's better in that it's incredibly fast compared to the double-buffered Classic of 10.3 and 10.4, almost native speed, but worse in that it is extremely badly integrated into the OS, can only run up to 8.6, and only runs full screen (although this may be partially why screen updates are so speedy -- it doesn't have to composite any windows). While I wanted to do more with Rhapsody, I found I was spending most of my time in the Blue Box, so I ended up repartitioning the hard disk so I had a 9.2.2 partition on it as well, and the default Blue Box disk image was too small, so I ended up copying it to the 7300 and having Disk Copy make it larger. (No, you can't do this in Rhapsody itself. WTF. Though having the whole of the Blue Box environment in a disk image is very convenient for backups.)

Which leads me to some annoyances about a portable Rhapsody installation specifically. First, there's no power management. The CPU runs full speed, no throttling, no cycling. There's no battery gadget for you to monitor how much time you have left (I'm sure there must be a way to check the battery through the I/O system, but I haven't found it yet). If you close the lid, the machine doesn't sleep, because there's no sleep support of any kind: you're either fully powered up or fully powered down. That's it.

If the battery runs out, and like most PowerBooks of this age the PRAM battery doesn't hold much of a charge anymore, I found out the hard way that Rhapsody becomes unbootable (more accurately, PRAM gets whacked, and the first-stage bootloader is not a normal "Toolbox-style" Open Firmware booter, so the Mac fails to start the operating system). Fortunately, OS 9.2.2 can fix this. When I set it up to dual-boot, and the original battery was flat, it automatically started OS 9. I rebooted it once (if you don't do this, Startup Disk will hang) and went to the Startup Disk control panel, and it saw the Rhapsody partition and offered it as a choice. Whew! You can force the Rhapsody bootloader to boot something else by holding Option down as you power on the machine, by the way, and Rhapsody will see the OS 9 partition (just not vice versa except as a startup choice). It's interesting how dependent Rhapsody is upon Mac OS 9 to be fully functional, just like 10.0 and 10.1 were.

There are also some other general annoyances with Rhapsody as a daily driver besides the dearth of software. In addition to the default Blue Box image being too damn small (after you run it for the first time, copy it from /Local/Library/MacOS/Users/your user name/StartupDisk.img to your OS 9 partition and let Disk Copy enlarge it; here are some tips on that), if you leave a CD in the optical drive when the machine boots, then you have to be root to eject it. This led to a lot of cussing until I figured out what was going on, which was worsened by the weird way the OS handles volumes (/Local?) and sometimes keeps ghosts of them around. And while the detachable menus are neat, they have a habit of detaching rather easily; fortunately Apple ditched this for the OS X Public Beta.

But Rhapsody was revolutionary at the time, and I can see why. It almost promised a nearly seamless transition from the Classic age to the NeXT one, even with the same skin and basic appearance. It would be hard for me to work in it compared to OS 9, let alone Tiger, and I really need to do something about that compiler, at least, but now I've got a little Rhapsody to go when my curiosity gets piqued and I can enjoy what might have been any time I want. So here's to you, Wally. Job well done.

Retracting the statistics post

Some of my recent numbers are causing me to consider my previous estimates unreliable. I'm retracting our previous statistics post and I will put up a revised one with hopefully solid numbers in a month or two when I am satisfied everything has settled down.

We miss Power Computing

The 31 launch went off mostly without a hitch, though the interface has jarred a few people because almost all of the vestiges of the old pre-Firefox 4 interface are now gone. However, the overall improvements in 31 I think do ultimately exceed its drawbacks.

The only significant non-cosmetic issue right now is issue 283, which made trackpad and Mighty Mouse scrolling abnormally slow (scrolling with the scroll bar or with a regular USB mouse scrollwheel works fine). This was because of a workaround for Lion code that didn't take account of the right selector. If you have a PowerBook or iBook affected by this, there is a test build available for you (7450 only). This appears to fix the problem and will be officially part of 31.1.

The test build also has the patches from issue 284 which fix certain rendering errors and improve performance with extra-tall gradients and/or opaque background scrolling. These are part of Firefox 32+ but they're not going to be backported to ESR, so I went ahead and adapted them since they do affect our primarily software-based graphics stack and they will also be in 31.1. You're welcome to try it on a 7450 system if you like; I didn't bother making other test builds since the only systems supporting trackpad scrolling are the late-model PowerBooks and iBooks, all of which are 7450-series G4 CPUs.

In the propaganda department, I picked up this rare but classic poster from kootenaymac (who also has a link to TenFourFox, thanks!; saturation up since the lights washed the photo out a bit):

For those of you in the younger set, you may not remember how aggressive Power Computing was back in the day, probably the most successful and certainly the most visible of the doomed Mac clone companies. Steve Kahng was notorious for beating Apple to the fastest PowerPC chips because of his history with IBM from his Leading Edge days (remember those?), introducing the 225MHz 604e PowerTower Pro in July 1996 which was faster than any other personal computer at the time. Apple could not beat it until the 300MHz 8600/9600 in 1997, and I think that's what scared Cupertino the most; Steve Jobs bought them out and cancelled the license when he returned to Apple. Power Computing even had a laptop ready to go, and G3-based systems, none of which Apple ever let them release.

Their marketing was as controversial as their sales tactics and as impactful as their technology -- lots of paramilitary themes, handguns and of course Sluggo, all done by artist Frank Kozik and engineered by marketing "weasel" Mark Rosenfelt. The Sluggo poster bought them a famous lawsuit from the original artist when it showed up at MacWorld Expo 1996 in Boston, and PowerComputing lawyers made the floor staff take down the posters and stop handing them out. So, of course, it's my favourite of a great number of great ads, and I'm delighted to finally own one because there are very few out and about. It's hanging in my server room with space for the G5 poster they're sending me too.

I put Sluggo as an easter egg in early versions of Classilla and since then every release of TenFourFox has had a version, updated for the times. See if you can find it. (Don't spoil the surprise in the comments!)

I'm planning to see how viable 33 is next week, and I'm working on the annual statistics post in the meantime, because I have no life.

Jump the gun, not the shark

I'm feeling charitable, so Yosemitespoof is available a day early (compare the original). Merry Christmas, or something. The automatic update notifications will go out tomorrow as usual.

31.0 RC available and new langpacks

As Sparks' Whomp That Sucker plays in the background, 31.0 RC-final is now available (download, release notes). Please check for sanity; it goes live on Monday along with 24.7.0 for the unwilling remainder. It fixes the G5 crashes and makes final changes to the GC timeslice, plus a little tweak to graphic context initialization that should eliminate an unnecessary block of code.

Starting in 31, language packs are now available on SourceForge also; you can get them from the download area, organized out by version.

I'm putting the final touches on Yosemitespoof, because Apple deserves a little ribbing now and then from those they've left behind. The annual statistics post is coming up too.

24.7.0 released (so long), plus: Mozilla tries to double their pleasure with new Electrolysis gum

24.7.0 is released (downloads, release notes), the final release for TenFourFox 24. Please check it for sanity and wave it goodbye into the sunset as it will be offered only as an interim download for those who do not want to upgrade to TenFourFox 31 yet.

I'm now working on the final build for 31.0. Issue 280 is fixed in this release for G5 users, the only remaining major issue; a minor cosmetic annoyance on low end Tiger systems is issue 282 but this can be dealt with during the release cycle. It looks like generational garbage collection was too crashy, so Mozilla has reverted that and ESR31 will be (like us) exact rooting only. This is good news, because serious problems outside of GGC now have a much better chance to get fixed since both B2G and ESR31 won't use it.

Thanks to Chris T's hard work and our localizers, we have the same set of language packs for 31 that we did for 24, which is great. Also, I'm going to include a link to the Japanese translation, which is maintained outside of our framework. Although Yosemite is still technically in preview, I'm going to rip it off early (minus that freaking annoying cloud animation) like we did for Mavericks since the whole design-change thing fits in perfectly with the Australis shift. You'll enjoy the pastiche.

Chris has also proposed finally turning on pdf.js, Firefox's built-in PDF renderer, as default. We disabled this originally for performance reasons, but it looks like the JavaScript and graphic rendering improvements make it at least usable. This won't happen on 31, but it might happen on "TenFourFox.next" (33 or FPR1, depending on what I decide). If you want to try it, toggle pdfjs.disabled to false (you may need to restart depending on what add-ons you have). It won't be as fast as the built-in PDF renderer in Preview, but the convenience may be worth it. What do you think?

I'm monitoring future changes in Firefox and there is a lot of activity around resurrecting the foundered Electrolysis (E10S) project that was originally scheduled for 4.0 way back when. Electrolysis, put simply, is multi-process Firefox -- chrome, i.e., the browser interface, runs in a separate process, and content, i.e., the websites you visit, runs in (at least) another. This improves security and responsiveness dramatically, but could use substantially more memory, may be overall slower on uniprocessor Power Macs (such as all PowerPC laptops), and might not even work. Right now, E10S will crash TenFourFox because the 10.4 SDK doesn't implement the process spawning library routines -- we have to do that ourselves (issue 66) -- and if we do it, there might be a whole class of new bugs to deal with since we don't know if there are endian issues with passing information or serializing objects and there could be operating system bugs that get exposed in the implementation. It would only be a net positive if it didn't suck, though that's true of everything, I guess.

Mozilla is pushing Electrolysis as a marquee security feature for Pwn2Own 2015, which is roughly the Fx35 or Fx36 timeframe. Usually once a major architectural change becomes default, the other code path is quickly deprecated or deleted (and certainly unmaintained), and we would be at least two releases shy of the next ESR (Fx38). However, given the amount of work needed to even make it workable for Nightly users and the chaos it will cause with add-on incompatibility, I think it will be even longer before it becomes default in Nightly (and the countdown begins).

Make no mistake: I support, in broad strokes, what Mozilla is doing and it solves a whole class of bugs for them they can't solve any other way with the current single-process architecture. But it might not be a good thing for us, and it would require a lot of work with no guarantee of a payoff. If they enforce it and I can't make it work, that's a portkiller. We also need to watch what's going on with 10.6 support -- I'm still predicting it will be removed somewhere in this inter-ESR timeframe and I bet 10.7 support goes away at the same time. We're still relying on much of that old interface code and having to backport and merge all of it along with the 10.4/10.5 compatibility code we already have would be far more work than I could reasonably accomplish on the rapid-release timetable, at least as it stands right now. Watch Chrome very closely, because once Google gives Snow Leopard the axe, Mozilla will almost certainly follow suit.

Expect 31.0 final by this weekend for an on-time release next Tuesday.

Clearing up misconceptions about Rosetta Flash and some additional security notes

Our little discussion over Rosetta Flash, the exploit that should have you dragging the Flash plugin out to the dumpster and setting fire to it, has gotten picked up by several other blogs and news sites. Ordinarily this would be highly gratifying, but along the way there have been a few questions and a couple misconceptions, so let's elucidate.

Both Flashback and Rosetta Flash have something in common: they both attack the virtual machine which runs architecture-independent bytecode, in Java and Flash respectively. This is why the basic exploit works on Power Macs as well; we implement the same virtual machine so that the bytecode is machine-independent and doesn't have to be written for the actual CPU in use. In this kind of situation we're just bycatch. The exploit wasn't really targeted at us, but because we implement the same bytecode instruction set in the same way, we are vulnerable to the same problem. However, we don't get updates for Java or Flash anymore, so the exploit never gets patched.

This is the point at which the two issues diverge. Flashback exploited a weakness in the Java VM present in all versions, including PowerPC, allowing the program to escape its sandbox and do tasks it should not ordinarily be able to do. In Flashback's case, this was to download a regular binary program and execute it, allowing it to take control of the computer. If the authors of Flashback had thought of it and compiled that second binary as universal, it would have enabled them to take control of Power Macs as well. Even though the exploit is universal in the sense that it functions anywhere the vulnerable version of Java does, the payload it executed was not universal, so the attack failed -- but only for that reason. If a future attacker did build a PPC/x86 universal binary payload, they could still take advantage of the same flaw in the Java VM, and Power Macs would be able to execute the payload. Thus, Java is no longer safe to use on Power Macs running OS X.

Rosetta Flash proceeds differently. Flash applets are permitted to send cookie-bearing web requests to and from the domain that hosts it (which can contain, for example, login credentials and session information). This wouldn't help an attack much except when combined with a technology called JSONP, which is specifically designed to give scripts a way around the browser's built-in same-origin policy preventing documents and scripts on one origin from interacting with those on another. The details are pretty gnarly, but the basic notion is that JSONP facilitates an attacker controlling the output using a callback, and that output is a malicious SWF (the Flash applet format) encoded in ASCII that now can access the victim server with your credentials by combining Flash and JSONP's powers together. Now the attacker can do anything you can do, including post, read, send money ...

This attack is also, in a sense, universal, because it works on any vulnerable Flash implementation. However, it's not universal in the sense that a universal binary is universal, because it's not running a binary like Flashback does; the attack is accomplished with a single completely valid Flash applet that works on PowerPC and Intel. Furthermore, this exploit is fully weaponized: all an attacker needs to do is cut and paste the malicious SWF and put it up on a server with a crossdomain.xml allowing victim access. Since a lot of people update Flash slowly, this is a great opportunity for attackers. And we don't get updates at all!

The part that's particularly bad for us is even though the researcher who constructed Rosetta Flash also found a means for victim servers to combat it, the most productive way won't work on Flash 10.1 -- it needs 10.2. The callback can also be tainted so that the attacker can't meaningfully control it, but I consider that at best a temporary solution. Because the mitigations are inadequate and the attack will succeed against servers that do not guard against it, Flash is no longer safe to use on OS X Power Macs either.

However, people still want to use Flash on those really crappy sites that lock everything behind a Flash paywall, so people are still running Flash. Besides being a really bad idea, the fact is, it won't work forever anyhow: those sites are almost certainly the ones that will rely on DRM features in Flash that 10.1 will one day not implement. You need a better plan.

If you must run Flash, and if you do so you're making a big mistake, you really need to run it as separated from other things as possible and most importantly from the browser you use for logging into sites. If you run TenFourFox 24 or 31, as you should if you read this blog, then you are doing that already because 19+ won't run any plugins, including Flash. You could run it in another browser, but that browser itself needs to be up to date, and you should treat that browser as tainted and never use it for critical logins. Some folks have put it into a webapp with Fluid; this is not a terrible idea if you also install Tobias' Leopard WebKit so that at least a WebKit exploit won't ruin your day at the same time (if you're using 10.4, this is not an option). If you use MacTubes with Flash mode, you are essentially doing the same thing.

However, this won't protect you from the one day we get an exploit like Flashback's, and it won't protect you from future exploits. I practice what I preach. I have not used Flash since I banned it officially in TenFourFox 6 and completely in TenFourFox 19. I use MacTubes (in QuickTime mode, which has no known PowerPC exploits) and the QuickTime Enabler, and I won't use sites that demand I use a Flash-based player. If you install a user-agent switcher, you can pretend to be an iPad and many sites will give you an H.264 alternative the QTE will play.

You can also throw hardware at the problem. One very easy way is to get a Chromebook: these are cheap, they come available in ARM versions too for people like me who get hives buying x86 hardware, and ChromeOS has a built-in, constantly updated implementation of Flash. If you have Windows or OS X in a VM on your x86 Intel box, you could use that. You could even run it on a 10.6+ Intel Mac. But however you do it, you need to find an alternative. Flash isn't safe.

One other security note: Microsoft recently banned certificates impersonating major sites after the National Informatics Centre of India was compromised and used to generate malicious certs. This has been a chronic problem with SSL (previously, previously), but Firefox has never accepted the Indian NICCA root, and after this it almost certainly won't ever do so. We are therefore not vulnerable to this problem.

Finally, a shout-out to my friend Jon Schiefer, who completed his movie ALGORITHM and it had its first Hollywood screening last week. I was honoured to be consulted on the production and script; I'm surprised Jon still speaks to me after the amount of red ink I bled on early drafts. ALGORITHM will be free for streaming on July 13 only, so please visit the site on that date for more details and to see the film. Please support independent film and purchase a digital copy if you enjoyed it (DVDs and Blu-rays will hopefully be available in the very near future). This was made on a budget of $8,000 and everyone involved worked for a piece of the action. Let your support remind Hollywood that indie film drives America.