Into The Unknown

Well, it didn't take long (I didn't think it would). Within two hours, a protocol handler exploit (including proof-of-concept) was posted up on the web, and then a handful of security researchers published the results of their own delving (mainly involving a stupid amount of fuzz testing to try and find weak points in the code). They turned out a fair few, less than I thought would actually be discovered (being the eternal cynic), but obviously WinSafari is still less than two days' old in the wild so I suppose there's more to come.

"It took all of two hours for researchers to find 6 bugs in the Windows version of Safari, 4 DoS attacks and 2 remote code execution bugs."
(via Wired Compiler)

Aside from the bugs in my initial impressions writeup, here's what's been found:

• The 0day exploit (found in two hours) by Thor Larholm (more info and PoC on his site);
  
  
• 4 Denial of Service attacks and 2 remote code execution attacks (found by David Maynor (yes, he of Apple WiFi hack) with free tools and a bit of elbow grease... more info);
  
  And to top it off:
  
  
• Many of the exploits also run on the OSX version of Safari, due to the shared codebase... Nice!

Avi Raff also found a memory corruption problem which crashes Safari and may be exploitable, but he reports on his blog he'll "...have to dig more to be sure of that." As Wired observe, "...six exploits in two hours doesn’t exactly make you want to rush out and download a copy does it?" (I guess it's a good job it's free then! I wouldn't pay for it, I know that much.) But, as Scott Hanselman says on his blog;

"It's clearly fast. Very fast. Like, noticeably fast, loading a half dozen sites (that take IE7 or FF2 a few seconds) within a blink of an eye. If nothing else, they've set the performance bar higher."
(via Hanselman.com)

... And you know what? I'm inclined to agree with him on this one. Obviously the rendering engine is a fast one, and as it's built on the open-standards WebKit framework with a bit of luck some other enterprising souls will come along and build a nicer-looking browser on top of the codebase, which would be perfect.

What holds me back from using Safari is... Well... I guess for one thing, it's the problem of it being an Apple-designed program for me. The forced Apple-style interface (ugh), the stupid layout and obvious skimming-over of standard Windows design (hello? top-left chrome menu?) and ignoring of design standards for the shortcuts, browser window design, missing features... Not being able to resize the window from anywhere except the bottom-left corner (where did the usability go?)

For me it's the little things with Apple's design conventions, and they all add up into a really frustrating experience for me. If Apple fix the bugs, standardise Safari's interface to match that of other Windows apps, maybe make it skinnable and retract their slightly pompous "Apple engineers designed Safari to be secure from day one" statement, I might consider using Safari on my laptop alongside Firefox, IE(6) and Opera.

Might.

I'm as big a big fan of HD content as the next geek, and I've found (as have many others) that on my PCs, along with AC3Filter and the Haali Media Splitter running the show for my decoding, CoreAVC is the most effective and efficient video codec for H.264/AVC content. However, in the CoreCodec discussion forums there's been lots of discussion about delays and widespread reports of bugs in the new version (1.3.0.0), including lack of playback once it's installed, incompatibility with Vista, and the inability to roll back to 1.2 once 1.3 has been installed - even if it's uninstalled.

The CoreCodec site, which has an online portal system for those who have purchased the codec (including personalised download links for the installers) is also in a state of hiatus, with all purchasing facilities suspended until the new versions of their most popular software - Coreplayer Mobile (formerly TCPMP, which I still use on my Vario 2) and CoreAVC - are bugfixed and compiled.

The CoreCodec developers have also commented several times on their forums that once the bugs are sorted out, 1.3.0.1 will be made available for purchase and everything will return back to normal, but the delays are increasing and feedback from the developers is less than forthcoming.


It's a shame, because CoreAVC is a really cracking codec - its performance on less-than-brand new systems is noticeably superior when put up against its main competitors, and all the processing is done in software as well - and I hate to see this small bit of bad press affect it. I have every hope that CoreAVC 1.3.0.1 will be released soon, as the developers promise. When it does I will be suggesting to the developers that they keep a closer eye on their (if small, but very active and vocal) community residing on their forums and on other forums like Doom9 so as to revise their code and fix problems much sooner. They are usually pretty good when it comes to fixing problems for next release, and their community acknowledges this, but equally this whole issue could also well be ascribed to taking a product out of beta a little too soon.

Conversely, Google loves its 'beta' tag, and applies it to just about everything (I'm still a little amazed that Google Search still isn't labeled as beta, as they're continually adding new features) - it raises an interesting question, too: given the possibility for keeping a product in continuous beta status, and releasing updates thick and fast as problems occur, is that a better practice for developers than to work a long time on fixing every problem they can foresee, releasing it to the masses then firefighting when a bunch of users come along with a new, unforeseen problem? The latter is what appears to have affected CoreCodec's product, but the former situation (thinking of Google again) also has the side-effect of devaluing the 'beta' status, and, in effect, merging together the beta and RTM levels of development until both terms have little relevance to their original meanings.


Maybe it's time for developers to rethink their usage of beta as a terminology for defining "it works, but it's not properly finished yet... But what the hell everyone, just use it anyway and don't bitch if it breaks on you", because it also - to me anyway - devalues the usefulness of effective Quality Control testing by a controlled group of testers. Every good product (should) have QC and QA performed on it at every major developmental stage, and usability tests to boot, otherwise you end up with a product which has been designed engineers without a thought paid to how regular users are going to use it.

The software which runs on 90% of the UK's checkout EFTPOS terminals (tills to you and me) is a prime example of software developed by developers without it ever having even a once-over from a usability engineer. That's possibly the most important stage of a software's beta cycle, and it's being neglected in this increasing trend of Web 2.0 "unfinishedness".


In fact, I think the beta tag should be dropped from many of the programs that use it, and replaced with a term like "almost" - that'd encourage developers to get it finished and out the door in a properly working state much faster than they do currently. Tagging something 'beta' almost encourages slower development, which isn't always good - last time I did something like that, I ended up spending weeks and weeks on it and continually losing my train of thought, which slowed down development as a whole and meant that I also lost some good ideas which I'd had but not started to work on.

Beta's not always a good thing to call something. Maybe beta-with-next-stage-deadline would be more appropriate for the majority of live, in-development projects I see on the web these days...