13.0 available

13.0 is now available. In addition to the new changes introduced overall, Tobias demonstrated that the browser can stand up and run with -mdynamic-no-pic, which disables position-independent code in the executable and the dylibs. For those unfamiliar with PIC, it allows libraries to move around in memory, but requires a level of indirection because instead of directly calling a routine you must call a PIC stub, which does the actual call. Since TenFourFox is the only app using its own internal libraries, and only one instance can run at a given time (except for certain unusual circumstances), this is entirely acceptable and improves the browser's smoothness a fair degree. This won't translate much into benchmark changes (most benchmarks including Peacekeeper are disproportionately swayed by our JavaScript JIT, which already generates code finalized to memory address), but the browser will feel a bit more responsive, and that's good. Because we don't know how this will behave completely yet, the change will not be backported to stable. However, even with binary extensions I have no reason to believe that this will cause any major issue; Tobias has been using such a build, and I've been running 13 with it on both my quad G5 and the Luxo G4.

A lingering bug is bug 757262, probably caused by a significant change in plugin architecture in bug 90268. Let me reiterate that plugins are still not supported, and even 10.5 is having some serious problems with plugin architecture that will probably cause our deprecated plugin support to stop working completely after 10.5 support is removed from Firefox. Nevertheless, if you are bitten by this bug (i.e., the plugin you enabled "against medical advice" fails to shut down when a tab is closed), you are encouraged to follow up in that bug. Don't report it here. Mozilla has decided not to respin since the proposed fix is speculative and no one has proven it works because the manifestation is maddeningly uneven.

This version also fixes the last of the graphical glitches with Azure (mostly issues with CTGradient), puts WebM back to single threaded (not ported to stable either), and fixes the endian problem with WOFF fonts. Smooth scrolling is disabled by default, only enabled for those who previously had it enabled; that's the only new difference between Fx13 and us. Remember, the change in how graphics are painted will affect how the browser reportedly acts, but does appear to be an overall win. We can expect the graphics stack and painting operations to change further as Mozilla tries to wring more efficiency out; most of this is likely to land in the Fx15/16 timeframe.

Some odds and ends. As a followup to our security on Power Macs post, Sophos has a list of viruses and malware listed by OS X version and architecture. Although an alarming number will work on PPC, all of those PPC-capable or Universal malware packages appear to be trojans, so you have to run them; none of the listed compatible attacks can be mounted without user assistance. The trick is to make sure you are not caused to receive them by a drive-by download, let alone execute them, and again, your browser can be a great help (or a horribly effective vector) with such software. Scriptable components like Flash and Java can be caused to download such software under false pretenses if their sandbox protections are subverted -- that is exactly the vector that Flashback used -- and it's yet another reason we need to leave those in the dust.

We are starting to deploy official localizations for German, French and Polish. There is an existing Japanese language pack, but so far they have indicated they would prefer to maintain it separately, and we have not yet heard back from our Chinese (zh-TW) translator. Chris is coordinating our l10n/i18n efforts. Please test these (they are only compatible with 10.0.x) and ensure they work to your satisfaction; I plan to roll these out with 10.0.5. Langpacks will not be offered for unstable branch to reduce load on our localizers.

WebGL nerds will want to look at bug 684882. While looking at 10.5 bugs to determine what we would need to backport in a 10.5-less future, comments 16, 37 and maybe 75 imply what needs to be fixed to enable WebGL and/or OpenGL acceleration on Leopard. I won't be doing this here on 10.4Fx because 10.4 doesn't support OpenGL 2.0 at all, so that's that, but those of you working on Leopard-specific ports including AuroraFox may wish to see if this gives you some pointers. Disabling texture minification appears to be the trick (but it has to be disabled completely) and a putative patch is in comment 16 in that bug. Obviously it will only work on those handful of cards and configurations where OpenGL 2.0 is operational, so this will only benefit a minority of Leopard users with a minority of configurations.

Finally, I am watching Mozilla's progress on Australis, the new Firefox UI. Some of the prerequisites for how the tab bar is to be drawn and designed (bug 625989 and dependencies) have me somewhat worried that there may be no good equivalents on 10.4, and a few comments imply that even 10.5 may have issues with it. It is entirely possible that Australis will land after 10.5 support in Firefox ends (we still don't know when this will be), and if it does, it is guaranteed Mozilla will use 10.6+ APIs of which some are almost certain not to have an effective or extant 10.4 equivalent. As we dropped visual parity with Firefox in 8.0, if it came to that, we would simply just not implement Australis and block installable themes that depend on it.

10.0.5 is holding for some last-minute landings; I aim to have it ready by Friday or Saturday. In the meantime, release notes and architecture builds:

• G3
• G4/7400
• G4/7450
• G5

13.0 changesets available

13.0 is now in the beta channel and I am typing this blog post in it. The new Blogger is still freaking treacle in January; I'd switch to Wordpress or something else, but Google still owes me some ad buxx and this is where people expect to find this blog, so I just turn the G5 up to Highest performance and type away.

The biggest change people will notice in Firefox 13 (and TenFourFox 13) is bug 598482. This greatly reworks how the graphics stack handles updates by almost totally eliminating the ability to have synchronous painting of the window, and instead connects everything up to the central refresh timer so that paints are batched and executed asynchronously. The result is some noticeable improvements in benchmarks because the browser is doing less unnecessary work (Peacekeeper increases to almost 660 on my quad G5), but there's occasionally a tiny lag in the UI because there is no way to trigger a synchronous paint anymore in the widget library. We notice this more because our title bar is drawn differently than Firefox's is (they use CoreUI; we use CoreGraphics to do it "by hand"); our titlebar is still drawn synchronously, so it appears first, but the rest of the window repaints at a random brief interval after when the refresh driver wakes up. Like most such title bar irregularities, using a Persona fixes it. A definitive fix is simply to rework the theme and the way we draw chrome completely, and I plan to (issue 16), but I'll talk more about that at the end. I expect graphics performance to improve further when bug 539356 lands.

13 also enables SPDY by default. Not many sites are using SPDY; as of this writing the only two big ones were Google and Twitter. SPDY improves network throughput, and it does seem to for us as well, but most of the overhead of rendering Google and Twitter isn't the network, so it's not really much different. There is no way to tell from the browser whether the site supports SPDY, btw; there are a few add-ons that will report the status if you're curious, but since functionally it doesn't differ any from SSL, I don't really see the point.

Another important user-facing feature is that tabs-refresh-on-demand is now default (so that tabs saved from previous sessions only load when you actually go to that tab instead of eighty tabs trying to squeeze out of your DSL line when you start the browser), and the new tab page. I actually don't care much for the new tab page -- it reminds me too much of Safari's, which I didn't like either -- but you can move things around and pin them, and you can also turn it off by clicking the little cube icon at the upper right.

Mozilla made two changes in 13 that I turned off. The first one is enabling smooth scroll by default: this is too slow on all but very simple sites, even on the G5; I might reconsider this after bug 702463. If you already have it enabled, of course, then it is still enabled. The second change they made was to compile everything with -ffunction-sections -fdata-sections, which is ostensibly to help trim binary fat, but caused an approximate 5% regression in just about every benchmark I test with and the small savings in code size are not worth it, so that's backed out too.

In other local changes, I landed a temporary endian fix for WOFF downloadable fonts (so Acid3 works again), and also removed our hack to make WebM decoding multi-threaded because Mozilla's testing seemed to imply it actually makes the current video pipeline slower. (This is not true of 10, so it will remain in the stable branch.)

While binaries for 13 are not yet ready, a number of you have asked for advance changesets to build your own or to play with them, and I will start making them available with this release; here you go.

I have my four eyes on two things in Mountain View. The first is, of course, IonMonkey, the new JavaScript engine. It is now to the point where the browser can allegedly stand up with it, but there are a number of tests that do not pass, and the engine is still not in mozilla-central. Reading the patches, it looks like IM will initially be paired with methodjit+TI ("JM+TI" -- the current JavaScript JIT in Firefox that we also use) in the same way that JM+TI was paired with the old tracejit (r.i.p.), so we should be able to just turn Ion off to start with and thus buy some time to get it working. Tracejit was fully functional for five entire releases (4 through 9), so we can assume we will have a similar grace period to get up to date. Unfortunately, even when IM eventually passes all the tests, benchmark results as of this writing show it's way behind Google V8 and even behind JM+TI, so it is very unlikely to be actually in the tree much before 17 or 18.

The second thing afoot is that Mozilla has started to float ending support for 10.5 again; recall that this was already circulated for the 13 timeframe, but that has obviously already come and gone as mozilla-central is currently on 15. While I still hold that Mozilla killed 10.4 and PPC support way too soon, they have supported 10.5 far longer than I thought they would, and their case is strengthened by Google planning to drop Chrome and Chromium support for 10.5 by "version" 22 -- note that Chromium hasn't been able to actually build on 10.5 for almost a year already.

The current proposal is that Mozilla would end 10.5 support for Firefox 16, but I'd prefer them to end it for 18 so that 17ESR still has 10.5 support in it and we can still use it as a dependable stable release. Since dropping 10.5 means losing a lot of legacy code we depend on (and a lot more work to merge), for 17 we would spin our current widget and theme libraries into Tiger-specific directories separate from Mozilla's code and maintain them independently. We would have to backport some changes required by the cross-platform portion of Firefox as it evolves, but it would be less work than the other way, and it also puts us in a better position for when 10.6 support ends as well because 10.7 has runtime and system requirements we will not be able to emulate. With our widget and theme thus separate from the mainline, I can finally rework how they are drawn, and I am strongly considering using brushed metal to work in better with the OS rather than the slight gradient we use now (remember that we haven't been at visual parity with Firefox since 8.0; if Australis imposed system requirements we would not be able to meet, under this scheme we could simply drop it entirely and continue to develop what we have). If Mozilla ignores us and decides to drop 10.5 in 16 anyway, I may accelerate this timetable. It's not a killer, but it may require us to fall away from them sooner.

10.0.5 and 13 binaries will probably be available in a week or two.

The security blanket blues

Briefly before the main piece, it seems that Fx 12 was not one of Mozilla's finer moments. Besides our broken web fonts, which was an endianness issue introduced by Google and picked up by Mozilla downstream, there was a rather nasty regression in JavaScript causing many scripts to run incorrectly and several other QA issues. I am hoping Mozilla fixes these in the 13 cycle, but many of the important fixes have not landed yet. It may be even later than beta 3, but that's when I plan to start the port regardless.

Also, Mozilla changed the login system for Builder.AMO, on which the QuickTime Enabler was stored, and now I can't get back in. I can recover the code, but this sucks, and we may need to rebuild against a new Add-on SDK anyway due to memory improvements landed for Fx15. So, for the time being, the QTE will remain at the same version for the lifetime of 10, and I will work on rebuilding it in the Fx15 timeframe against the new SDK.

Anyway, security. A recent piece in Computerworld gives the chilling statistic that half of all Macs will no longer be receiving security updates by this summer, assuming that Apple continues their current trend of ending security updates for version n-0.2 when version n comes out (so 10.6 ended updates for 10.4; 10.7 ended them for 10.5; 10.8 will end them for 10.6). Considering Microsoft is still supporting Windows XP, admittedly unwillingly, this seems pretty lousy behaviour.

In particular, this thinly disguised attempt at maximizing hardware sales screws those Intel Macs that can't be updated to 10.7 (or those of us that realize the utter trainwreck that is Lion and/or still need Rosetta), but in PowerPC land, even if Tim Cook grew the conscience for his userbase his predecessor never had, we can assume Apple doesn't give a flying cancerous pancreas about us. PPC is dead technology to Cupertino and that's that.

Because one of the goals for TenFourFox is security -- and security is the goal for Classilla, which if I grow an extra pair of hands might allow me to complete the security audit by the American Tricentennial -- I think it's worth a blog post to talk about exactly what security issues Power Mac users face. Both 10.4 and 10.5 are equally unsupported now and they won't ever be again (I intentionally won't talk about 10.1-10.3 here; there are very few good reasons for New World Macs not to be on at least 10.4, and beige Macs are better off in OS 9). If you are like me and believe it is not unreasonable to expect a long life out of your computer, then you'd better be prepared to do the legwork to keep it safe. Not only is a compromised computer a risk to you and your data, it can also be a source of misery for people on your network. At my normal workplace we are wrestling with a worm preying on the local Exchange server to pump out spam, and it all came from someone incautiously loading drive-by malware onto their office PC from some link they clicked. Moreover, while no PowerPC machines were known to be exploited by the recent Flashback worm, our previous analysis shows that the flaw was real; it's just that the actual payload was Intel-only, so it could not run even though it was possible to gain the privileges it would have required to be successful.

Surprisingly, the biggest improvement to our current security situation comes from, of all companies, Apple themselves. Believe it or not, One Infinite Loop is doing us a big (unintended?) solid by dropping PowerPC support like a hot potato. Xcode 4, which is the most current major version, does not support the 10.4 and 10.5 SDKs, and although it can be coerced with some difficulty into building x86 and x86_64 binaries for them, it won't build PowerPC code at all. To make a PowerPC binary, you must explicitly use Xcode 3, which won't run on 10.7 or any later version of OS X. Furthermore, to make a PowerPC binary that can run on 10.4, you must use Xcode 3 and explicitly link against the 10.4 SDK and build Universal or PPC, none of happens by default (heck, for that matter, linking against the 10.5 SDK is not by default either). Making malware that runs on a Power Mac will get harder and harder as the user base slowly dwindles, and this doesn't seem like much payoff for the typical money-grubbing phisher. I doubt Apple did this out of love and affection for us, but it is an unexpected benefit.

Most attacks nowadays won't work on Power Macs, anyway. A buffer overflow or stacksmash or other kind of specific low-level code attack requires that the malicious code written by the attacker be built in PowerPC machine language. Relatively few existed during the Power Mac's reign, almost all of them dating from pre-OS X days, and they all but disappeared after the 2006 Intel debacle transition when attackers moved to the much more familiar x86 architecture. Any attack that requires the processor to execute malicious code directly must be in PPC machine code; if it's in x86, it'll merely crash. The security elite reading this entry will immediately dismiss the rest of it as an appeal to "security by obscurity," and I entirely concur. But when the primary motivation of most attacks today is monetary, obscure just doesn't make enough dough. Laziness and the profit motive are the noblest goals. ;)

We do have to worry about cross-platform attacks, however, and there are no shortage of those. The Flashback worm was one example: by allowing Java to escalate privileges, anything could have been in that payload -- if it had been another Java-based executable, say, then the worm would have been able to run on Power Macs, and we'd be just as shot. Flash has been used as a cross-platform attack vector, as have the scripting capabilities of Adobe Acrobat Reader, and macro viruses in Word. And, of course, your Virtual PC instance is just as susceptible to a virus as the real thing if you run an unpatched version of Windows in it. Plus, a trojan written in a cross-platform language like Python, Java, Perl or whatnot will probably alarmingly run just fine on a Power Mac. These attacks are particularly dangerous because they hit us just as easily as the PCs and Intel Macs they are targetted at, even though we weren't the actual target (we're just gravy on the cake, or something).

Similarly, you need to make sure the browser you are using doesn't leak data and helps to insulate you against running insecure code. But you're using TenFourFox, so you already have an updated browser that doesn't run insecure plugins. Right? Right.

Security issues with what comes with OS X

Built-in networking: Enable the built-in firewall, and, if you can, enable stealth mode and disable UDP from System Preferences. Some applications require UDP, but see if you can work without it. Using a hardware firewall is even better. There are some potential exploits with the network-accessible components of 10.4 and 10.5, and simply preventing access to them is probably the best approach. If you intend to use Apache or some other server software with your Power Mac, probably better just to install Linux PPC and use that except if you are serving to an internal, trusted network.

QuickTime: There are PPC-based exploits for certain codecs in QuickTime, though none of these are known to be circulating now, and no specific PPC-based exploit for QT 7+. (While QT 6.0.3 in Classic is technically vulnerable, the limitations of OS 9 make the exploit difficult and it would have to be specific to both OS 9 and PowerPC.) It is possible for QuickTime playlists and certain other kinds of scriptable content to be used to load data over the network, but they can be only interacted with in limited ways, and to actually use them for executable data would require a PPC-compatible attack. An attack designed for Intel Macs wouldn't work.

Preview.app: Preview.app and the built-in image and PDF viewer libraries do have known holes, but no known PowerPC-based exploits. The built-in PDF toolkit doesn't understand JavaScript in PDF files or embedded Flash, and as a result is much safer than using the real Adobe Acrobat Reader (which you should really only use for protected documents). This TidBITS article says it all, really. Eventually TenFourFox will have the pdf.js extension when Firefox gets it, but it's slow even on supported Firefox systems, so Preview is still going to render much service for most people.

Java: Just don't. If you use TenFourFox, it is disabled by default; otherwise, disable and destroy the Java plugin if it exists. Java is no longer safe on Power Macs.

Mail.app: There are probably multiple specific ways to attack this application, mostly by blended attacks on the individual components such as the image viewer, etc. (and see below about Webkit). However, almost all of them would require PowerPC-specific code. That said, with Tenfourbird available, why take the risk?

Safari.app and system WebKit: oh gawd no. But here's something you might not have thought of: applications that use the built-in system WebKit components to view HTML are just as vulnerable to attack as Safari. This includes, notably, iCab 4 (but not 3), and many RIA-based applications. However, it does not include OmniWeb, which has its own updated WebKit, nor Tobias' leopard-webkit, of course.

Security issues with common applications

Adobe Flash: I think I've already voiced my objections to Flash. At least one cross-platform worm was created with Flash to attack local networks, and there will be others. Because it is scriptable, many malicious tasks can be executed on a Power Mac. If you use TenFourFox, it and other plugins are disabled; otherwise, disable and destroy the Flash plugin if it exists. For the doubters in the audience: I have not used Flash since TenFourFox 6 disabled plugins last year. I mean it.

Adobe Acrobat: Acrobat allows embedded Flash and JavaScript, which also makes it a scriptable cross-platform target. The only thing you should use Acrobat for is creating PDFs, and protected documents. Otherwise, make sure your PDFs open by default in Preview. Do not use the Acrobat plugin.

Microsoft Office: Office has a number of exploitable holes through macro viruses. For Word, I can think of few reasons you would want macros enabled, but this is a real problem with Excel. v.X and 98 in Classic are probably too old to be effectively pwned, but many macro attacks against 2004 will run on Power Macs, and the Open XML Converter can be attacked in some of the same ways. Fortunately, Microsoft has been kinder to us Power Mac users than Apple has, and you can get updates for all of these issues from Mactopia. Office 2008 is much less susceptible than 2004, but this is because it lacks VBA altogether (greatly limiting its utility), and it is noticeably slower than 2004 or v.X. iWork does not seem to suffer from any of these issues, nor does dear old AppleWorks, so those are safe alternatives. OpenOffice and NeoOffice also get regular updates.

Microsoft Virtual PC (and other PC emulators): This depends greatly on what you run. Remember that a virtual machine installation of Windows can be just as hosed as a real installation. Some Linuces will still run in VPC (I used to use Knoppix). Otherwise, stick to Windows XP and patch patch patch, and/or take advantage of disabling networking or enabling bridged mode.

We need to be realistic and realize our dear Power Macs are not absolutely invulnerable, but we can make them practically so. While I respect those who run Linux on their Macs, for me I need Classic compatibility and the ability to run the apps I've paid good money for over the years (part of what also keeps me from switching to Intel, besides my general bigotry against x86 ISA), and there is no substitute for 10.4 or to a lesser extent 10.5. I run my Macs behind a hardware firewall and I practice what I preach in software. If we're judicious, careful and methodical, we can be nearly as functional as anyone else on the hardware we paid good money for and faithfully maintain.

By the way, I detest the new Blogger. It's slow, and trying to send a complaint about it being slow was even freaking slower. I don't enjoy upgrades for upgrades' sake, and Google is great at this kind of self-gratifying nonsense. Let's hope they forget about Google Code so that it doesn't get "upgraded" either.