Tuesday, September 22, 2015

Sandboxin' Safari on PowerPC (because plugins can't be trusted, and neither can you)

First, for your entertainment, another episode of keeping old Power Macs running in the age of Intel. The hardware failure this week was oslo, the Sawtooth G4 file server and backup depot, which started throwing weird checksum errors on its Sunday backups which I couldn't figure out at the time, and then completely seized up around 2:30am yesterday morning while the G5 was backing up to it. The system is not especially complex; besides the default Rage 128 AGP card, it has a Gigabit Ethernet NIC for a point-to-point connection to the G5, an Orange Micro Grappler+ SCSI card that seemed like a good idea at the time but other than driving a SCSI CD burner essentially does nothing, and a FireWire 800 card in the bottom PCI slot connected to a 4-drive external RAID 5.

When I started getting alarms that oslo was unresponsive from the systems that couldn't dump backups on it anymore, I tried to bring it back up after work and noticed I was missing the array's core HFS+ volume (the array is partitioned into three). While the array's UFS volume seemed intact, none of the files verified; worse, not only was the HFS+ volume on it completely hosed, DiskWarrior actually crashed trying to repair it after throwing an error I'd never seen before (2351, -36 in case anyone is searching in the future).

Now, this is a backup array, so it could be dispensed with, but I wanted to understand what was going on first before wiping it. In the interest of ruling out the controller, I first decided to see if it was a problem with the array hardware and connected the RAID over FireWire to the iBook instead. To my surprise and delight, the files on the UFS volume checked out! I quickly booted DiskWarrior on the iBook and managed to get the HFS+ volume repaired -- it was pretty hideously mangled but spot checks on the files seemed to validate. So that ruled out the array.

At this point I concluded it must have been something wrong with the FW800 card. I'm notorious for keeping large amounts of spares on hand, so I got a spare FW800 card out that I'd bought as a Fry's special six years ago, pulled the old one from the bottom slot and installed the new one in the same place, and connected the array. This time, no volumes mounted, and System Profiler actually crashed when I asked it to enumerate FireWire devices. I powered off the system and said something intemperate, then started to wonder if it was something about the slot or (grr) the logic board. Fortunately, I could dispense with the Grappler+ since it was just occupying space, so I pulled that and put the new card in its slot instead. Everything mounted. Whew! Conclusion: bad PCI slot, possibly bad card as well, not clear if or which one caused the other, but I'm not going to take chances -- that card's going in the eWaste bin. Either way, the moral of this story is to not only keep backups, but keep spare parts on hand, because you never know when you'll need them. And oslo has a complete body double in the stock closet for the day it might blow its logic board entirely. Still, not bad for a machine that was built 15 years ago.

Now to the main event. I mentioned a while back a couple of secret projects I've been working on, and while one of them is probably going to get invalidated by Google again in the very near future, this second one has bigger import: no less than a safer, sandboxed way to run Flash and other plugins on Tiger. Let me introduce you to SandboxSafari.

First, let's be painfully clear about two important points: both Flash and Java remain unsafe to run on Power Macs, and TenFourFox's no-plugins policy remains inviolate. That's not ever going to change. But there are still sites people want to visit that insist on requiring a plugin and some of the sites either still work or can be coerced to work with the older version of Flash Player available for PowerPC. While not all the problems can be mitigated, it seemed to me that there could be a safer way of doing so that would reduce a potential attack profile.

Because our primary operating system of interest is Tiger (Leopard is supported, but I've always been frank that the best reason to still own a Power Mac is to run Classic apps, and that means 10.4), we can't use the Leopard sandbox, and the Leopard sandbox has at least one sandbox escape that was never fixed (though I suppose in the future it could be part of a blended implementation). So SandboxSafari takes a different approach: it runs a very limited WebKit instance in a separate process as nobody so that it doesn't run within TenFourFox or even run as you. By limiting the functionality it exposes and the privileges it can wield, it reduces the chance of an unsafe operation because it can't do many such operations.

In fact, SandboxSafari is so limited you can't even use it as a regular browser; there's no tabs, no downloads, only a single window and almost no chrome except for a right-click context menu for navigation. You feed it URLs through Launch Services, not through a typical address bar -- because there isn't one! It can't even save its own settings, nor can any plugin it instantiates, let alone anything else. The overriding idea is "as little as possible to go wrong."

So how do you use it? TenFourFox integrates with SandboxSafari through an enabler add-on included in the package. Let's say you're on one of those troublesome sites and you need Flash to operate on it. Just right-click on an open area of the page and from the context menu select the option to pass the URL to SandboxSafari (or pass it and close the tab simultaneously, such as a video site you don't need to keep open in TenFourFox). SandboxSafari will open to that URL; when you're done, just close the window and it will return to the previous app (invariably TenFourFox). You can drive SandboxSafari from your own application with AppleEvents, btw; see the openurl tool in the source code bundle.

SandboxSafari is not at all complete protection. Even though crashes are limited to the SandboxSafari process, it may still be possible for a malicious or misbehaving site to trigger other OS bugs, and while it's designed to resist modifying old files as well as creating new files, it may still be able to read other files and possibly be manipulated to upload them. A subverted plugin may also be able to activate input contexts that capture all keyboard events or draw things that look like password dialogues, and while these would disappear when SandboxSafari quits, they could potentially grab data anyway if you type in sensitive information while SandboxSafari is running. These kinds of operations are not generally dependent on the user ID in use or cannot otherwise be blocked with this method of sequestration. There are other limitations with what it can access and you should read the documentation thoroughly beforehand so you understand why.

SandboxSafari is also provided to you "best effort" and strictly "as-is." It's a means to get obsolete, insecure software to run a little more safely, but the software in question is unmaintained and known to have problems, and that means you should expect to have problems with it too. Because I don't want to turn my life into a living hell with people who can't read and don't care sending me complaints I don't want, the policy is explicit: bug reports that do not include fixes will be ignored (unless it's an obvious security issue over and above the security issues I already know it has). Don't write it here, don't post it to Tenderapp, don't E-mail me. If you're having trouble with it and you don't know why or don't care to find out how to fix it, then don't use it. I'm serious. I have enough to worry about with TenFourFox without regretting anything else I maintain. :P

Download SandboxSafari here, after reading the page thoroughly, and God have mercy on your souls.

Saturday, September 19, 2015

38.3.0 available

But first: check out the stylin' official Mozilla add-on shirt I got!

Try as I might, however, I could not find any XUL in it (there is no XUL, only WebExtensions).

TenFourFox 38.3.0 is now available for testing (release notes, hashes, downloads). Currently I'm tracking two confirmed bugs and one questionable one, none of which are fully fixed yet. We have an issue with what appears to be exact rooting and may be partially a compiler bug, but I can only reproduce it on Github, and only specifically with one particular operation. The patch I added to 38.3.0 seems to wallpaper the intermittent crash that can result from it though not the incorrect behaviour it causes with the JITs (but it does restore correct behaviour with the naked interpreter, which was not the case in 38.2.x), although I don't think this is the cause of some of the unreproducible crashes a few people have reported -- YMMV. In addition, the new jsonlz4 compressed JSON bookmark backup format seems to be bogus despite setting all the proper endian options near as I can tell, so I'm not sure why it's writing invalid data. If I can't figure this out, forcing it to save uncompressed backups a la TenFourFox 31 should not be exceptionally hard. The remaining questionable bug allegedly has to do with modal drop-down-sheet requesters becoming unresponsive, which in turn makes the browser halt (more accurately it goes into a loop where it ignores other events), but I can't get it to do so reliably. Because of these issues, official MP3 support is still delayed for the time being.

Disabling incremental garbage collection in lieu of periodic full collections of the tenured heap appears to be a mixed bag with respect to performance. Although it was a win on my systems, a few of you reported it made them somewhat worse, and not enough people reported a difference to really outweigh them. You can still consider trying it on your own Power Mac and seeing if that helps, but I've abandoned this line of enhancement for the time being and it remains enabled by default in 38.3. As always, the browser goes live on Monday evening Pacific time.

I've been slack on some other fun posts and I'll try to catch up on those soon as my situation permits.

Friday, August 28, 2015

38.2.1 is available

TenFourFox 38.2.1 is available (release notes, hashes, downloads). Due to the fact this is a chemspill and we're already delayed, it will become live by this evening. Other than the Mozilla fixes, issue 306 is also repaired. Further work on 38's MP3 support is being deferred until the replacement hard disk arrives (should be early next week).

Don't forget to test 38.2.1 with incremental GC disabled. See the previous post. Enjoy our new sexy wiki, too. Sexy. Yes.

Thursday, August 27, 2015

38.2.1 delayed due to hardware failure

TenFourFox 38.2.1 was supposed to be released to you today but the hard disk used for compiling it blew up sometime yesterday and I've been recovering data from the drive and the last backup instead. The G5 version was built before the disk died, and does check out, but the other three builds haven't been yet. Let this be a reminder that DiskWarrior can fix a lot of things but not hardware failure (and people complaining of random faults in TenFourFox, please check your hardware first -- the symptom here was random freezes because the electronics kept dropping the drive off the SATA bus unexpectedly), so Data Rescue is busy getting the recoverable pieces off it and the rest I can restore from the file server. Both tools belong in your Power Mac bug-out bag and both still support PowerPC, so please support those vendors who still support us. It should be repaired enough to resume builds hopefully late tonight but I don't have an estimated time of release (hopefully no later than Sunday). It includes two Mozilla fixes and will also include a tweak for TenFourFox issue 306.

In the meantime, a fair bit of the wiki has been updated and rewritten for Github. I am also exploring an idea from bug 1160228 by disabling incremental garbage collection entirely. This was a bad idea on 31 where incremental GC was better than nothing, but now that we have generational garbage collection and the nursery is regularly swept, the residual tenured heap seems small enough to make periodic full GCs more efficient. On a tier 1 platform the overhead of lots of incremental cycles may well be below the noise floor, but on the pathological profile in the bug even a relatively modern system had a noticeable difference disabling incremental GC. On this G5 occasionally I get a pause in the browser for 20 seconds or so, but that happens very infrequently, and otherwise now that the browser doesn't have to schedule partial passes it seems much sprightlier and stays so longer. The iBook G4 saw an even greater benefit. Please note that this has not been tested well with multiple compartments or windows, so your mileage may vary, but with that said please see what you think: in about:config set javascript.options.mem.gc_incremental to false and restart the browser to flush everything out. If people generally find this superior, it may become the default in 38.3.

Monday, August 24, 2015

Okay, you want WebExtensions API suggestions? Here's three.

Not to bring out the "lurkers support me in E-mail" argument but the public blog comments are rather different in opinion and tenor from the E-mail I got regarding our last post upon my supreme concern and displeasure over the eventual end of XPCOM/XUL add-ons. I'm not sure why that should be, but never let it be said that MoFo leadership doesn't stick to their (foot)guns.

With that in mind let me extend, as an author of a niche addon that I and a number of dedicated users employ regularly for legacy protocols, an attempt at an olive branch. Here's the tl;dr: I need a raw socket API, I need a protocol handler API, and I need some means of being able to dynamically write an document/data stream and hand it to the docshell. Are you willing?

When Mozilla decommissioned Gopher support in Firefox 4, the almost universal response was "this shouldn't be in core" and the followup was "if you want it, it should be an add-on, maintained by the community." So I did, and XPCOM let me do this. With OverbiteFF, Gopher menus (and through an analogous method whois and ph) are now first class citizens in Firefox. You can type a Gopher URL and it "just works." You can bookmark them. You can interact with them. They appear no differently than any other web page. I created XPCOM components for a protocol object and a channel object, and because they're XPCOM-based they interact with the docshell just like every other native core component in Necko.

More to the point, I didn't need anyone's permission to do it. I just created a component and loaded it, and it became as "native" as anything else in the browser. Now I need "permission." I need APIs to do what I could do all by myself beforehand.

What I worry is that Mozilla leadership is going to tick the top 10 addons or so off as working and call it a day, leaving me and other niche authors no way of getting ours to work. I don't think these three APIs are either technically unrealistic or lack substantial global applicability; they're foundational for getting new types of protocol access into the browser, not just old legacy ones. You can innovate nearly anything network-based with these three proposals.

So how about it? I know you're reading. Are you going to make good on your promises to us little guys, or are we just screwed?

Friday, August 21, 2015

Mozilla's future footgun add-on policy (or, how MoFo leadership is getting it totally wrong)

So long, Firefox. It was nice to know you.

First, Electrolysis. As mentioned, we won't support it in TenFourFox; we would need to implement a userland spawn implementation for 10.4 from scratch for starters, and I suspect that the overhead required will end up performing substantially worse on old Macs plus the inevitable OS bugs it will undoubtedly uncover. Currently Mozilla is predicting Electrolysis will reach the release channel by Fx43, which I find incredibly optimistic given predictions for Australis which slipped deadline after deadline, but it's clear Electrolysis' public unveiling in the relative near future is inevitable. Once it becomes no longer possible to launch the browser in single-process mode, likely one or two versions after, that's the end of source parity. My suspicion is that it will actually reach release by Fx45, which is the next ESR anyway, and there should be an emergency fallback to single-process that we can exploit to keep us running at ESR parity for the last time.

To facilitate addons in the new e10s world, Mozilla is effectively announcing that XPCOM/XUL-based addons are now deprecated because of their highly synchronous nature. (Technically, they'll be deprecated six months after Electrolysis goes golden master, and completely unsupported and/or incompatible within six months after that, but as far as I'm concerned announcing a future deprecation is the same as deprecating it now.) This sucks because the use of XPCOM and XUL in the Mozilla Suite and later Firefox and SeaMonkey meant easy cross-platform add-ons that could do powerful things like implementing a completely new protocol within the browser. Although jetpack addons will still work, sort of, any jetpack addon that requires chrome features is subject to this policy also. Mozilla will be enforcing this brave new XUL-free world by refusing to sign addons that rely on XPCOM or XUL in this later timeframe, which dovetails nicely with not allowing unsigned addons starting with Firefox 42. (Parenthetically I don't agree with the mandatory signing policy, and if there is a TenFourFox 45 it will disable this feature. I don't port Gecko code for the walled garden, guys, thanks.)

Calling this a footgun and the future death of Firefox is not merely hyperbole. I suspect, and I suspect Mozilla is ignoring the fact, that many Firefox users use it because of the presence of such powerful addons that just can't be replicated in other browsers. Chrome, for example, doesn't have near the functionality because it doesn't expose it, and its addons are much less useful in general. But Mozilla is not content to merely shoot themselves in the foot here; they've emptied the whole magazine into their leg by making the new add-on world based on the almost completely different WebExtensions API. WebExtensions is Blink-compatible, the engine powering Chrome. That means an author can easily create a much less functional addon that runs not only on Firefox but also on Chrome. Yup, you read that right: soon the only functional difference between Firefox and Chrome at this rate will be the name and the source tree. More to the point, many great classic addons won't work in the new API, and some addons will probably never be made to work with WebExtensions.

Riddle me this, Batman Mozilla leadership: if the addons are the same, the features are the same, the supported standards are the same, the interface is converging and Mozilla's marketshare is shrinking ... why bother using Firefox? I mean, I guess I could start porting SeaMonkey, although this announcement probably kicks the last leg out from under that too, but does Firefox itself, MoCo/MoFo's premier browser brand, serve any useful purpose now? Don't say "because it makes the web free" -- people can just go download and compile WebKit, which is open source, well understood and widely available, and they can even usefully embed it, another opportunity Mozilla leadership shortsightedly threw away. They can fork it like Google did. They can throw a shell around it. Where's the Gecko value now?

Maybe this is a sign that the great Mozilla experiment has finally outlived its usefulness. And frankly there won't be much value in a Gecko-based browser or even a Servo-based one that works exactly the same way as everything else; notice the absolute lack of impact Firefox OS is having on mobile, although I use and prefer Firefox Android personally just because I don't trust Chrome. Maybe that trust will be the only reason to keep using Firefox on any platform, because I certainly can't think of anything else.

Meanwhile, this weekend I'm rewriting TenFourFox wiki documentation on Github ahead of the impending read-only status of Google Code. Since this is true Markdown, I'm using Nathan Hill's SimpleMarkPPC since it works pretty well for simple documents of this type and runs on 10.4. I won't be copying over all the old release notes, but starting with 38.3 all future ones will be on Google Code as well. After that we'll work on the MP3 support to finalize it, and I've got a secret project to share hopefully next week.

Saturday, August 8, 2015

38.2 available, and Google Code ain't

TenFourFox 38.2 "final" is now available (downloads, release notes and hashes). This will be the last release with documentation on Google Code because I punched the button today to start moving data over to the new TenFourFox Github repo. Please note that the repo won't have a lot in it currently because Google Code is still dumping stuff over and we're still on source parity with 38ESR (we'll see about what happens next, but we have bigger fish to fry in the interim). Please do not modify issues or update wiki pages on Google Code any longer -- they will not be reflected on Github. If you have issues to file, note them here or on Tenderapp.

Langpacks for 38 are also available.

The next step will be updating the home page with the new URLs, then starting work on the revised FAQ, hashes and release note templates. As usual, 38 will become final on Monday afternoon-ish Pacific time.