TenFourFox FPR23b1 available

TenFourFox Feature Parity Release 23 beta 1 is now available (downloads, hashes, release notes). This version brings various oddiments of image tags up to spec, fixing issues with broken or misdimensioned images on some sites, and also has a semantic upgrade to Content Security Policy which should fix other sites but is most important to me personally because now TenFourFox can directly talk to the web BMC interface on Raptor Talos II and Blackbird systems -- like the one sitting next to the G5. There is also a minor performance tweak to JavaScript strings and the usual security updates. Assuming no major issues, FPR23 should go live on or about June 2nd.

TenFourFox FPR22 available

TenFourFox Feature Parity Release 22 final is now available for testing (downloads, hashes, release notes). There is no difference from the beta except for outstanding security fixes and updated timezone locales. As usual, if all goes well, it becomes live Monday evening Pacific time.

I don't have much on deck for FPR23 right now, but we'll see what low-hanging fruit is still to be picked.

TenFourFox FPR22b1 available

TenFourFox Feature Parity Release 22 beta 1 is now available (downloads, hashes, release notes). I have abandoned trying to write that AltiVec GCM routine because it really needs 64-bit elements, something that 32-bit AltiVec obviously doesn't have, and the 32-bit version I attempted to throw together ended up being not much faster (if at all) than a scalar approach. Since this seemed like a lot of risk for no gain, I just threw in the towel. Instead, this release has a syntactic update to JavaScript and also improves the performance of H.264 streams using the MP4 Enabler, especially on multiprocessor systems. This now by default uses the lower "fast" quality mode of ffmpeg and because it is not spec-compliant may cause odd behaviour on a few videos. If you notice this, advise which URL, and then set tenfourfox.mp4.high_quality to true (you may need to add this preference). TenFourFox FPR22 final will come out parallel with Firefox 76/68.8 on or around May 5.

TenFourFox FPR21 available

TenFourFox Feature Parity Release 21 final is now available for testing (downloads, hashes, release notes). Since the beta looks like it's working well, this release simply completes the upgrade with updates to the ATSUI font blacklist and all outstanding security patches, including backported fixes from the recent Mozilla security chemspill for CVE-2020-6819 and CVE-2020-6820. Note that while we are indeed vulnerable to those security issues and they are fixed in FPR21, they would require a PowerPC-specific attack to be successful. Assuming no issues, this will go live Monday evening Pacific time as usual.

In addition, language pack users should note that new langpacks are available for FPR21, thanks to Chris T's hard work as always. These updated langpacks have additional strings related to TLS 1.3 plus other sundry fixes; simply run the installer as in prior updates. They will go live on Monday too.

TenFourFox FPR21b1 available

TenFourFox Feature Parity Release 21 beta 1 is now available (downloads, hashes, release notes). I decided against adding the AltiVec GCM accelerator for this release, since it needs some extra TLC to convert from VSX to VMX, and I'd like to test the other major changes independently without introducing a bigger bug exposure surface than necessary. As promised, however, this release does have support for higher-speed 0RTT TLS 1.3 with HTTP/2 (particularly useful on Google properties) and has additional performance adjustments to improve parallelism of TLS connections to HTTP/1.x sites (mostly everybody else). I also updated Reader mode to the most current version used in Firefox 74, incorporating several important fixes; for a slow or complex site that you don't need all the frills for, try turning on Reader mode by clicking the "book" icon in the URL bar. You can do it even while the page is loading (reload after if not all of it comes up). FPR21 will go live with Firefox 68.7/75 on April 7.

TenFourFox FPR20 available

TenFourFox Feature Parity Release 20 final is now available for testing (downloads, hashes, release notes). This version is the same as the beta except for one more tweak to fix the preferences for those who prefer to suppress Reader mode. Assuming no issues, it will go live Monday evening Pacific as usual.

I have some ideas for FPR21, including further updates to Reader mode, AltiVec acceleration for GCM (improving TLS throughput) and backporting later improvements to 0RTT, but because of a higher than usual workload it is possible development may be stalled and the next release will simply be an SPR. More on that once I get a better idea of the timeframes necessary.

TenFourFox FPR20b1 available

TenFourFox Feature Parity Release 20 beta 1 is now available (downloads, hashes, release notes). Now here's an acid test: I watched the entire Democratic presidential debate live-streamed on the G5 with TenFourFox FPR20b1 and the MP4 Enabler, and my G5 did not burst into flames either from my code or their rhetoric. (*Note: Any politician of any party can set your G5 on fire. It's what they do.)

When using FPR20 you should notice ... absolutely nothing. Sites should just appear as they do; the only way you'd know anything changed in this version is if you pressed Command-I and looked at the Security tab to see that you're connected over TLS 1.3, the latest TLS security standard. In fact, the entirety of the debate was streamed over it, and to the best of my knowledge TenFourFox is the only browser that implements TLS 1.3 on Power Macs running Mac OS X. On regular Firefox your clue would be seeing occasional status messages about handshakes, but I've even disabled that for TenFourFox to avoid wholesale invalidating our langpacks which entirely lack those strings. Other than a couple trivial DOM updates I wrote up because they were easy, as before there are essentially no other changes other than the TLS enablement in this FPR to limit the regression range. If you find a site that does not work, verify first it does work in FPR19 or FPR18, because sites change more than we do, and see if setting security.tls.version.max to 3 (instead of 4) fixes it. You may need to restart the browser to make sure. If this does seem to reliably fix the problem, report it in the comments. A good test site is Google or Mozilla itself. The code we are using is largely the same as current Firefox's.

I have also chosen to enable Zero Round Trip Time (0-RTT) to get further speed. The idea with 0RTT is that the browser, having connected to a particular server before and knowing all the details, will not wait for a handshake and immediately starts sending encrypted data using a previous key modified in a predictable fashion. This saves a handshake and is faster to establish the connection. If many connections or requests are made, the potential savings could be considerable, such as to a site like Google where many connections may be made in a short period of time. 0RTT only happens if both the client and server allow it and there are a couple technical limitations in our implementation that restrict it further (I'm planning to address these assuming the base implementation sticks).

0RTT comes with a couple caveats which earlier made it controversial, and some browsers have chosen to unconditionally disable it in response. A minor one is a theoretical risk to forward secrecy, which would require a malicious server caching keys (but a malicious server could do other more useful things to compromise you) or an attack on TenFourFox to leak those keys. Currently neither is a realistic threat at present, but the potential exists. A slightly less minor concern is that users requiring anonymity may be identified by 0RTT pre-shared keys being reused, even if they change VPNs or exit nodes. However, the biggest is that, if handled improperly, it may facilitate a replay attack where encrypted data could be replayed to trigger a particular action on the server (such as sending Mallory a billion dollars twice). Firefox/TenFourFox avoid this problem by never using 0RTT when a non-idempotent action is taken (i.e., any HTTP method that semantically changes state on the server, as opposed to something that merely fetches data), even if the server allows it. Furthermore, if the server doesn't allow it, then 0RTT is not used (and if the server inappropriately allows it, consider that their lack of security awareness means they're probably leaking your data in other, more concerning ways too).

All that said, even considering these deficiencies, TLS 1.3 with 0-RTT is still more secure than TLS 1.2, and the performance benefits are advantageous. Thus, the default in current Firefox is to enable it, and I think this is the right call for TenFourFox as well. If you disagree, set security.tls.enable_0rtt_data to false.

FPR20 goes live on or about March 10.