Tuesday, September 27, 2011

7.0 was converted to final this morning and I'm pulling down 8 beta 1 for initial conversion as we speak. This will require more work than 7 because Mozilla committed a number of 10.5/10.6-specific widget changes which will need to be rewritten for 10.4, but I'm pretty confident this is possible. You'll be the first to know.

A number of people have privately asked me whether TenFourFox is susceptible to the BEAST SSL attack revealed over the weekend. This rather startling hack was able to decrypt a Paypal cookie sent over SSL, allowing the attacker to assume the identity of the logged-in user. It should come as no surprise that 1) the Mozilla security team has been discussing this (along with representatives from Google, which uses the Netscape-originated Network Security Services library also) for several months, and 2) as shipped, TenFourFox is not vulnerable. Notice that I said "as shipped." The exploit demonstrated by Rizzo and Duong used a Java applet to do the server thrashing needed to get the key out, and TenFourFox disables all plugins including the Java Embedding Plugin, so the applet cannot run. It may be possible to do something similar in Flash (though such code has not yet? surfaced), but obviously this doesn't ship enabled in TenFourFox either, and the version of WebSockets in Firefox 7 and TenFourFox 7 cannot be used to trigger this exploit.

Even with plugins, Java and/or other suitable footholds available, the SSL flaw in question is not trivial to exploit: not impossibly hard nor prohibitively expensive, but neither is it simple, quick or easy. An attacker must have control of the network the victim is using (such as a compromised or open wireless link), and must be fast enough to spy on the connection and manipulate the victim's browser to try combinations on the server the victim is accessing before the session terminates. Under the optimal conditions of the demonstration the "victim" was pwned in about two minutes; real world assaults will undoubtedly require significantly more time. It is also possible for servers to immunize themselves against the attack by negotiating ciphers that are not vulnerable to the flaw Rizzo and Duong are taking advantage of; RC4/ARC4 is one such cipher and Google is using it already on its services.

The best solution is to leave TLS 1.0 behind, but for a variety of reasons this has yet to happen, and perhaps this will be the impetus to change to a safer, later TLS version. Once a final fix is decided upon for NSS, there may or may not be a 7 chemspill; we'll follow Mozilla's lead here. A similar fix will be included in Classilla, which is technically vulnerable but hard to exploit because OS 9's MRJ is mercifully too old and Flash 7 does not support sockets of the type required.

Friday, September 23, 2011

Well, heck, let's start with the good news first. AT&T installed the T1 on Monday and DSL Extreme activated it earlier today, so Floodgap and its associated projects, including TenFourFox.com, is back online. Point your friends, enemies, rather less good enemies of theirs and friends of those people's less good enemies to it.

The T1 comes at (naturally) a substantially greater hosting cost; though it is amortized against using it for my other projects and as my regular means of Net access, it's still a pricey (but very smooth and low-latency) way of getting hosts online compared to DSL or cable, neither of which were practical options for reasons many of you already know. As a policy matter I do not accept project donations as this has the risk of encouraging expectations I and the other contributors can't satisfy, but I am considering allowing Blogger to put ads on this blog to make a little of the money back. I won't object if you Adblock them away, of course.

Mozilla has signed off on the 7 release candidate, so now we have our release candidate available ahead of Firefox 7's formal launch on September 27th. As with previous release candidates, if there are no showstoppers then this will become the formal release. There is one small fix in this version (in addition to Mozilla's fixes): because Floodgap was down there was nothing to post update snippets against, so this fix adds the 7-specific update checks. As a result, there is also a new set of changesets for builders. Read the release notes and grab for your architecture:

Also available, as promised in the previous blog entry, is a new version of the TenFourFox QuickTime Enabler. If you are new to the QTE, please see this blog entry for basic instructions; in short, the QTE allows you to play certain media types outside of the browser in QuickTime, including H.264 video (which Firefox can't play at all) and most other audio and video files by right-clicking and selecting Open Media in QuickTime. In alpha-45, here's what's new:

Updated for Gecko 7 (alpha-43 will not work with 7.0)

Overly long URLs don't cause garbage characters in the URL dialogue anymore; they will simply be truncated (but will still play)

If you are not offered the QuickTime option initially, start to play the video. When the video appears and starts, right click again and see if the option is offered then. If it is, and you open the file in QuickTime, the enabler will now automatically stop the video in the browser (if possible) so that you aren't playing it in two places. This should enable JavaScript-based video code that tries to detect browser capabilities to also be playable in the Enabler.

Download QTE alpha-45 and drop it on your browser window to enable it. It does not require a restart. Remember, this add-on is still in testing and development.

"One more thing." Many of you will have read the press coverage about the "BEAST" SSL chosen plaintext attack demonstrated at ekoparty this weekend. Virtually every browser is vulnerable to this; Opera has already released a patch and Chrome has one in testing. Note that Mozilla and Chrome share SSL code (i.e., they both use NSS), so the same fix is likely to appear in Firefox, but it is not currently in 7. There is substantial argument about how easy it is to pull off in practice, but certain things can make it easier, and we might talk about this once Mozilla goes public with a final determination.

Sunday, September 4, 2011

So, it's Labor Day weekend and I've spent it watching Law and Order DVDs, painting the house trim and tweaking TenFourFox. Today, for those of you with nothing better to do on a holiday weekend either, 7.0 beta 1 is available, roughly corresponding to Firefox 7 beta 4. Generally I am loathe to talk about subjective speed improvements in this blog because they are just that, subjective. However, there is a lot to like about Fx7, and the biggest one isn't the memory footprint improvements (because we're forced to take a hit on that, read on). Instead, it's the graphics stack, and the new Cairo really benefits our rendering pipelines. Pages paint quicker, animations are snappier and movie playback is less jerky. The improvement is subtle, and there is still much improvement to come, but I think virtually everyone will notice the difference. Tobias, the early trailblazer on 7, said it was the first version he felt was truly useable on his PowerBook. While I politely demur that I've been perfectly happy with TenFourFox on my iBook G4 ;) , I certainly do agree that 7 is better in nearly every metric.

Also new in 7 is the beginnings of a new HTML5 canvas backend (Azure, which will eventually take over the entire rendering pipeline; fortunately for us, the CoreGraphics version is likely to work and even if it doesn't there's still Cairo), improvements to Sync, a new Telemetry module for reporting performance back to Mozilla (we don't track this information ourselves, but if you want to remind Mozilla that PowerPC lives, go for it :), a new API for sites to determine load times and adjust themselves to slower systems, and CSS3 ellipsis support.

Oh, and it takes http:// out of the menu bar. Strangely, I'm not as offended by this as I thought I would be, but I'm not wild about it. gopher:// does still appear, though, and so does https://, so I guess that's all that matters. :D

So, yeah, about that "memory footprint" thing. Firefox 7 is being touted as the first product of Mozilla's MemShrink project, bragging numbers that reduce its overall memory usage by 20-50%, will leak considerably less, and will more aggressively release memory as tabs are closed. Naturally such must be taken with a grain of salt, but I will say that memory usage is noticibly less on both my G5 and my iBook. In typical usage on the iBook, comparing 6 versus 7, 7 seems to use about 25% less memory, and the system is able to reclaim it more easily.

Our problem, however, is it appears we are dramatically underestimating the PowerPC's JavaScript stack demands. Longtime TenFourFox veterans will recall several bugs that in succeeding order jack up the stack ceiling more and more, and in this version we jump from 64MB of stack to 256MB of stack (repairing issue 85). This is unfortunately unavoidable because the PowerPC ABI requires us to save registers to the stack on function calls and the PPC has a massive number of registers. As OS X has a hard cap limit we must ask for this cap in advance, and the original limits we asked for were too small because our stack frames are so much larger, causing it to crash out on certain scripts. This means in the worst case the browser may require a minimum of 256MB of RAM just for the stack, let alone the app or the rest of the OS. For this reason, starting with 7.0, the minimum system requirements will be for 512MB of physical memory. Systems with 256MB of RAM will no longer be supported. Every Power Mac we support in TenFourFox is capable of at least that much; even my Outrigger beige Power Mac 7300 has a gig, and my blueberry iBook G3 has 576MB. The recommended minimum will now move to 768MB. Fortunately, thanks to the other improvements, you'll be able to do more with the rest of your memory, and the 256MB is only a peak possibility, not a persistent requirement. So do yourself and your Mac a favour (RAM is dirt cheap these days) and max out your memory now.

A few of you will be wondering about that cryptic title, and that's the other thing that we need to mention: YARR sucks. Mozilla is expanding their JIT to JavaScript regular expressions using WebKit's YARR library. YARR originally used the Perl-Compatible Regular Expression library (or at least their heavily hacked version of it) as the interpreter fallback for when a JIT was not available, and since we don't (yet) have support for methodjit or the Nitro assembler on PowerPC, we used PCRE for regexp evaluation. In 7.0 Mozilla "upgraded" YARR to a version that now uses its own interpreter as the fallback instead of PCRE. All of their shipping platforms use the JIT, which to be sure, is very quick.

We knew about this going in and several of Tobias' patches were to fix the JavaScript core to deal with the situation where the YARR JIT was not enabled. When I got this together and ran it through Dromaeo for conformance testing, however, I was shocked to see the G5 drop from 110+ runs/sec (in 6) to a dismal 65. All of this regression was paid on the regular expression part of the benchmark. When I hacked PCRE back into the JSRegExp portion of the library, the number went back to the old figure. While WebKit admits benignly that YARR's interpreter is "slower" than PCRE, frankly we really take it in the shorts with YARR and so will any other tier-3 platform that doesn't yet have methodjit/macro assembler support. I filed this with Mozilla as bug 684559 so they can ignore it, but we are shipping with PCRE back because we can't afford a hit like that. Eventually we will have methodjit and we can play in the full JIT party too, but that won't be for a couple cycles yet.

Specific to us, because of my continuing downtime (AT&T is coming out to look at installing a second NID this week for my T1), there has not been any new TenFourFox-specific features in 7 other than updating Sluggo for the new Apple CEO. However, as mentioned, issue 85 is repaired, and a 10.5 specific bug with dropdowns (issue 72) has a putative fix. This fix is limited to 10.5; if you are one of those affected by that bug, please let me know if triggering dropdowns actually crashes the browser instead, because this would imply that my theory is incorrect (i.e., that issue 9 should only be worked around on 10.4). 10.4 is not affected by this issue. This version does not fix issue 84, the table spacing issue; although we have test cases, we haven't narrowed it down to the exact Mozilla patch that provoked the issue and I don't want to wreck my one working 6 repo until I don't need it anymore since none of my ad-hoc offline repos have history. As this bug is a simple nuisance, occurs only on certain sites and the sites in question are otherwise useable, we're shipping with this bug for now.

Soon we will need to turn our efforts to methodjit so that we can keep pace with Mozilla's improvements to JavaScript. If you know PowerPC assembly language and want to help, we can always use more coders.

I'm also working on a new release of the TenFourFox QuickTime Enabler. Watch for it in the coming week or two.

In news from the Mountain View mothership, Mozilla is planning a chemspill for their chemspill, viz., a Firefox 6.0.2. This version "fixes the fix" for DigiNotar, which seems to have caused some collateral damage, but their fix-fix is similarly controversial. I am not planning to generate a 6.0.2 as 6.0.1 will fail safe and I'm not convinced there won't be more changes in the pipeline before 7 emerges. If you are affected by the changes in 6.0.1, you could always use this beta, of course. :) However, if there is a large demand for it, I will consider releasing it as well.

For now, read the 7.0 beta release notes, and grab for your architecture: