Saturday, February 22, 2014

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.

Tuesday, February 11, 2014

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.

Sunday, February 2, 2014

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.