Saturday, April 14, 2018

TenFourFox FPR7b2 available

Despite being currently in the grip of my annual case of bronchitis, in which I sweat and secrete more foul cloudy phlegm than Jabba the Hutt, TenFourFox Feature Parity Release 7 beta 2 is now available for testing (downloads, hashes, release notes).

The reason for beta 2 was to fix a serious regression caused by issue 495. Since I was issuing a second beta anyway, I took the opportunity to make a few more fixes, including a glitch with image layout that manifested on the MorphOS site, fixing SourceForge's tendency to corrupt our pulldown menus with unrenderable icons, and adding support for TLS SHA-384 ciphers to fix an issue with HTTP/2 sites. There are also some security fixes for testing and instead of changing the fx shorthand UA template to Firefox 60, I just added a new fx60 one as well as a user agent for Internet Explorer 11. This means users whose sites incorrectly sniff them and are using the current Firefox 52 impersonation won't unexpectedly get Fx60 features enabled that the browser can't handle right now (this is particularly an issue for Gmail).

As a result, I'm going to rework the user agent support in TenFourFoxBox, meaning version 1.1 will not get an official release (I'll be going to 1.2). Yes, this will include allowing custom agent strings, though you'll need to do that from the command line. It will be left up at the old URL until the new one is completed.

Meanwhile, my excitement over the Talos systems finally shipping cannot be contained by my mucus. It looks like motherboard orders are being fulfilled and are already out in the public. The system depicted there, however, is not the Talos II as shipped. On the other hand, however, Phoronix actually did get access to a confirmed Talos II, pitted the POWER9 versus AMD Epyx Epyc and Intel Xeon, and came away very impressed. Especially when we consider that the software packages in question were in no way optimized for POWER9 (and are for x86_64), the Talos has very competitive performance even pitted against non-libre systems. I haven't heard that the full workstations are shipping yet, but given that the rest of the components are all off-the-shelf, it shouldn't take long.

2005 called, folks. They want their PowerPC performance jokes back.

Friday, March 30, 2018

Stuff spotted in Ready Player One

Saw Ready Player One tonight with my wife and the bro-and-sis-in-law in 3D. Capsule review: if you loved the 80s, you'll love this movie, but if you only liked the 80s you'll feel like you're being subtly manipulated. But, despite being silly and overly gamer-y, it's cute and fun, and looks pretty good. It's worth at least a matinee.

We spent a lot of time spotting old hardware in it. An Atari VCS is a major part of the plot, but we also saw a ColecoVision, though both were simulated. There were a number of old arcade cabinets, notably a Pinball 2000 Revenge From Mars. In the Macintosh world, a possibly anachronistic Macintosh LC series machine (we couldn't determine the model) turns up along with an unknown early PC which sort of resembles a Tandy 1000 of some kind. However, the real oddball was what I'm pretty sure was a Commodore 1570 disk drive. These are rather unusual and it wouldn't make sense for one to be in the United States around that time period. Watch for it in Halliday's bedroom with the unknown LC near the end of the film.

Saturday, March 24, 2018

TenFourFox FPR7b1 and TenFourFoxBox 1.1 available

TenFourFox Feature Parity Release 7 beta 1 is now available for testing (downloads, hashes, release notes). I chose to push this out a little faster than usual since there are a few important upgrades and I won't have as much time to work on the browser over the next couple weeks, so you get to play with it early.

In this version, the hidden basic adblock feature introduced in FPR6 is now exposed in the TenFourFox preference pane:

It does not default to on, and won't ever do so, but it will reflect the state of what you set it to if you played around with it in FPR6. Logging, however, is not exposed in the UI. If you want that off (though it now defaults to off), you will still need to go into about:config and change tenfourfox.adblock.logging.enabled to false. The blocklist includes several more cryptominers, adblockerblockers and tracking scripts, and there are a couple more I am currently investigating which will either make FPR7 final or FPR8.

The other big change is some retuning to garbage and cycle collection intervals which should reduce the browser's choppiness and make GC pauses less frequent, more productive and more deterministic. I did a number of stress tests to make sure this would not bloat the browser or make it run out of memory, and I am fairly confident the parameters I settled on strike a good balance between performance and parsimoniousness. Along with these updates are some additional DOM and CSS features under the hood, additional HTTPS cipher support (fixing Amtrak in particular, among others) and some sundry performance boosts and microoptimizations. The user agent strings are also updated for Firefox 60 and current versions of iOS and Android.

To go along with this is an update to TenFourFoxBox which allows basic adblock to be enabled for foxboxes and updates the cloaked user agent string to Firefox 60. There is a new demo foxbox for 2048, just for fun, and updated Gmail and user guide foxboxes. TenFourFoxBox 1.1 will go live simultaneously with FPR7 final on or about May 9.

Meanwhile, the POWER9-based Talos II showed up in public; here's a nice picture of it at the OpenPOWER Summit running Unreal Engine with engineer Tim Pearson. I'm not in love with the case, but that's easily corrected. :) Word on the street is April for general availability. You'll hear about it here first.

Thursday, March 15, 2018

TenFourFox FPR6 SPR1 coming

Stand by for FPR6 Security Parity Release 1 due to the usual turmoil following Pwn2Own, in which the mighty typically fall and this year Firefox did. We track these advisories and always plan to have a patched build of TenFourFox ready and parallel with Mozilla's official chemspill release; I have already backported the patch and tested it internally.

The bug in question would require a TenFourFox-specific exploit to be useful, but is definitely exploitable, and fortunately was easily repaired. The G5 will chug overnight and have builds tomorrow and heat the rear of the house all at the same time.

Saturday, March 10, 2018

TenFourFox FPR6 available

TenFourFox Feature Parity Release 6 is now available for testing (downloads, hashes, release notes). Other than finishing the security patches and adding a couple more entries to the basic adblock, there are no other changes in this release. Assuming no issues, it will become live Monday evening Pacific time as usual.

The backend for the main download page at Floodgap has been altered such that the Downloader is now only offered to browsers that do not support TLS 1.2 (this is detected by checking for a particular JavaScript math function Math.hypot, the presence of which I discovered roughly correlates with TLS 1.2 support in Google Chrome, Microsoft Edge, Safari and Firefox/TenFourFox). This is to save bandwidth on our main server since those browsers are perfectly capable of downloading directly from SourceForge and don't need the Downloader to help them. This is also true of Leopard WebKit, assuming the Security framework update is also installed.

For FPR7, I have already exposed basic adblock in the TenFourFox preferences pane, and am looking at some efficiency updates as well as updates to the supported TLS ciphers and hopefully date pickers if there is still time. Also, the limited profiling tools I have at my disposal suggest that some of the browser's occasional choppiness is at least partially associated with improperly scheduled garbage collection slices. I'm experimenting with retuning the runtime environment to see if we can stave off some types of collection to preserve CPU cycles and not bloat peak memory usage too much. So far, 24 hours into testing with some guesswork numbers, it doesn't seem to be exploding. More on that later.

Saturday, March 3, 2018

And now for something completely different: Make that Power Mac into a radio station (plus: the radioSHARK tank and AltiVec + LAME = awesome)

As I watch Law and Order reruns on my business trip, first, a couple followups. The big note is that it looks like Intel and some ARM cores aren't the only ones vulnerable to Meltdown; Raptor Computer Systems confirms that Meltdown affects at least POWER7 through POWER9 as well, and the Talos II has already been patched. It's not clear if this is true for POWER4 (which would include the G5) through POWER6 as these processor generations have substantial microarchitectural differences. However, it doesn't change anything for the G3 and 7400, since because they appear to be immune to Spectre-type attacks means they must also be immune to Meltdown. As a practical matter, though, unless you're running an iffy program locally there is no known JavaScript vector that successfully works to exploit Spectre (let alone Meltdown) on Power Macs, even on the 7450 and G5 which are known to be vulnerable to Spectre.

Also, the TenFourFox Downloader is now live. After only a few days up with no other promotion, it's pulling down about 200 downloads a day. I note that some small number are current TenFourFox users, which isn't really what this is intended for: the Downloader is unavoidably -- and in this case, also unnecessarily -- less secure, and just consumes bandwidth on Floodgap downloading a tool to download something the browser can just download directly. If you're using TenFourFox already (at least 38 or later), please just download upgrades with the browser itself. In addition, some are Intel Mac users on 10.6 and earlier, which the Downloader intentionally won't grab for because we don't support them. Nevertheless, the Downloader is clearly accomplishing its goal, which is important given that many websites won't be accessible to Power Mac users anymore without it, so it will be a permanent addition to the site.

Anyway, let's talk about Power Macs and radios. I'm always fond of giving my beloved old Macs new things to do, so here's something you can think about for that little G4 Mac mini you tossed in the closet. Our 2,400 square foot house has a rather curious floor plan: it's a typical California single-floor ranch but configured as a highly elongated L-shape along the bottom and right legs of the property's quadrilateral. If I set something playing somewhere in the back of the house you probably won't hear it very well even just a couple rooms away. The usual solution is to buy something like a Sonos, which are convenient and easy to operate, but streaming devices like that can have synchronization issues and they are definitely not cheap.

But there's another solution: set up a house FM transmitter. With a little spare time and the cost of the transmitter (mine cost $125), you can devise a scheme that turns any FM radio inside your house into a remote speaker with decent audio quality. Larger and better engineered than those cheapo little FM transmitters you might use in a car, the additional power allows the signal to travel through walls and with careful calibration can cover even a relatively large property. Best of all, adding additional drops is just the cost of another radio (instead of an expensive dedicated receiver), and because it's broadcast everything is in perfect sync. If your phone has an FM radio you can even listen to your home transmitter on that!

There are some downsides to this approach, of course. One minor downside is because it's broadcast, your neighbours could tune in (don't play your potentially embarrassing, uh, "home movie" audio soundtracks this way). Another minor downside is that the audio quality is decent but not perfect. The transmitter is in your house, so interference is likely to be less, but things as simple as intermittently energized electrical circuits, bad antenna positioning, etc., can all make reception sometimes maddeningly unpredictable. If you're an uncompromising audiophile, or you need more than two-channel audio, you're just going to have to get a dedicated streaming system.

The big one, though, is that you are now transmitting on a legally regulated audio band without a license. The US Federal Communications Commission has provisions under Part 15 for unlicensed AM/FM transmission which limit your signal to an effective distance of just 200 feet. There are more specific regulations about radiated signal strength, but the rule of thumb I use is that if you can detect a usable signal at your property line you are probably already in violation (and you can bet I took a lot of samples when I was setting this up). The FCC doesn't generally drive around residential neighbourhoods with a radio detector van and no one's going to track down a signal no one but you can hear, but if your signal leaks off your property it only takes one neighbourhood busybody with a scanner and nothing better to do to complain and initiate an investigation. Worse, if you transmit on the same frequency as an actually licensed local station and meaningfully interfere with their signal, and they detect it (and if it's meaningful interference, I guarantee you they will sooner or later), you're in serious trouble. The higher the rated wattage for your transmitter, the greater the risk you run of getting busted, especially if you are in a densely populated area. If you ever get a notice of violation, take it seriously, take your transmitter completely offline immediately, and make sure you tell the FCC in writing you turned it off. Don't turn it back on again until you're sure you're in compliance or you may be looking at a fine of up to $75,000. If you're not in the United States, you'd better know what the law is there too.

So let's assume you're confident you're in (or can be in) compliance with your new transmitter, which you can be easily with some reasonable precautions I'll discuss in a moment. You could just plug the transmitter into a dedicated playback device, and some people do just that, but by connecting the transmitter to a handy computer you can do so many other useful things. So I plugged it into my Sawtooth G4 file server, which lives approximately in the middle of the house in the dedicated home server room:

There it is, the slim black box with the whip antenna coming off the top sandwiched between the FireWire hub (a very, very useful device and much more reliable than multiple FireWire controllers) and the plastic strut the power strip is mounted on. This is the Whole House FM Transmitter 3.0 "WHFT3" which can be powered off USB or batteries (portable!), has mic and line-level inputs (though in this application only line input is connected), includes both rubber duck and whip antennas (a note about this presently) and retails for about $125. Amazon carries it too (I don't get a piece of any sales, I'm just a satisfied customer). It can crank up to around 300 milliwatts, which may not seem like much to the uninitiated, but easily covers the 100 foot range of my house and is less likely to be picked up by nosy listeners than some of the multi-watt Chinese import RF blowtorches they sell on eBay (for a point of comparison, a typical ham mobile radio emits around 5 watts). It also has relatively little leakage, meaning it is unlikely to be a source of detectable RF interference when properly tuned.

By doing it this way, the G4, which is ordinarily just acting as an FTP and AFP server, now plays music from playlists and the audio is broadcast over the FM transmitter. How you decide to do this is where the little bit of work comes in, but I can well imagine just having MacAmp Lite X or Audion running on it and you can change what's playing over Screen Sharing or VNC. In my case, I wrote up a daemon to manage playlists and a command-line client to manipulate it. 10.5+ offers a built-in tool called afplay to play audio files from the command line, or you can use this command line playback tool for 10.2 through 10.4. The radio daemon uses this tool (the G4 server runs Tiger) to play each file in the selected folder in order. I'll leave writing such a thing to the reader since my radio daemon has some dependencies on the way my network is configured, but it's not very complex to devise in general.

Either way works fine, but you also need to make sure that the device has appropriate signal strength and input levels. The WHFT3 allows you to independently adjust how much strength it transmits with a simple control on the side; you can also adjust the relative levels for the mic and line input if you are using both. (There is a sorta secret high-level transmission mode you can enable which I strongly recommend you do not: you will almost certainly be out of FCC compliance if you do. Mine didn't need this.) You should set this only as high as necessary to get good reception where you need it, which brings us to making sure the input level is also correct, as the WHFT3 is somewhat more prone to a phenomenon called over-modulation than some other devices. This occurs when the input level is too high and manifests as distortion or clipping but only when audio is actually playing.

To calibrate my system, I first started with a silent signal. Since the frequency I chose had no receivable FM station in my region of greater Los Angeles (and believe me, finding a clear spot on the FM dial is tough in the Los Angeles area), I knew that I would only hear static on that frequency. I turned on the transmitter with no input using the "default" rubber duck antenna and went around the house with an FM radio with its antenna fully retracted. When I heard static instead of nothing, I knew I was exceeding the transmission range, which gave me an approximate "worst case" distance for inside the house. I then walked around the property line with the FM radio and its antenna fully extended this time for a "within compliance" test. I only picked up static outside the house, but inside I couldn't get enough range in the kitchen even with the transmitter cranked up all the way, so I ended up switching the rubber duck antenna for the included whip antenna. The whip is not the FCC-approved configuration (you are warned), but got me the additional extra range, and I was able to back down the transmitter strength and still be "neighbour proof" at the property line. This is also important for audio quality since if you have the transmitter power all the way up the WHFT3 tends to introduce additional distortion no matter what your input level is.

Next was to figure out the appropriate input level. I blasted Bucko and Champs Australian Christmas music and backed down the system volume on the G4 until there was no distortion for the entire album (insert your own choice of high volume audio here such as Spice Girls or Anthrax), and checked the new level a few times with a couple other albums until I was satisfied that distortion and overmodulation was at a minimum. Interestingly, while you can AppleScript setting the volume in future, what you get from osascript -e 'set ovol to output volume of (get volume settings)' is in different units than what you feed to osascript -e 'set volume X': the first returns a number from 0-100 with 14 unit steps, but the second expects a number from 1-10 in 0.1 unit steps. The volume on my G4 is reported by AppleScript as "56" but I set that on startup in a launchd startup item with a volume value of 4.0 (i.e., 4 times 14 equals 56). Don't ask me why Apple did it this way.

There were two things left to do. First was to build up a sufficient library of music to play from the file server, which (you may find this hard to believe) really is just a file server and handles things like backups and staging folders, not a media server. There are many tools like the most excellent X Lossless Decoder utility -- still Tiger and PowerPC compatible! -- which will rip your CDs into any format you like. I decided on MP3 since the audio didn't need to be lossless and they were smaller, but most of the discs I cared about were already ripped in lossless format on the G5, so it was more a matter of transcoding them quickly. The author of XLD makes the AltiVec-accelerated LAME encoder he uses available separately, but this didn't work right on 10.4, so I took his patches against LAME 3.100, tweaked them further, restored G3 and 10.4 compatibility, and generated a three-headed binary that selects for G3, G4 and a special optimized version for G5. You can download LAMEVMX here, or get the source code from Github.

On the G5 LAMEVMX just tears through music at around 25x to as much as 30x playback speed, over three times as fast as the non-SIMD version. I stuck the MP3 files on a USB drive and plugged that in the Sawtooth so I didn't have to take up space on its main RAID, and the radio daemon iterates off that.

The second was figuring out some way to use my radios as, well, radios. Yes, you could just tune them to another station and then tune them back, but I was lazy, and when you get an analogue tuner set at that perfect point you really don't want to have to do it again over and over. Moreover, I usually listen to AM radio, not FM. One option is to see if they stream over the Internet, which may even be better quality, though receiving them over the radio eliminates having to have a compatible client and any irregularities with your network. With a little help from an unusual USB device, you can do that too:

This is the Griffin radioSHARK, which is nothing less than a terrestrial radio receiver bolted onto a USB HID. It receives AM and FM and transmits back to the Mac over USB audio or analogue line-level out. How do we hook this up to our Mac radio station? One option is to just connect its audio output directly, but you should have already guessed I'd rather use the digital output over USB. While you can use Griffin's software to tune the radio and play it through (which is even AppleScript-able, at least version 2), it's PowerPC-only and won't run on 10.7+ if you're using an old Intel Mac for this purpose, and I always prefer to do this kind of thing programmatically anyhow.

For the tuner side, enterprising people on the Linux side eventually figured out how to talk to the HID directly and thus tune the radio manually (there are two different protocols for the two versions of the radioSHARK; more on this in a moment). I combined both protocols together and merged it with an earlier but more limited OS X utility, and the result is radioSH, a commandline radio tuner. (You can also set the radioSHARK's fun blue and red LEDs with this tool and use it as a cheapo annunciator device. Read the radioSH page for more on that.) I compiled it for PowerPC and 32-bit Intel, and the binary runs on anything from 10.4 to 10.13 until Apple cuts off 32-bit binary compatibility. The source code is available too.

For USB audio playthru, any USB audio utility will suffice, such as LineIn (free, PowerPC compatible) or SoundSource (not free, not PowerPC compatible), or even QuickTime Player with a New Audio Recording and the radioSHARK's USB audio output as source. Again, I prefer to do this under automatic control, so I wrote a utility using the MTCoreAudio framework to do the playback in the background. (Use this source file and tweak appropriately for your radioSHARK's USB audio endpoint UID.) At this point, getting the G4 radio station to play the radio was as simple as adding code to the radio daemon to tune the radio with radioSH and play the USB audio stream through the main audio output using that background tool when a playlist wasn't active (and to turn off the background streamer when a playlist was running). Fortunately, USB playthru uses very little CPU even on this 450MHz machine.

I mentioned there are two versions of the radioSHARK, white (v1) and black (v2), which have nearly completely different hardware (belied by their completely different HID protocols). The black radioSHARK is very uncommon. I've seen some reports that there are v1 white units with v2 black internals, but of the three white radioSHARKs I own, all of them are detected as v1 devices. This makes a difference because while neither unit tunes AM stations particularly well, the v1 seems to have poorer AM reception and more distortion, and the v2 is less prone to carrier hum. To get the AM stations I listen to more reliably with better quality, I managed to track down a black radioSHARK and stuck it in the attic:

To improve AM reception really all you can do is rotate or reposition the receiver and the attic seemed to get these stations best. A 12-foot USB extension cable routes back to the G4 radio station. The radioSHARK is USB-powered, so that's the only connection I had to run.

To receive the radio on the Quad G5 while I'm working, I connected one of the white radioSHARKs (since it's receiving FM, there wasn't much advantage to trying to find another black unit). I tune it on startup with radioSH to the G4 and listen with LineIn. Note that because it's receiving the radio signal over USB there is a tiny delay and the audio is just a hair out of sync with the "live" analogue radios in the house. If you're mostly an Intel Mac house, you can of course do the same thing with the same device in the same way (on my MacBook Air, I use radioSH to tune and play the audio in QuickTime Player).

For a little silliness I added a "call sign" cron job that uses /usr/bin/say to speak a "station ID" every hour on the hour. The system just mixes it over the radio daemon's audio output, so no other code changes were necessary. There you go, your very own automatic G4 radio station in your very own house. Another great use for your trusty old Power Mac!

Oh, one more followup, this time on Because I Got High Sierra. My mother's Mac mini, originally running Mavericks, somehow got upgraded to High Sierra without her realizing it. The immediate effect was to make Microsoft Word 2011 crash on startup (I migrated her to LibreOffice), but the delayed effect was, on the next reboot (for the point update to 10.13.2), this alarming screen:

The system wouldn't boot! On every startup it would complain that "macOS could not be installed on your computer" and "The path /System/Installation/Packages/OSInstall.mpkg appears to be missing or damaged." Clicking Restart just caused the same message to appear.

After some cussing and checking that the drive was okay in the Recovery partition, the solution was to start in Safe Mode, go to the App Store and force another system update. After about 40 minutes of chugging away, the system grudgingly came up after everything was (apparently) refreshed. Although some people with this error message reported that they could copy the OSInstall.mpkg file from some other partition on their drive, I couldn't find such a file even in the Recovery partition or anywhere else. I suspect the difference is that these people encountered this error immediately after "upgrading" to Because I Got High Sierra, while my mother's computer encountered this after a subsequent update. This problem does not appear to be rare. It doesn't seem to have been due to insufficient disk space or a hardware failure and I can't find anything that she did wrong (other than allowing High Sierra to install in the first place). What would she have done if I hadn't been visiting that weekend, I wonder? On top of all the other stupid stuff in High Sierra, why do I continue to waste my time with this idiocy?

Does Apple even give a damn anymore?

Wednesday, February 21, 2018

The TLS apocalypse reaches Power Macs and TenFourFox FPR6b1 available (plus: let's block nuisance JavaScript)

TenFourFox Feature Parity Release 6 beta 1 is now available for testing (downloads, release notes, hashes). FPR6 has speculative but high-confidence fixes for freezes on Facebook due to a corner case with our little-endian typed array emulation and occasional crashes with textboxes which seems to be due to a glitch with getting the current CoreGraphics context. The ATSUI font blacklist has been expanded (fixing TurboTax and the Los Angeles Times) and performance has been improved slightly, URL bar handling has been tuned up and is snappier, the AltiVec routine used for YUV conversion and scaling has been tweaked to reduce unaligned loads (cutting three SIMD instructions per pixel), and I've done some manual hinting in JavaScript for when the branch predictor evicts the result. There are several new DOM features which get us a couple extra HTML5 points on benchmarks and fix sites like the Home Depot; finally, there is also one big new feature which is currently not yet exposed in the UI and I'll talk about this in a moment.

Partial work on native date pickers (with eventually time pickers) and support for idle callbacks (allowing better performance and scheduling of JavaScript tasks) is in FPR6, but they're not finished yet and therefore not enabled. The native date-time pickers use the standard NSDatePicker control instead of the XUL-based one in current versions of Firefox. Since we don't have to deal with a Windows or GTK version, we can just use the operating system controls built into Mac OS X and eliminate a lot of date management code by simply relying on the OS implementation; I have a prototype control working but haven't hooked it up to the input field yet (for simplicity, it will act as a OS modal window). Idle callbacks and support for requestIdleCallback exist in the WebIDL but don't connect to anything and there is only a skeleton implementation which does not yet function. The expected timeframe for these is somewhere around FPR7 or FPR8 and I will be working on them up until then; both of these are features I expect to see more use of, and we should support.

Unfortunately, unless you already have TenFourFox, you won't be able to download it: the "TLS apocalypse" has come to Power Macs running OS X. No browser that was previously available for PPC OS X can download TenFourFox now that SourceForge is mandating minimum TLSv1.1 support: Classilla, Safari 4, Safari 5, Camino and Firefox 3.6 all only support TLSv1.0. For that matter, TenFourFox didn't support TLSv1.1 or TLSv1.2 until version 31, when both were enabled (Mozilla added support in Firefox 27), and Safari didn't add support until version 7. The only other browser that supports TLSv1.1 or better on PPC OS X is Leopard WebKit when you also install the updated Security framework, and of course WebKit shells linked against those components, but it doesn't run on Tiger and it is also hosted on SourceForge.

SourceForge, however, is just following along with the general trend of removing TLSv1.0 support (SSLv2 and SSLv3 support have of course long since been deprecated on just about every major site). On February 22 -- tomorrow -- Github will end support for anything prior to TLSv1.2 and certain cryptographic algorithms. (If you are using a Power Mac to develop with a Github project, you'll need to upgrade your git and dependent components. I'm looking at providing those pieces as a way of facilitating development.) As the number of browsers limited to TLSv1.0 (and eventually v1.1) diminishes on the Web, more and more sites will remove support and be inaccessible to Power Macs with the default browser. Eventually this will impact things like the QuickTime Enabler which relies on the OS to download movie data, which someday no longer can.

I think it's a critical base feature that a Power Mac be able to bootstrap itself and download TenFourFox without having to use another computer. There is no way I can host several hundred megabytes on Floodgap itself, let alone deal with thousands of weekly downloads, but maybe we can just host a tool to handle the download instead. If you looked in that SourceForge directory already, you saw a new file: the TenFourFox Downloader. Grab it, copy it to one of your computers and see if it can fetch FPR5. It should be able to because it has all the pieces necessary to do so, including updated encryption and certificates, and using it should be self-explanatory. Assuming people report no problems, the Downloader will go live in a week or so and be offered from the main TenFourFox page to users on unencrypted HTTP who are using any non-WebKit browser other than TenFourFox, as well as systems without Leopard WebKit (TenFourFox and Leopard WebKit users will get regular HTTPS links as the site offers currently). While you could use the Downloader to do your version updates, it's really intended just to help new users starting from scratch to get off the ground.

Meanwhile, I'm in the midst of converting Floodgap to HTTPS, and https://gopher.floodgap.com/ is already live (and gets an "A" grade from Qualys SSL Test). However, even though the HTTPS/TLS version of Floodgap will support the latest security practices, there will always be an unencrypted version of Floodgap since I serve lots of old systems that don't even speak SSL. While I think the resurgence of the Gopher protocol means that Gopher is likely the best place for old computers to live, since it's a trivial protocol to implement, there's clients for even very limited systems like the Commodore 64(!), and lots of people in the retrocomputing hobby are rediscovering it, I'll still always offer alternatives to allow old systems to still be as useful as they can be and that means a perennial HTTP fallback just in case. That's what makes the Downloader a viable option.

Back to the invisible new feature. Google's Chrome group announced that they are now blocking "annoying" and "disruptive" ads in the browser. I think it should be applauded that Google is paying attention to this, but bear in mind Google is a media-advertising company first, and this move is a pre-emptive strike to make people not reach for adblockers as much. Instead, they'll rely on Google's adblocker, which, of course, will increasingly comply with the rules to not be as "annoying" and "disruptive" and still show you ads.

I don't care if ads are shown or not, personally. Sites need to make a buck to stay open, but if they're going to make that buck by being indiscriminate about what ad networks they use and inconsiderate of the burden they place on their viewers, then they should expect to be blocked. On our older, slower and more resource-limited systems, annoyances are not merely limited to obnoxious images and pop-over-under-arounders, but also larding sites up with additional processing from web scripts. This processing rarely benefits us directly, is usually used to spy on us, increases page load times and can bring the browser to its knees if multiple scripts are competing for the CPU because of JavaScript's "run to completion" semantics. But this isn't what Google wants to block, because these sorts of spy scripts are how they and their allied advertisers acquire their analytics.

Thus, may I present TenFourFox's basic adblock. Calling it adblock is sort of a misnomer because it's really a script block, but those scripts are usually loading ads or ad support libraries, so it achieves a similar effect. Basic adblock is implemented as a simple internal built-in blacklist. This blacklist is implemented at the "caps" level in the browser in C++, so it runs at native code speeds and can check very quickly (far, far faster than any adblock add-on, even Bluhell Firewall), and entries in the blacklist not only are marked as restricted and unable to execute code, but because they are marked as restricted, other components referencing them like adblocker-blockers also are unable to execute. The blacklist contains many common ad networks and "monetization" systems, as well as tag aggregators, user "engagement" and analytics systems, cryptocurrency miners and certain other types of arguable malware, all the major categories that make our lives online hell. The browser speeds up because there are many fewer scripts competing for resources, there are fewer pauses for garbage collection and there is less memory in use, and overall browsing performance improves.

The basic adblock is just that: basic. There is no claim that it is complete, nor will there ever be such a claim. Ads such as cooperative sponsorships that simply load images and aren't script-based, for example, will still appear (and, arguably, should; there's no easy way to distinguish such things programmatically). It's possible to add an imageblocker implemented in a similar fashion as well, but this would rapidly get into a situation where the overhead of scanning for these images exceeds the overhead of just displaying the images themselves (whereas the overhead of many of the scripts we block far exceeds any CPU time spent checking for them). For that matter, some scripts may just simply not be in the list yet. Similarly, the adblock is designed so that the functionality of a given site should remain basically the same whether it is enabled or not, which is why I haven't added entries for things like Disqus because they are part of the comments functionality on many sites, and Disqus may display some ads.

In addition, I had a firm rule while constructing the blacklist that if there is any ambiguity of what exactly is being blocked during the testing of an individual entry, or the entry causes a site to lose important features or fail to properly load, then that entry won't be added. Even when basic adblock is visibly exposed to users, it will never be enabled by default for exactly this reason. But the beauty of this scheme is that it's additive: if what's there (and it will be expanded) is not enough, you can use private browsing mode to block even more tracking scripts, or you can add an adblocker on top of basic adblock for even greater restrictions, depending on your taste and how much overhead you want to devote to that purpose.

To test it out, I first recommend either disabling or entirely removing any existing adblock or anti-tracker add-ons before you update so you can see basic adblock in its truest form. Update to FPR6b1, and in about:config set tenfourfox.adblock.enabled to true (you don't need to restart the browser). Open the MacOS Console (i.e., Console.app) and load a typical media website. Wow, look at what gets blocked! If you don't care for the running tally spamming your system log, set tenfourfox.adblock.logging.enabled to false. Logging will be disabled when the feature is released and finally exposed to users in the TenFourFox preference pane, but the log this option generates will be necessary if you need to report a site that basic adblock seems to disable or cause malfunctions on. I'm interested to hear your comments and how it interacts with other privacy add-ons, even though I myself am now surfing "naked" with only basic adblock so that I can try my own dogfood. I will be adding entries up until the FPR7 beta since the feature is not officially released yet, but once it becomes public (likely FPR7), new entries will only be added during the beta-test period to reduce regression risk from improperly or incompletely screened additions.

FPR6 final is scheduled for March 12.