SSafari SSL SSucks

Apple apparently created a major bug in the OS X SSL stack in 10.9, a one-line error that causes certain kinds of SSL handshakes to never fail. Because of the nature of the SSL failure, you can't prove that the server possesses the certificate's private key matching the public key it advertised in the handshake. This is a severe flaw and makes man-in-the-middle SSL attacks greatly facilitated.

Apple has fixed this in iOS, but to date they have not fixed it in OS X. Fortunately, the error was newly introduced in 10.9 and earlier versions of OS X are not vulnerable -- you can prove that with this test site, appropriately named gotofail.com, which tries to trigger the bug. That said, you will notice that the error isn't actually in WebKit ... it's in the operating system security library.

I think this bears repeating, because anything that uses the operating system libraries to securely access the network could be vulnerable to other security flaws. Safari, for example, is precisely in this situation; WebKit does not implement SSL per se, and certainly not in the way that Mozilla does. Every time you update TenFourFox (and for that matter SeaMonkeyPPC), you get an updated network library, current security certificates and an up-to-date SSL implementation. Although Leopard WebKit at least fixes the problems with WebKit proper it cannot defend against a deficiency in, say, NSURL, and if one were discovered then you would be vulnerable if you use Safari or any other application accessing the network in that manner, even if you have Leopard WebKit installed. (Even OmniWeb, which embeds its own custom WebKit framework, suffers from this problem, and it is highly unlikely OmniWeb will issue future releases for 10.4.)

Because Tobias no longer has the resources to maintain WebKit for Tiger, I think this bug serves as a warning that 10.4 users should not Safari any longer for any purpose, and even for 10.5, if you depend on your Power Mac for banking or paying bills I would look at something with a more robust secure network implementation for those tasks. This failure (even though it's on 10.9) demonstrates in a painfully clear manner that the strength of your encryption in virtually all WebKit-based browsers is entirely dependent on an operating system component that on Power Macs has not been updated in almost three years.

Thanks to those of you who have reported your tests with garbage collection optimization. Turning off incremental GC does not appear to be an option; it stalls out too much after awhile, even worse than incremental GC. Increasing the time slice to 100ms does not seem to make anything worse, and pairing it with reducing browser.sessionstore.max_tabs_undo to, say, 2, does seem to allow the browser to recover memory a bit better. (There is still an issue with slow creep up to an unpredictable maximum even when the browser is idle, and it's hard to determine if the operating system or the browser is doing this or a combination of both.) These prefs make significant changes to the browser's behaviour, so as stated before they will not appear in the current stable branch. Remember to restart your browser after making changes to them.

Finally, and almost unexpectedly, SourceForge named us one of their Projects of the Week. I know some of you are frustrated with SourceForge's download system and the pages and advertising are certainly much more heavy than they were on Google Code, but they welcomed orphan projects like us, the site administration has reached out to me directly, and little kindnesses like this show they've supported us in a way Google never did. Plus, $FREE is a powerful motivator, even if it comes with drawbacks. Hopefully they can fix some of the network issues on their mirrors that some of you have experienced.

I pulled Firefox 29 from Aurora a couple days ago and I will be uploading 26 changesets when I get a chance later today, so watch for them. This includes a very preliminary, awfully buggy, only partially working implementation of IonMonkey, but you must run it in gdb7 because it has trap opcodes. One way or another, I should have an idea very quickly if Australis is going to be in any way workable.

The end of OS/2, the beginning of MIPS, and the question of ads (plus: take out the garbage and the trash)

29 has officially moved into Aurora, the first version of what (we assume) will become the Australis Firefox. There are several bugs still pending related to OS X, and once those are fixed on Aurora, then we will try porting and God help us. For now I am taking a break from JavaScript work to do other things, such as my memorial to the old floodgap.com server, the Apple Network Server 500 and 700.

For 24.3.0 we made an apparently minor change to the user agent string by moving the TenFourFox token into middle position to stop Chase banking services from complaining users weren't using a supported browser. That worked, and instead broke Yahoo! Mail. So no more user agent changes and this one will be backed out for 24.4.0. Users who are bitten by this can use any of the user agent changer add-ons for now. The TenFourFox token must appear because we use it for detection purposes internally, and also because, believe it or not, some sites actually check for us and serve appropriate non-plugin content. Eventually when we drop source parity there will be a user agent pane in Preferences like Classilla has, but I'd rather users used an existing add-on while we still mirror ESR24.

For some time an annoyance has been that TenFourFox gets slower with prolonged use. Prolonged use means days to weeks, of course, but for those of us who never have crashes, the browser may only be restarted when there is an update to install. The reason for this is garbage collection: as more tabs are loaded and more pages are in use -- and recall that tabs keep a certain amount of in-memory cache for fast backup and forward -- the browser must visit these objects and determine if they are still referenced by something, and keep or dispose of them appropriately. This isn't a memory leak; it's just more stuff hanging around so that it can be referenced at will. We just need to manage it better.

Prior to Firefox 16/TenFourFox 17, garbage collection was an all-or-nothing phenomenon. It would occur (with a noticeable stall) and then keep going. In 16/17, Mozilla changed garbage collection to be incremental: the browser would divide garbage collection into time slices (default, 10ms) and execute those. If you can be reasonably certain enough work can occur in that timeslice so that the browser stays ahead of the problem, then this is fine, and makes the browser appear to garbage collect instantaneously on a modern system. Well, we're not modern systems, and arguably the 10ms time slice wasn't doing any significant garbage collection even on the G5, meaning it all slowly stacked up and the browser just scheduled garbage collection slices, over and over, forever.

For 24, I increased this time slice to 30ms. That helped by getting more done per slice, but eventually garbage still builds up and the browser gets into that vicious cycle again. There are two ways around this: make the time slice redonkulous, like 100ms, or turn off incremental garbage collection altogether and go back to the old periodic stop-the-world GC that would at least enable the browser to catch up even if now and then it will seize. Right now I'm testing option 2, and that's not doing too bad so far; my worry with option 1 is that if that cycle of GC after GC crops up again, then the slices it schedules are really long, and the browser gets starved for time to service user requests.

If you want to try this, you can, but if you screw this up you will significantly impact browser performance. Don't do this if you're not prepared for the consequences. For option 1, increase the value of javascript.options.mem.gc_incremental_slice_ms. For option 2, turn javascript.options.mem.gc_incremental off. Option 2, of course, overrides anything you have for option 1. Restart the browser to start from a clean slate. The browser will appear faster, of course, when you do; the real test is how it performs after a few days. If you don't know what these settings are or where you find them, you should not do this! I might consider adding this to the next unstable build based on people's opinions, but this is too risky a change for 24.

For those of you who are more risk-averse, remember that TenFourFox by default restores your tabs when the browser restarts, so if you restart the browser, all the tabs get unloaded and there are many fewer objects for the garbage collector to check (but they load when you access them). So, you can get the speed back with a quick restart add-on, and there is such an add-on available that adds a "Restart" hot key (Option-Command-R, or go to File and Restart), which amusingly doesn't require you to restart the browser to install. If this works well for folks, we'll make it an official recommendation. You can get Restartless Restart from Mozilla Add-ons.

In other news, Mozilla has officially removed all OS/2 code from the Firefox tree, finally ending that platform's support even as Tier-3. There have been problems with OS/2 support as far back as Firefox 3.6 and OS/2 support never officially made the jump to ESR17 even though there is a porting effort that did release a few beta builds. This doesn't mean there won't be another OS/2 Firefox, but it does mean that, like us, they'll have to take and port forward a lot of the pre-existing code, and it will require significantly more work for them because OS/2 is so unlike anything else. We ourselves remain a Tier-3 platform, but even if Mozilla took all the PowerPC OS X code out we would simply add it back in (and say mean things about them in this blog and make empty threats towards their pets and families), so this is more of a sad footnote than an actual change in service level.

So that's sad, but the hopeful part is that there is someone working on a MIPS port of IonMonkey and, surprisingly, asm.js/OdinMonkey. This is for mobile devices running MIPS, of course, so it's little-endian MIPS, but it is already making significant progress and we might be able to pattern our PowerPC port of IonMonkey off it. (I remain unconvinced of the utility of asm.js on big-endian platforms, given that all the extant asm.js code is little-endian and particularly the voluminous crapola code generated by Emscripten. We could make it byte-swap, maybe, but that would require two somewhat separate code generators and be a fabulous pain in the ass to manage.) I intend to watch their progress closely.

Finally, today's web hissy fit is about the possibility Mozilla may allow sponsored content on the new tab page. Sponsored tiles would be marked. That's about all we know; we don't know if third-party builds like us can (or will be forced to) also take part, we don't know what information the browser would collect, and we don't know how configurable it is (like whether it will always take up a certain number of tiles, or gradually disappear as the browser accumulates history, or how you can change that). The move does make some financial sense; Mozilla is too dependent on Google for income, and it needs to diversify its revenue stream to stay afloat. Furthermore, as a practical matter I'm not going to dismiss the idea immediately out of hand, because maintaining Floodgap is expensive and TenFourFox consumes a lot of my time, and while I have assiduously refused actual donations I obviously do accept ad revenue from this blog. If we got a cut, users could turn it off, and the information it collected was not personally offensive or overly intrusive, I would consider it. If we don't get a cut, I find it to be insufficiently configurable, or I conclude it collects an unacceptable amount of personal data, we would disable it at the code level. The whole idea is very embryonic. Either way you'll hear about it here.

24.3.0 available

24.3.0 is now available from SourceForge (release notes). This version has some minor fixes, including to the user agent for certain sites that would misdetect TenFourFox as not-Firefox; if you're looking for a TenFourFox-specific string, it has now moved to the middle position. It will go live tomorrow night assuming no major issues.

IonMonkey PowerPC is still stuck on function calls; I can get simple ones to work now, but major portions of the test suite still crash when it must bail out to PPCBC. Eventually it will work, but it's slow going. Once 29 moves to aurora (the first official Australis release), I will issue a 26 snapshot for the interested and then we will see if we'll drop source parity or not. The new MTE concept apparently is not well received, so I guess I'll scrap that idea.

Ten years of the Twentieth Anniversary Macintosh ... or something (plus: try MTE v2)

The Twentieth Anniversary Macintosh still doesn't know what to make of this:

On the other hand, I have a 1984-2004 poster on my machine room wall.

And yes, today is indeed the 30th anniversary of the original Macintosh Super Bowl big game ad, for those of you hiding out under a rock for the last several decades. Apple did a retrospective video for apple.com, which because they used a weird manner to do it, is not compatible with the QTE. However, here are the low bandwidth and high bandwidth versions (QTE users can right click and select "Open Link in QuickTime" to play the movie). While much of it is the usual Apple equals sex design twaddle, the following classic and vintage Macs are featured, in order of appearance: the original 128K (of course), the Macintosh XL (presumably standing in for the Lisa), the Macintosh II, the Macintosh Portable, the Macintosh LC, the PowerBook 100, a Quadra 9x0 (either a 900 or a 950, amusingly lacking the key), a Color Classic, a Power Macintosh 8500 or 9500, a Macintosh SE/30 (called SE 301, with an FWB hard drive icon), a Twentieth Anniversary Macintosh (mine is better), a tower beige Power Macintosh G3, a Bondi Blue iMac G3 (the machine that arguably saved Apple), a graphite Power Mac G4 (either a Yikes! or a Sawtooth), a Blueberry iBook G3, a Titanium PowerBook G4, a 15" iMac G4, a 14" iBook G4, and finally the Power Mac G5. After that is all the Intel rot. But it's fun to see the creative luminaries assembled for this well-produced short, and of course the return (however briefly) of the rainbow Apple logo we all loved back when:

For the record, I own about 2/3rds of the featured pre-Intel Macs; the first Mac I used was my friend's dad's Mac Plus, and the first Mac I personally owned was a IIsi. And, btw, as a physician the scene of an iPad over a sterile surgical field near the end makes me shudder.

The real anniversary for us is March 14, 2014, the 20th anniversary of the Power Mac 6100 and the first Power Mac (along with the 7100 and 8100). I remember the new Power Mac well when I was in college. We'll do a special retrospective then.

No one has indicated serious intestinal distress over the highly automated way I've taken the new MacTubes Enabler, so you can download a prototype and try it. Here's an appropriate one: the Apple 1984 Super Bowl big game ad. As a bug I've subsumed as a feature (I think this is a glitch in the Add-on SDK), if you search for a video in YouTube and go to it from there, the video plays in the browser, so you can still interact with the (puke) comments and (gag) other users. But if you click on a YouTube URL anywhere else, or you cut and paste a YouTube URL into the address bar, it automatically opens in MacTubes and goes back to what you were doing. If the URL opens in a new tab, the tab automatically closes. Try it. I like it.

24.3.0 should come out this week or weekend.

IBM, MacTubes, monkeys and morons (plus: Quake is better in OS 9)

UPDATE: IBM sold the entire x86 server line to Lenovo after all, for a billion less than Google paid for the Nest.

About eight months ago, your faithful chronicler reported IBM, developers of the POWER architecture from which PowerPC descended, was trying to exit the x86 server business and sell it to Lenovo. As I mentioned in that article, margins are thinning on x86 servers, especially as companies like Google and Facebook build their own bespoke devices (Google has even looked at designing its own POWER and ARM processors), and IBM has never liked being in low-margin markets just as Apple doesn't. Well, looks like that foundered and IBM is shopping the business to Dell. Either way, IBM really wants out and I think you'll see the bottom fall out of the commodity x86 rackmount market, leaving the low-margin no-name companies to struggle for that money while the big corporations like Oracle and IBM continue to produce their proprietary RISC lines. (That must alarm Hewlett-Packard, which is stuck on Itanium with its clouded roadmap having jettisoned PA-RISC long ago. I have a fondness for PA-RISC since my first job out of college was working on a HP 9000 K-Class.) As I mentioned in the previous article, it's good news for POWER in general, since this makes it a bigger proportion of IBM's product portfolio and ensures its continued evolution even if it is gradually disappearing from the mass consumer market.

I've been playing with the next release of the MacTubes Enabler, which a number of you are already using. Since YouTube pages are only getting heavier and our computers aren't getting any faster, my current idea is to completely avoid making the browser do the work of loading the page so that you can labouriously click through the context menu to start MacTubes -- it should just hand the URL right off and halt the load so you can go back to what you're doing. And that's what it does: when a YouTube video URL is detected, it automatically fires up MacTubes and then either backs up to the previous page or closes the tab if it was a new tab like a program passing your browser a URL. In fact, if you visit any YouTube video page, the switchover occurs automatically, though things like the YouTube search are still within the browser (I figure you're doing that on purpose if you're not using MacTubes for the actual search portion). Embedded videos can be played if they properly include the embed code that has a link to the video -- you click the link and MacTubes starts, easy as that. You can still play an embedded video in WebM directly in the browser. If you use the QuickTime Player mode in MacTubes, you should be able to get HD videos and download them directly from the client.

So far this approach seems to be working well and it's nice that it's totally automatic. Please note that I haven't tested this with any tab-management addons, but this is using Mozilla's Add-on SDK for tab control, so it's not doing anything it shouldn't be. If anyone has objections, voice them in the comments; if people like how the idea sounds, I'll release that as the next version of the MTE in a couple of weeks.

IonMonkey PowerPC has progressed to the point where it can now compile and run loops in JavaScript, which particularly for floating point operations execute dramatically faster than the current PPCBC compiler (as expected). Memory usage is higher, but that is expected too; although function calls are still problematic, I have some ideas about how to fix this. I'm hoping to have a beta for IonMonkey for either 29-aurora or 31-aurora. If we make it to Fx31, I want IonMonkey to be ready by then as a marquee feature.

In other news, the morons at Google Code has shut down new downloads as threatened. Please extend your middle fingers in salute to this policy. All further uploads, including localization packs, will be on SourceForge; historical downloads will remain on Google Code "while they last." The transition to SourceForge is complete for file hosting, and we'll see what happens with the rest of it.

Finally, for you classic Mac OS gamers, I had some friends over for a good-old-fashioned LAN party so we could kill each other in Quake. We chose the original Quake because it has little network demand (particularly on modern networks), the same protocol works on Mac OS 9 and I have many OS 9 machines (this was a problem with Quake III Arena, where ioquake3 and the official id software Mac OS 9 compatible version use different network protocols), and you can get it hardware-accelerated with GLQuake for both OS X and OS 9. Our initial idea was to have the G5 be the Quake server, but GLQuake X crashed randomly and repeatedly during game play, greatly preventing me from firing rockets into my beloved friends' visceral cavities. So, just to see what would happen, I assigned server duties to the Power Mac 7300 running OS 9.1 (with 1GB RAM, a G4/800 Sonnet upgrade card and an ATI Rage Orion 3D accelerator). It never crashed for the hours of game play after that. Maybe GLQuake X is glitchy on 10.4, maybe it was some process on the G5, but if you want a solid Quake (or probably even Quake II) server, a reasonably-specced OS 9 machine did the trick for us. Go Classic go!

My New Year's Resolution is to fix IonMonkey ...

... and ask Scarlett Johansson out on a date. Fortunately, I have made progress on the more realistic goal of the two:

Starting program: /Volumes/BruceDeuce/src/mozilla-26.0/obj-ff-dbg/dist/bin/js --ion-eager -e var\ i=0
Reading symbols for shared libraries ... done

Program exited normally.

Like our initial victory with PPCBC, this is the simplest of simple JavaScripts. But it proves the basic machinery for IonMonkey optimized JavaScript compilation is now, finally, working. A very ugly hack was required that should stick for the time being. Meanwhile, we will move on to more complicated scripts and fill in the holes in the code generator that I know are not correct.

Of course, the moving target that is the JavaScript JIT compiler in Firefox is moving again. Mozilla is unhappy with the slow, nay, nonexistent pace of progress on YARR, the regular expression library used in Firefox/TenFourFox imported from WebKit. At least one suggestion that has legs is to switch to V8 irregexp, the regular expression library used in V8 imported from Google Chrome. irregexp is pretty fast, but it means yet another macroassembler to write, and more importantly it means the Nitro macroassembler we use now for both YARR and (underlyingly) PPCBC would be removed and we'd have to actually write two new backends just to restore the level of JIT function we have now. Understandably I am less than thrilled with this possibility even though the work would not be excessively difficult; it would just be tedious and delay my porting activities further. I'm hoping Mozilla develops their own regex and bases it on the existing infrastructure so I'd only have to port our underlying code generation once when they get rid of Nitro. Fortunately this is not likely to be consummated in any meaningful way much before Firefox 31.

Don't even get me started on asm.js, by the way. That's waaaay down on the priority list.

24.3.0 is scheduled for 4 February, at which time the assault on 29 and Australis will begin. By the way, does anyone have Scarlett's phone number? Asking for a friend.

26.0, trouble in paradise

So over Christmas weekend I managed to get a debug build of TenFourFox 26 up and running. It basically works, though I figured it would (29, the first Australis release, is what worries me more). So that's the good news.

The bad news is that there are three major problems, one of which is worked around only incompletely, all of them having to do with the graphics stack. Recall that starting with Firefox 12, Mozilla introduced a scheme called Azure to reduce the overhead of graphics drawing by mapping graphics calls more directly into operating system primitives rather than running them through Cairo, the abstracted graphics system Firefox has used for almost everything since 3.0. We support Azure for HTML5 <canvas> elements, and in that employ it works very well, improving overall canvas performance for most shapes by about 60 percent.

Where our implementation falls flat is text and gradients; we need lots of hacks for 10.4 to make this work, and the overhead for these specific elements is significantly greater. (Text filled with gradients is even worse.) Unfortunately, a browser's primary job is to render lots and lots of text, and Mozilla now wants to use Azure to do the rendering for everything (relegating Cairo to a backup engine, and for printing). I have to disable "content Azure" in 26, or the browser renders things about three times slower overall in the debug build (and in an opt build we'd lose AltiVec-accelerated compositing through pixman too). I think we can get away with this for awhile since Cairo is still an integral part of the layout stack for now, but if Mozilla finds another printing solution then Cairo becomes expendable. I'm going to try to do more research to figure out if we can speed this up, but remember that the vast majority of supported Macs running Firefox have hardware acceleration and we don't. It's entirely possible that the combination of 10.4 graphics thunks and their hardware-tuned rendering strategy is just too much for Macs limited to software rendering like us.

On top of that, our current Azure implementation exposes bugs in 10.4 CoreGraphics that, although not obviously severe, generate invalid context errors and other such annoyances that suggest we're just wallpapering over more significant problems. I haven't figured out where these errors come from yet (I suspect DrawTargetCG::FillRect), and because of their frequency I can't enable content Azure in TenFourFox until I'm forced to.

The third problem is the most serious, and the one I don't know how to fix definitively. One of 10.6's new system features is blocks, a construct for creating closures in C, C++ and Objective-C that allows applications to better exploit Grand Central Dispatch: you can generate little snippets of code, wrap them up as a block, and pass them around in such a way that they can remember their original state when finally run and even execute in parallel. Blocks require both runtime support from the operating system to handle and execute them, and compiler support to understand the new syntax and generate the closure code. Apple implemented this in Xcode using their fork of gcc, but blocks are really a better first-class citizen in clang, and regular gcc doesn't support them.

Blocks can be added to 10.5 using PLBlocks, which offers a modified gcc (presumably using Apple's patches) and a userland framework for runtime support. Tobias himself already uses this package for Leopard WebKit, so we have good evidence it should work fine for this purpose. Although this framework does not exist for 10.4, it looks like it doesn't require any 10.5 Objective-C features to function, so it could probably be ported. That's not the real problem. The real problem is the compiler: we don't use gcc 4.0.1 or 4.2 anymore, and Apple never ported blocks to a later version (we use 4.6), so we'd have to roll this support ourselves off Apple's patches. Even assuming it works (which is a big if), I really don't want to be maintaining a compiler and an entire tool chain on top of a browser, linker and debugger, especially since it's likely we'll have to force another compiler change in the not-too-distant future (fortunately MacPorts already offers 4.8 and it works fine on 10.4). David Fang is still industriously working away on a PowerPC OS X clang, but I don't know how far along he is with it or if its codegen for blocks will work with the PLBlocks runtime, which we'll still need.

Fortunately, Mozilla uses blocks in a very limited way and only within the OS X widget library as callbacks for graphics calls, since no other compiler other than Apple's supports them. For the time being, these callbacks (which so far appear to only apply when hardware acceleration is active) can be partially emulated by spinning the closure out as a static function that can be passed as a function pointer. I say partially, because what this doesn't emulate is the, you know, closure part: being static functions they don't have access to class member properties, and even if they did (or we figure out some Rube Goldbergian bridge class) they have no memory of their value at creation, so it's possible for them to have the wrong value when the callback is triggered. I hacked around this and the app seems to be fine, but that's no guarantee it will continue to be. As Mozilla tries to optimize Firefox more for multi-core systems and Off-Main Thread Compositing looms on the horizon, the use of blocks in Mac-specific code is likely to increase because it's what Apple wants developers to do and it's relatively straightforward for developers to use, but it's going to be a big problem for us if that code is an essential part of the application.

26 will be issued as changesets only and maybe a debug build. The first unstable release will either be 29-aurora, if Australis works, or a new 24 branch if it doesn't. Cross your fingers.