Fire up Software Update, Apple just released Safari 4.0.2!

As usual, the release notes are extremely informative (laugh), stating:

This update is recommended for all Safari users and improves the stability of the Nitro JavaScript engine and includes the latest compatibility and security fixes.

Looking a the actual security announcement, this is is one update you're going to want to install. One of the security fixes addresses potential cross-site scripting attacks, via WebKit's handling of parent and top objects. The other fix addresses memory allocation for numeric character references, which if exploited, could allow arbitrary code execution or application termination after visiting a malicious site.

These issues affect Mac OS X and Windows XP and Vista, so everyone, download your Safari updates!

As usual, you will have to restart your computer after installation.

I realize I may not be your average browser user. As a web developer, a browser to me is two parts daily use, two parts testing, and one part challenge. Since 2005, I've been using Firefox in some form or fashion as both my primary browser and as a testing vehicle.

I had recently started a JavaScript-intensive project, and I appreciated Safari 4's lightning-fast JavaScript execution speeds. In Firefox, I rely mostly on add-ons like Web Developer and Firebug to help me analyze and test for mistakes in websites I build in Firefox. They work great, but enabling them slows the browser down.

That's why I was excited for the updated Web Inspector that comes as part of Safari 4. (Yes, Safari 3 first came with Web Inspector, it couldn't hold a candle to Firebug's Swiss Army knife of an add-on for Firefox.) Testing was easy, and Safari 4's Web Inspector's many improvements made me think I could migrate to Safari full-time.

Read on to see how it went.

I guess the iPhone 3.0 update and Safari 4.0.1 weren't enough for Apple. Along with the just released update to Safari, Apple has just tossed in one more Software Update:

Bluetooth Firmware Update
"This update provides bug fixes and better compatibility with the Apple Wireless Mighty Mouse and Apple Wireless Keyboard. It installs on all Macintosh systems with Bluetooth based on the Broadcom chipset."

This update is only applicable to certain hardware configurations (as noted above), so if you don't see it, you don't need it. After running, the Bluetooth Firmware update will provide you with an installation screen and require a reboot when it's done.

I wonder if Apple will throw us any other new surprises today.

Digg's Kevin Rose, perennial purveyor of information that just "fell off the back of the truck" shared a link early this morning to Google's new, supercharged, Webkit-based browser -- for Mac.

The new browser, Chrome, is clearly marked as a developer preview, and not meant for general browsing. In fact, as a good Mac citizen, it will refuse to set itself as your default browser.

It scores a 100 on the Acid3 test straight out of the box, but doesn't pass: it fails something called the linktest, which involves interacting A tags and IFRAMEs. A little research suggests that it could be a bug with Webkit. If that's true, then it's a bug that Safari 4 beta has fixed.

Chrome appears to have Flash (and other plugin) support disabled as well. JavaScript support, however, is fully functional. While Chrome performed much better than Firefox on this cursory test, it still didn't beat Safari 4 by a long shot. While only a beta, its performance is respectable and sure to improve.

Again, Google Chrome isn't for everyone, but if you're a web developer who needs to keep up with the bleeding edge of browser development, then this preview should be stable and reliable enough for you to test what you need to.

Read through for the full JavaScript test details.

Thanks to everyone who sent this in!

If you're looking for a bright spot in the Mac market share numbers after the recent dips, Net Applications has your back. The May survey indicates an uptick in Safari's share of browser usage -- up to 8.43% from 8.21% in April, and 2% higher than a year earlier. Firefox continues to be the big 2nd banana to leading browser choice IE, with a 22.5% share. It's not yet clear how the IE8 release will drive browser adoption.

Operating system numbers (which aren't definitive, but provide a reasonable indicator of usage) also show a slight rise for Mac OS X (9.81% from 9.73%), also more than 2% over the year-ago allocation.

On the mobile side, the survey company notes that Android browsing usage started out with the same adoption curve as the iPhone/iPod touch, but has since fallen off that pace. Coverage of the Palm Pre starts soon.

[via Ars Technica]

It was one of those slow weekends. A good time, I thought, to clean up some odds and ends on my to-do list. Often, my list involves things relating to my computers, and this weekend was no exception.

Item #1. Install Windows 7 RC1 using VMWare. I didn't have a super urgent reason for doing so, but the time seemed right. I went to the Windows 7 download site, followed the instructions and the download never started. Just an animated thingy. I assumed the Microsoft Servers were busy, so just let it go. A few minutes passed. The thingy kept spinning. Finally, after an hour I said the hell with it. Oh, I wasn't just staring at the screen for an hour. I DID have other things to do.

I tried again later in the day. I thought, well, maybe this download is really popular, but it has been out for a few days, and certainly Microsoft has plenty of bandwidth. I tried a few tests downloads of other things, and everything was peachy.

Just for the heck of it, I tried downloading the RC with Firefox. Blam! It started right away. I'm sure other people know this, but a quick Google didn't give me any obvious joy. For whatever reason, Safari just won't connect. A subtle message from MS? Or just one of those things? Anyway, save yourself some frustration, and use Firefox. It just works. (Note: there were some comments about this in Steve's Windows 7 post)

There's no denying it: locally caching messages in Gmail on the iPhone (via the storage capability in HTML 5, similar to Google Gears) is fun and good for you, especially if you don't connect to your Gmail via IMAP in the regular iPhone Mail application. Unfortunately, if the local copy of your mail gets funky, things can become difficult and much less fun.

John F. sent in this handy tip for resolving issues with cached Gmail; his suggestion is a quick dive into the iPhone's Settings app, then navigating to the Safari preferences to clear out the local database that stores the cached mail.

You may have to wait a bit the next time you connect to Gmail in Mobile Safari as the messages are re-downloaded, but any wacky cruft should be gone. While you're in there, take a look at some of the other settings options; you may discover choices you never knew you had.

Back in March I made a plea for a native Gmail application on the iPhone. As it turned out, Google was working on a new version of the Gmail Mobile site that takes advantage of HTML5 features like database storage to provide caching functionality on the iPhone and Android phones. The demo was compelling; a super-fast Gmail experience that includes long-awaited features like full label support, the ability to apply changes to multiple messages at once, and a floating action bar (dubbed the "floaty bar") that allows you to archive, delete, mark read/unread, add or remove a star, or mark messages as spam without having to scroll to the top or bottom of the thread you are viewing to do so.

The demo was certainly exciting, but though I was hoping would be released soon, I was fearing we were still a year away from seeing this new version of Gmail Mobile. Boy, was I wrong.

This sexy new web version of Gmail Mobile was released yesterday, and as a heavy Gmail user I have only one word for it: Glorious! Okay, I'm a blogger, so we know I never only have one word for something. But if you've been using the built in Mail app on your iPhone to avoid the clunky web version, it's time to try Google Mobile again.

While it's a huge, massive improvement on the previous version, the new Google Mobile is not without areas that could use improvement. For one, it is very slow to load. For me, I'm willing to put up with this since once it does load everything is significantly faster than it was. But it would certainly be nice to see an improvement in this regard, and that's something that was hinted at on the Official Gmail blog post announcing this new version. Another small annoyance is that the buttons are smaller than standard iPhone buttons, and there are more of them. It's manageable, but does require a bit of extra care and attention.

All in all, a very solid improvement, and one that makes working with email on the iPhone significantly more pleasant for Gmail users.

Ars is reporting the 3.0 speed improvements to Mobile Safari's JavaScript engine range from 3x to 16x -- a blessed boon to web developers everywhere. No one seems to know if Mobile Safari will be sporting Nitro or SquirrelFish or what, but whatever it is, it'll be faster. If you check out the benchmarks originally posted on Wayne Pan's blog, iPhone OS 3.0 blazes past 2.2 in every category except divisions (the benchmarking tools are available at Craig Hockenberry's blog here).

It's nice to see progress, but I don't think anyone expected Apple to let the JS engine in Mobile Safari lay fallow for long. Every day browsers like Opera Mini and Android's WebKit-based browser are getting better. Heck, even WinMo's version of IE is supposed to support H.264, Flash and Silverlight. Will the upgraded js engine and technology like CSS3 and Canvas draw more developers to iPhone web apps? I doubt it, but the speed improvements will make many browser-based services feel more responsive. That's certainly a win for consumers.

Update: Thanks as well to everyone who pointed out that we got our sources mixed up! The article linked is the 2007 CanSecWest, and we apologize for the confusion. The winner of the 2009 competition was Charlie Miller (sorry Charlie), and you can read more about this year's competition here -- IE8 and Firefox have also been compromised in the competition. If you're curious about the state of Mac security and exploitation, be sure to check out Dino Dai Zovi's presentation here.
Special thanks to Chris von Eitzen at The H, and to everyone else who let us know!

---

Another year, another Pwn2Own at CanSecWest and Safari falls... in a short time. Well, to be fair, Safari fell after 24 hours and "... a couple of seconds" give or take a few. On day two of the event the "attack surface" widens -- that is, hackers are given more ways to hijack the machine. In this case, it wound up being a hole in Safari. As the barrier was lowered, an email was sent to the judges, who clicked on it, and that link took them to a special page that exploited the vulnerability. The exploit was discovered by Dino Dai Zovi who, "wrote the exploit overnight in about 9 hours" as MacDailyNews reports. Dino was assisted on the ground by Shane Macaulay. As yet, we haven't seen this in the wild and the hole has been properly disclosed to Apple.

As Download Squad notes, Firefox and Internet Explorer 8 were taken down some time later. Before declaring Safari "less secure" then those browsers, it is important to note that the hole has been reported to Apple, who need only issue a patch to fix it. Further, the exploit that took Dino 9 hours to write isn't publicly available. That said, it stresses the importance of installing browser patches and security updates for your machine. The best part about finding these exploits at events like CanSecWest is that they help make Safari, and every other browser, more secure.

Thanks to everyone who sent this in!

Safari 4 Beta's new tab arrangement has me bothered. It seems to be largely lifted from Chrome's user interface that puts the tabs at the very top of the window. Not only is this a departure from Apple's typical UI choices, it presents problems for users with special needs.

On your average Apple user interface, every object -- a title bar, menu, button, or handle -- has a single function. It can resize the window, move it, close it, or scroll it. Safari 4's tabs, however, have a dual purpose: They not only can be selected to move the entire Safari 4 window, but can be clicked individually to display their contents. In Safari 3, this was handled by two different objects -- the title bar to move the window, and tabs in the tab bar.

Google chose to put tabs at the top of the window because it was an important part of the user metaphor for their web browser, Chrome. In Chrome, tabs are independent processes brought together in a kind of stack. This is all very well and good, but it poses the same problem of having the area at the top of the window do two things at once: move the window as a whole, and control each item in the stack.

After waiting a day for the dust to settle -- and for developers to catch up -- since Apple's release of Safari 4 beta, it looks like there are relatively few show-stopping bugs to talk about. Just about every problem we've heard about at TUAW, and every issue I've had personally, has been an issue with a plugin. Fortunately, for those of us who really depend on hacks plugins for surfing productivity, most developers have been preparing for the release using nightly builds and have already come through with updates.

Yes, plugins break when software is updated, when the software is beta, and when -- due to the lack of a genuine plugin architecture -- plugins are, in fact, hacks. The developers of our third-party goodies have our backs, in most cases, and I expect the ripples on the water to die down completely over the next week.

In the area of search plugins, I switched from Inquisitor to Glims a while ago because of the extra features Glims offers. I haven't seen an update to Inquisitor yet, but Glims came out with build 13 this morning. Unfortunately, my search-as-I-type functionality still isn't working, but the plugin loads and the additional functionality is there. It's quite possibly a conflict with another plugin ... not that I'm running that many.

Thanks Vivek!

Postscript: Brian Mastenbrook, who discovered the Safari RSS vulnerability has posted a blog entry detailing how he discovered the problem, why he issued a warning and how long it ultimately took Apple to respond (6 months!). It's good reading and a good discourse on how our favorite company handles security threats and how they might want to improve.