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.

It's time to stop using Flash on Power Macs. Period.

There are already a large number of reasons not to use Java on Power Macs, not the least of which being Flashback, which exploited a hole in the Java VM sandbox to run a native binary and thus gain control of the Mac. If the binary had been compiled universal, then the exploit would have worked on Power Macs, too.

Well, Flash just got that sort of exploit, but it's worse, because this attack will work successfully against Power Macs too. "Rosetta Flash" (how appropriate!) can steal credentials and cookies by generating valid, malicious SWFs through JSONP that abuse Flash's ability to bypass the same-origin policy that would normally protect against such an attack.

There are ways that a service can protect itself from Rosetta Flash, but that's where it gets even worse for Power Mac users: the recommended server-side change to retard the attack won't work on Flash 10.1. Yes, you heard right. Even if the server implements the recommended server-side protection, Flash 10.1 will still download and execute the malicious SWF. And that's critical, because there is no Flash 10.2 or above for Power Macs, just various hacks that change the version number.

This exploit is fully weaponized, as they say in the biz. It's ready for any attacker to use. So Flash is dead: it is no longer safe for use on Power Macs, TenFourFox won't run it anyway, and if you are still using TenFourFox 17 to run Flash applets, I warned you this day would come.

So far all indications are that beta 3 is substantially faster than beta 2. I will make one last tweak to the garbage collector timeslice before release for a little better long term throughput. The only remaining bug is issue 280, which is a crash with the G5 using 7450 branching; I'm just going to revert to G5 branching as was originally in 24/26/29. I'm now starting to think that the performance delta might be a benchmark artifact anyway, and it's not worth the trouble to debug prior before release. Meanwhile, 31 will come out on schedule simultaneously with 24.7.0 to conclude ESR24. Another year of support ahead!

Well, let's just wave our hands around a bit with 31.0b3 for you

Today in the USA, we celebrate July 4th where America freed itself from the little-endian tyranny of King Tim by throwing Mac Pros into the harbour. Or something like that, I was always daydreaming about Alyssa Milano in civics class. Anyway, Beta 3 is now available (downloads, release notes) corresponding to the Firefox 31 beta 6 code drop. I am not able to distinguish much performance difference from 29 now, and the initial beachball with Adblock is gone on the quad G5 and lasts only a few seconds on the iBook and iMac G4 systems. On battery in Reduced mode, I consider my iBook G4/1.33's performance acceptable -- I can get into Gmail and my office mail much more quickly, and scrolling is significantly less sluggish. This also fixes the problem with spurious extra Window menu entries. Make sure you update your Adblock Edge and Plus; there were some recent updates for ABE, at least.

There were two problems with JavaScript, and I appreciate Chris Trusch for giving me reliable figures that I could replicate (performance issues cannot be fixed without them). For this purpose I compared performance in debug builds, which is not something I usually do for obvious reasons and is what led to me finding the second problem. Indeed SunSpider and microbenchmarks were performing worse in 31 and it turned out to be another side effect of the added Ion optimization analysis I had to work around once already. I added another check to not run it except in the situations that 29 runs it, and while the analysis is more heavyweight than 29's, the added improvements to inline caches in 31 generally even the impact. I think I can port this change forward; it's not very complex. Interestingly, V8 was at most fractionally perturbed by this, at least on the quad, so we're going to have to watch both benchmarks again in the future.

However, when I built the optimized version, it was still the same speed as beta 2 despite the debug build now being substantially faster. That didn't make any sense at all. Why would a debug build now beat the optimized build by almost a factor of two? It's not only bigger, it's deliberately more inefficient!

After about a week comparing source code, it became obvious that indeed there was nothing in Mozilla's debug code that was doing an operation with side effects or something getting cached that wasn't in the opt build. To prove that, I turned Mozilla's -DDEBUG on for the G5 opt build and the numbers indeed sank further. Incredibly, Shark would run the JS shell at least (even if it won't run the browser, so now I'm reexamining my theory about pilotfish -- perhaps it's just objecting to the size of XUL, which would not be surprising), and comparing the performance traces in Shark showed that the G5 opt build was slow across the board even in things that had no debug code at all, like C++ object constructors. WTF?

The other difference in a debug build is the compiler settings. So, over the second week, I did like we used to do to find the bad extension and ran and re-ran builds with different permutations of compiler and build settings to find the setting in the debugging configuration file that made the difference. And the winner was, incredibly, --enable-debug-symbols=-gdwarf-2 -- adding that to all the optimization configs greatly improved performance. For JavaScript, and now the entire browser, the opt build is once again substantially faster than the debug build just as you would expect. (One other note is that the G5-specific branch stanzas we relied on for 11-29 look like they are not working well in PPCBC, so the G5 build now uses the same shortened branch stanzas Ben innovated for JaegerMonkey on G3 and G4. This further improves V8 by about 8%.)

I don't have a good explanation for why DWARF-2 symbols weren't needed in 29 but are needed now; all I can think of is that somehow we crossed some internal maximum and we need the more efficient modern representation, even though the opt build does strip out most of the symbol table. This may have a consequence for debugging and crash reports, but I don't think we can go back to the old STABS symbols for 31. We'll just have to deal with the problems as they come up.

Your remaining homework:

• I'm toying with bumping the GC timeslice back to 100ms as it was in 29 (it remains at 30ms right now, same as 24). You can try this by setting javascript.options.mem.gc_incremental_slice_ms to 100 and restarting the browser. This should not make much immediate difference; this is for later on when there are more compartments for the garbage collector to search. I just want to make sure that it doesn't slow the browser initially.

• Now that we have substantially changed the browser foundation, we should reexamine some earlier performance conclusions. If you are on a multi-core Power Mac, such as a dual G4/G5 or the quad, try turning OMTC back on and restarting the browser. Does it help? Does it help on a uniprocessor Mac? It's hard for me to judge on my test systems. To try this, toggle layers.offmainthreadcomposition.enabled to true and restart the browser. The G5 seems a bit better, but it's a wash on the iMac, and the iBook is still questionably worse.

• The most important question: release 31 on time on July 22, or wait for 31.1? It's important to us to prove to the Mozilla community we're still a viable and well-maintained port, and I'd like to release on time to make that clear. However, if you have a good reason to wait, I'm willing to consider it; either way, though, we will release no later than 31.1. We need to stay current and ESR24 is going away.

I have not come to a firm decision about dropping source parity, though some code changes in 33 are making me unhappy (they're not portkillers, but they're a lot of work and will invalidate substantial portions of our changesets). I might jump straight to 33 from 31 to deal with those and the irregexp migration at the same time. If that goes awry, that would make my decision for me.

One outstanding bug is a printing crash on Tiger Server only. I have never supported the Server versions of 10.4/10.5, mostly because I have no way to test them and I don't have a need to run OS X Server personally. However, if you're using it, please look at issue 279. While I will not hold the release to fix this and I don't have the ability right now to fix it myself, if you do, I will accept your patch as long as it doesn't regress the regular OS X client versions.

In July we will have our annual state of the Power Mac userbase, and I also have some fun future blog posts in the hopper on my expensive but incredibly fun Amiga 4000T (with Picasso IV, 68060 CPU card and Hydra NIC), and my old Wallstreet G3 now dualbooting Rhapsody 5.6 (Mac OS X Server 1.2) and OS 9.2.2. Plus, I picked up a Cube G4 when I was in Berkeley last week that's waiting for a power supply. The shell is in excellent shape with no major nicks or scuffs and I think it'll be a great test system for playing around with MorphOS in my copious spare time. If you're in the Bay Area and looking to pick up some more Power Macs, they've got plenty at M.A.C. on University and Shattuck and they're willing to deal. Check it out.

Progress report on 31b3

After almost two weeks of digging I was able to find two separate issues, one specifically in JavaScript and one affecting most of the browser, which seem to improve the benchmarks back to 29-levels. However, the proof is the browser's overall performance, of course, and when I fired up the G5 test build this morning before work, even with the processors set to Reduced mode I was delighted to note there's no more beachball with Adblock. This is a very good sign, but I'm going to withhold judgment until I've done some more analysis on the iBook G4; the iBook, especially if the CPU is throttled, has had the most issues with 31. The G5 is building a 7450 test build right this moment while I'm typing this over a coffee Mr. Pibb break. If the iBook's performance on battery is acceptable, then we will proceed with beta 3, hopefully over the weekend.

OMTC and generational GC will remain disabled for 31 just to give us every possible advantage.