It is no secret that Classilla has gotten backburnered because of TenFourFox, and to my regret, but there's only one of me. While we have had some substantial code contributors to this project, especially Tobias and Ben but many others, Classilla has only had a couple small patches from outside contributors and none to the core code. That is undoubtedly because it's much harder to get a build running and much harder to work with when you do, but that doesn't change the fact that it's almost entirely been a single nerd effort and this particular nerd has had bigger fish to fry. TenFourFox is the browser I use on my personal systems more than 90% of the time (Classilla and regular Firefox on my token Intel systems takes up the remainder), and I have a rule that I work hardest on the software I actually use myself.
Still, I love the classic Mac OS for its simplicity and its ease of use. Its technical underpinnings and limited multitasking may occasionally be frustrating, and everyone knows that if you push it too hard you'll be forcibly rebooting for your troubles. But there are to this day advantages to the lovely Platinum UI that OS X has not replicated and given its new direction probably never will, including its better human interface consistency, window shading, and true spatial Finder. Lots of applications and great games won't run on anything else, and so Classilla still meets a need for me today on those systems I've dedicated to running OS 9. Plus, I chafed a little bit at that Ars article, since Andrew didn't even try to explore its admittedly unusual features. ;)
My first thought was to allow this fatal error to become a non-fatal error that someone could override, similar to forcing acceptance of certificates that were expired or the wrong domain name. In fact, I did implement this (using a different error code so that SHA-1 certs that didn't validate would still fail with a fatal error code), because one day there will be a certificate signing algorithm beyond even the whole of SHA-2. But by 2017, virtually every certificate would fail this test because there would be almost no SHA-1 (let alone MD5) certificates left, meaning certificate verification would essentially not take place for any site. As a future-proofing stopgap, that's one thing, but there must be a better solution in the meantime. How much work would it be to add this support so that Classilla's NSS could actually do the verification?
Interestingly, even though the NSS (Network Security Services) library in Classilla is old, roughly equivalent to 3.7.8 with patches, there was a SHA-2 implementation in its hash algorithm suite that had never been hooked up to anything. In fact, Classilla didn't even have it in its CodeWarrior project files. It compiled and appeared to support everything necessary for a complete SHA-2 implementation (including SHA-256, SHA-384 and SHA-512 variants), so I sat down and noted everywhere that SHA-1 was referenced and duplicated that using the same API. And what the heck -- it worked. Plus, it's a template if SHA-384 or SHA-512 certificates become more common; they can be implemented in exactly the same way. At some point SHA-1 certificate support will also be sunsetted in Classilla, and will be treated as an unknown algorithm, but I will probably not do this until well after the major browsers no longer accept them either.
Server Name Indication was a tougher one. SNI is an extension to the initial TLS handshake that allows virtual hosts on the same server to have different certificates; Mozilla did not support it until Firefox 2.0 (Gecko 1.8.1). Without this support, site hostnames will not appear to match, requiring a fallback to that override dialogue box I'm trying to avoid. Digging through old issues I found a patch in Bugzilla that seemed to fit the bill in a simple sense, but not only did it not work, it made the browser incredibly unstable. NSS can be very byzantine to understand with earlier versions festooned with magic constants and offsets, and one wrong move will upset the entire apple cart. So I pulled that out and tried to hack in some support of my own, but as soon as I turned it on, HTTPS hosts complained my handshake was bad. I had to use openssl on my POWER6 as a dummy server to debug what was going back and forth over the wire until I figured out where my byte offsets were going wrong after a marathon 12 hour hack session. Once this was done, suddenly a great many sites started working even better, to the point where we can ourselves deprecate the flawed SSLv3 in favour of TLSv1 as well (and SSLv2 is now, finally, disabled by default).
I'm not sure how much more I can cram into Classilla NSS. It supports Diffie-Hellman exchange for forward secrecy, but it has absolutely no support for elliptic curve variants (for example, it supports DHE-RSA-AES256-SHA, but not ECDHE), which are more complex but much more performant for a given bit length; implementing this means not only porting over the hashing algorithms but also writing up the TLS hello extension used to negotiate them. Session ticket support is possible, but requires some substantial refactoring under the hood, and there is little payoff given the effort required. TLSv1.1 similarly is possible, but will require a lot of reworking, and many features of TLSv1.2 such as Galois/Counter Mode would have to be implemented from scratch (of terribly questionable utility on a platform where most systems are uniprocessor). However, TLSv1.3, currently in draft, will remove support for non-AEAD ciphers and Classilla's cipher suite is all non-AEAD, so being just short of a complete rewrite it would be nearly impossible to implement it in any reasonable time period. At some point the combination of MD5 and SHA-1 used in TLSv1 will be considered similarly weak, and TLSv1 will also be deprecated, though I don't expect that for some time yet to come. For the next few years even sites that eventually implement TLSv1.3 will still downgrade to TLSv1 and Classilla will still be able to access them. In fact, it is the only classic Mac OS browser now that can.
Compared to those two big updates, the remaining changes are relatively pedestrian. There are some new Byblos stelae for Bing and DuckDuckGo, and Byblos stelae can be stored in Documents:Byblos: so that you can keep the custom ones you write between updates. I fixed issues with custom user agents, wallpapered an annoying layout crash and refreshed user agent strings and SSL certificates. Plus, mail and news is a little faster by not constantly loading an ancient 404 URL from Mozilla (I'm sure their network ops office appreciates the load of thousands of classic Macs being lifted).
For 9.3.4 I intend to return to the security rollup I wanted to complete, and hopefully the hiatus between versions will be much less this time. Layout is still going to be limited, but as Byblos improves I intend to rely more on it to help sites help themselves. If you have a Byblos stele that works well for you, please submit it. I also really want to figure out what the heck is up with this blog layout and scrolling!
Classilla was tested on 9.2.2 on the big 1.8GHz MDD G4, 9.2.2 on my strawberry iMac with a 600MHz Sonnet HARMONi G3, 9.2.2 on my Twentieth Anniversary Macintosh with a 500MHz G3, 9.1 on my 7300+G4/800, 9.1 on my 1400+G3/466 and 8.6 under Rhapsody Blue Box on the Wally G3. Download it now.
It was nice to get the browser and a wonderful classic OS working on the modern web once again, and even though TenFourFox is my priority, I am delighted to say that Classilla is still my joy.