Boy howdy, it sure is interesting what sort of policy changes a little well-placed litigation can shake loose, isn't it? You're probably already familiar with the long-standing complaint among several Mac users that, despite the fact that their Macs (such as Bondi Blue iMacs, original iBooks, beige G3s, etc.) are on the official "supported hardware" list, the older ATI graphics chipsets found in those particular systems aren't fully supported in Mac OS X. Crazy optimists that we are, we always just figured that Apple simply hadn't yet gotten around to fixing that-- but in December, the company officially stated that further support for those chips was "not planned."

Well, as you can imagine, even if Apple never had any intention whatsoever of adding support for older ATI chipsets, admitting that fact in public was probably a mistake; we have this unshakeable mental image of Apple's entire legal department all saying "D'oh!" at once. With a fairly clear gulf between what was promised and what Apple admitted that it would (or would not) provide, it was only a matter of weeks before we heard about a class action lawsuit alleging that Apple had lured buyers with promises of certain technology it then decided not to deliver. And frankly, as much as we love Apple, it looked to us that for Apple to wriggle out of this snafu would be a litigational upset almost O.J.-esque in its range. Well, okay, maybe not that bad, but still, Apple's statement that further support for those chipsets "is not planned" looks like a smoking gun to us, and it's available right on Apple's own web site.

Or, at least, it was. Interestingly enough, according to an article at MacCentral, Apple has quietly changed that Knowledge Base article, which now states that "further support for the graphic accelerator chipsets listed above is being investigated for a future version of Mac OS X." So whaddaya think-- is this Apple seeing the light after facing a lawsuit it didn't think it stood much chance of winning, or is it just the company trying to get rid of the evidence to cover its butt? Frankly, we wouldn't necessarily put it past Steve and co. for engaging in a little creative revisionism, but we're just nutty enough to think that Apple really is reconsidering its position on older ATI support.

After all, if Apple was hoping that the plaintiffs would see the new page and just rub their eyes and say, "gee, we must have read that wrong the first time-- let's drop the case," the company's even more naïve than we are, and that's hardly likely. No, Apple's a business, and right now it's presumably weighing whether the costs to build better legacy graphics support into Mac OS X would outweigh the costs of fighting-- and quite possibly losing-- the lawsuit. We can hardly wait to hear what the decision turns out to be. May we hazard a guess that "upon further investigation," Apple will decide to support those chipsets after all? Fingers crossed, anyway.

Question: How can Apple make AirPort go faster? (The first person that says "grease its runways" gets a smack upside the head.) Because, as you know, we've all been hearing about faster AirPort implementations coming "real soon now" since, oh, we'd say roughly about the end of the Battle of Hastings. The tricky bit is that AirPort is based on the 802.11b standard, and while there's a faster 54 Mbps 802.11a floating around out there, the two aren't compatible because they operate at different frequencies-- and we doubt Apple's going to move to a standard that won't work with any existing AirPort cards or Base Stations. But there has to be a way to increase AirPort's bandwidth without sacrificing compatibility, and it has to happen sometime, right? So as long as rumormongers keep bringing it up, eventually it has to come to pass.

Seriously, we're not just saying that. If you were beginning to despair about the prospect of AirPort ever being able to break out of its 11 Mbps box, trust us; it can be done, and we have proof. According to an article in PC World, U.S. Robotics has already announced a new line of 802.11b-compatible wireless networking products that will be available in June and will run at a relatively zippy 22 Mbps-- while retaining full backward compatibility with older AirPort-style 11 Mbps devices, and providing "better range," to boot. (This is apparently that technology that was expected to become the 802.11g standard, although it sounds like the standards committee passed it over.) That all sounds great, except for one thing: it's not being made by Apple.

However, U.S. Robotics fully expects that now that it's announced the first 22 Mbps wireless products based on Texas Instruments' ACX100 chip (where all the magic happens), announcements from other companies will follow "in a matter of weeks." Could one such company be Apple? Sure, Apple likes to lead where it can-- AirPort itself was really the first consumer-priced wireless networking architecture that didn't suck-- but it's not at all out of the question that we might see an announcement of a line of me-too ACX100-based double-speed AirPort products within a month or two.

Or maybe not. Faithful viewer Joe Radosevich tells us that Mac OS Rumors is cranking out tales of a new set of AirPort gear that Apple has been schlepping to secret demos for certain Left Coast educational institutions. Apparently Apple has pooh-poohed this whole "twice as fast" nonsense and really gone for the throat, wirelessly speaking; allegedly this stuff somehow manages to do its thing at a whopping 112 Mbps, representing a full tenfold increase in bandwidth, and with a range boost, too. A tenfold increase? Considering that the technology that was going to be 802.11g reportedly tops out at 54 Mbps, it sounds like Apple just may have told backward compatibility to take a hike after all.

Then again, 802.11a (the incompatible wireless standard just coming to market) reportedly maxes out at 54 Mbps, too, so we really have no idea what Apple may have done to more than double that speed. Assuming the reports are true, all we can guess is that dark and arcane magicks are involved. And possibly animal sacrifice.

Okay, help us clear up a little confusion, here... Bill Gates really did issue a companywide memo urging all Microsoft employees to usher in a new era of "trustworthy" computing by putting security ahead of new features, right? And he even ordered the company to cease development for a month to find and squash bugs-- that wasn't just some wacky fever-dream on our part? Because it certainly seems to us that the Microsoft security holes are still coming fast and furious. Heck, on the Mac side alone, we had that Office bug in February which allowed a remote doofus to shut down your software by sending a "malformed packet," and then that other issue just a few days ago which could compromise your Mac by allowing evildoers to "run arbitrary commands." So, uh, what happened to that whole "trustworthy computing" initiative? Because right about now we trust the security of Microsoft's products about as far as we can hurl Bill Gates's net worth in pennies.

And yeah, we fully understand that these bugs were introduced long before Bill's incredible epiphany that a reputation for security might be a necessary selling point to sucker the whole planet into dumping their identities into .NET. But if you want a recent example of why that "leaked" Gatesian edict for Security Over Features was little more than a PR stunt, look no further than the Gigantic Microsoft Security Hole du jour: a few days ago, Wired reported that Internet Explorer's security settings for a given page kinda sorta don't apply in any way, shape, or form once a user moves on to another page and then clicks the "Back" button.

In other words, if we're understanding this correctly, say you visit a page packed full of nasty painful evil scripting junk, but you've got IE configured to block the code from executing automatically. Pleased with how your deft use of security settings prevented disaster, you then visit a security site you've bookmarked so you can tell them about the evil page. But you forgot to copy the URL, so you click the "Back" button... and whammo, the code executes automatically-- deleting all your files, raiding your fridge, drinking right out of the milk carton, and using the last of the toilet paper without replacing the roll. Bad, naughty, evil code.

Now, okay, we admit that this bug was certainly introduced prior to when the Shining Example of Security memo went around in January. But here's the wacky bit: when the Microsoft Security Response Center was informed of this problem, it "thoroughly investigated" the issue and finally arrived at the conclusion that "the proposed exploit scenario... does not meet [its] definition of a security vulnerability" because it "requires the attacker to compel users to click on the back button while visiting a malicious website." According to Microsoft, the scenario therefore "does not constitute a viable threat to users following standard best practices."

So there you have it, folks-- using the "Back" button in Internet Explorer isn't a standard, best security practice. Apparently everyone just knows this a priori, or at least Microsoft assumes they do, because nowhere in Microsoft's documentation does it state that using the "Back" button is only for loose cannons who are itchin' for trouble, nor is the button labeled "Back Minus Security Measures" (though maybe that full title was just truncated to fit in the toolbar). By the way, this is only a problem under Windows; the Mac version is safe. But if the official corporate reaction to this bug is any indication of Microsoft's progress down the long road to Securityville, we'd say the company is just about ready to start thinking about maybe putting on its left shoe. Who knows? Maybe by the end of the year Microsoft will even tie the laces!