Anomalous Anomaly

I don’t know whether to blame the hard drive, Windows 2000, or NTFS-3G. But never in my life do I want to see chkdsk show this again:

It kept scrolling that text for about 10 minutes before finally hitting this BSOD:

So we booted a Windows Vista DVD and ran chkdsk with that to finish the job it couldn’t:

Long story short, we were trying to reformat an external hard drive and ended up putting temporary copies of the data onto the local disk. Unfortunately, the local disk went haywire at that moment, and to make a long story short, most of the files were nicely toasted. The machine needed to be reformatted as well.

During some general failure of mine, I mentioned to my mum that I would probably also fail at failing, since I can never seem to tie a proper knot.

And that’s when she told me that “Tying a noose is easy. Let me show you how.”

Talk about parental support. <3

After tormenting my room for weeks, Beelzebug has met his end.

I really enjoyed these because of how true they were to life.

From the book How Not to Program in C++ by Steve Oualline:

• Real Computer Scientists admire ADA for its overwhelming aesthetic value, but they find it difficult to actually program in it, as it is much too large to implement. Most computer scientists don’t notice this because they are still arguing over what else to add to ADA.
• Real Computer Scientists despise the idea of actual hardware. Hardware has limitations; software doesn’t. It’s a real shame that Turing machines are so poor at I/O.
• Real Computer Scientists don’t comment their code. The identifiers are so long they can’t afford the disk space.
• Real Computer Scientists don’t program in assembler. They don’t write in anything less portable than a number two pencil.
• Real Computer Scientists don’t write code. They occasionally tinker with “programming systems,” but those are so high level that they hardly count (and rarely count accurately; precision is for applications).
• Real Computer Scientists only write specs for languages that might run on future hardware. Nobody trusts them to write specs for anything homo sapiens will ever be able to fit on a single planet.

I am quite excited. The Acid 3 web standards-compliance test is now up, and there’s no browser in existence yet that fully succeeds at the test.

Let me explain what these results are telling us before I show them. The World Wide Web Consortium (W3C) develops standards for Internet applications. For example, XHTML, HTML, CSS, etc. Acid 3 basically takes a lot of W3C’s newer standards and tests to be sure that the browser supports the features it should and that it behaves as it should when using them. Acid 3 is a collection of 100 different test suites to be sure that these standards are being met. So when I say that browser X gets a score of 55%, this means that browser X passed 55 of the 100 test suites.

Updated March 8, 2008. Camino nightlies switched to Gecko 1.9 to bring it up to par with Firefox and Seamonkey nightlies. All Gecko 1.9 browsers are at 69% currently (were at 68%).

Updated March 9, 2008. Too many updates to record. I’ll start logging changes again after the Slashdot effect dissipates.

Updated March 10, 2008. I’ve received quite a few emails about different results people have gotten with their browser. I’m working on adding them all to the list.

Updated March 11, 2008. Split browser list into two sections (release and beta). Added Mobile Safari to release list. Updated Gecko nightlies (now at 70%). Added SeaMonkey 1.1.8 to release list. Removed Firefox 3.0b3 and added 3.0b4 to the beta list.

Updated March 13, 2008. I’ve received multiple requests to add Shiira to the list. Unfortunately, Shiira crashes after attaining a score of 26. I’m not going to add it until it makes it through the test (failing or not) without crashing.

Updated March 15, 2008. The latest WebKit nightly (r31078) is now at 91%.

Updated March 17, 2008. The latest WebKit nightly (r31114) is now at 93%.

Updated March 18, 2008. Safari 3.1 has been released. I’ve been informed that Acid 3 itself has been updated, so I will be rerunning the tests on all listed browsers. I don’t have an iPhone, so if someone could send me a result for Mobile Safari (assuming there’s an update for it’s version of Safari as well), that would be great. More importantly, if someone could report any inconsistencies they see here (browsers with incorrect scores), please inform me.

Updated March 22, 2008. The latest WebKit nightly (r31232) is now at 95%.

Updated March 25, 2008. The latest WebKit nightly (r31306) is now at 96%.

Updated March 26, 2008. The latest WebKit nightly (r31323) is now at 98%.

Updated March 26, 2008. The latest WebKit nightly (r31356) now passes Acid 3 (100%).

Updated March 27, 2008. People keep sending me Opera’s claim of victory on Acid 3, but since I cannot verify their results, I’m not listing it here. Once the build becomes public, I’ll add the result (don’t hesitate to email me when this happens).

Updated March 28, 2008. Opera has released a public build which passes Acid 3. I’m going to test it momentarily.

Updated March 31, 2008. Opera has released 9.50 beta 9864, it gets a 79%.

Thanks to all who have submitted their results. I was going to try and maintain a list of people to individually thank, but it’s becoming too difficult to keep track of who has sent me results and managing to get those results accurately depicted here.

These results are public domain, but I would very much appreciate a link back to this page if you copy this table somewhere else. I will keep updating this table as the race continues, and if everyone copies my table, they’ll have to maintain theirs as well. Mine’s not going anywhere, just link to it.

Beta Browsers
Browser	Version	Operating System	Acid 3 Score
Safari	WebKit Nightly (r31388)	Mac OS X 10.5.2	100% (0.44s)
Opera	9.0 Beta (build 636) “WinGogi”	Windows Vista 32-bit	100% (1.31s)
Opera	9.50 Beta (build 9864)	Windows XP Service Pack 2	79%
Camino	2.0a1pre nightly (2008031801)	Mac OS X 10.5.2	71%
Firefox	3.0b5pre nightly (2008031804)	Mac OS X 10.5.2	71%
Seamonkey	2.0a1pre nightly (2008031801)	Mac OS X 10.5.2	71%
Flock	1.3pre (2008031604)	Mac OS X 10.5.2	70%
Firefox	3.0b4 (2008030317)	Mac OS X 10.5.2	68%
Firefox	3.0b4 (2008030714)	Windows XP Service Pack 2	68%
Firefox	3.0b4 (2008030714)	Windows Vista (32-bit)	68%
Internet Explorer	8.0.6001.17184 (Beta)	Windows Vista (32-bit)	18%
Internet Explorer	8.0.6001.17184 (Beta)	Windows XP Service Pack 2	18%

Released Browsers
Browser	Version	Operating System	Acid 3 Score
Safari	3.1 (5525.13) *	Mac OS X 10.5.2	75%
Safari	3.1 (525.13) *	Windows Vista (32-bit)	75%
Konqueror	4.0.3	Linux	65%
Epiphany	2.22	Ubuntu 8.04 (beta)	59%
Camino	1.5.5	Mac OS X 10.5.2	52%
Firefox	2.0.0.12 (20080201)	Mac OS X 10.5.2	52%
Firefox	2.0.0.12 (20080201)	Windows Vista (32-bit)	52%
Firefox	2.0.0.12 (20080201)	Windows XP Service Pack 2	52%
Flock	1.1 (20080304)	Mac OS X 10.5.2	52%
SeaMonkey	1.1.8 (20080201)	Mac OS X 10.5.2	52%
Firefox	2.0.0.12 (20080201)	CentOS 5	51%
Firefox	2.0.0.12 (20080201)	Windows Vista (64-bit)	51%
Epiphany	2.20.3	Gentoo Linux	51%
Konqueror	3.5.9	Gentoo Linux	51%
Firefox	1.5.0.12 (20070508)	Windows XP Service Pack 2	50%
Opera	9.26	Mac OS X 10.5.2	46%
Opera	9.26	Windows Vista (32-bit)	46%
Safari	3.0.4 (5523.15) *	Mac OS X 10.5.2	39%
Safari	3.0.4 (523.15) *	Windows XP Service Pack 2	39%
Safari	3.0.4 (523.15) *	Windows Vista (32-bit)	39%
Mobile Safari	3.0 (420.1)	iPhone	39%
Internet Explorer	5.50.4807.2300 (SP2)	Windows XP Service Pack 2 (Multiple IE)	14%
Internet Explorer	5.50.4134.0600	Windows ME	14%
Internet Explorer	5.50.4807.2300 (SP2)	Windows 2000 Service Pack 4	13%
Internet Explorer	7.0.5730.13	Windows XP Service Pack 2	12%
Internet Explorer	7.0.6000.16609	Windows Vista (32-bit)	12%
Internet Explorer	6.0	Windows XP Service Pack 2	12%
Internet Explorer	6.0	Windows 2000 Service Pack 4	11%
* I don’t know whether Apple meant to put 5xx or 5xxx. I highly doubt that they intended to use such an inconsistent versioning scheme, but I’m going to cite here whatever they put on the About window. Thanks to Mark Rowe from Apple for explaining this: “The leading digit of the build number signifies the platform version. 45xx.y.z is Tiger (10.4), 55xx.y.z is Leopard (10.5), and 5xx.y.z is Windows.”

I guess it really comes as no surprise that Internet Explorer is currently in last place. But really, how did Internet Explorer 7 and 6 do worse than v5.5?

Note: If you want to see another browser in this listing, let me know and I will try my best to test and add it here. Please include the browser’s name, a screenshot of the result and about window.

I’ve been working on a new benchmark for the past several weeks (would have finished it much sooner too, had it not been for college). I think the results are very much worth sharing.

The first thing to know is that the source code to the new benchmark (I’ve named it CheckMark), is one of the CrissCross library’s example programs and is available in the CrissCross source repository. It will be more easily accessible when it goes into the CrissCross v0.7.0 release (probably in a few weeks).

CheckMark has several different checksum/hashing algorithms in it: Adler-32, CRC32, MD4, MD5, SHA-1, SHA-256, SHA-512, and Tiger. Tiger and SHA-512 were written to be especially fast on 64-bit machines (they use 64-bit word sizes), and the rest are optimized for 32-bit use.

The benchmarks I’ve done are fairly simple to do. First, for consistency, it’s best to run in an environment as close to the one I used as possible. I run the Linux 2.6.24 kernel and use GCC 4.1.2. To compile and run CheckMark, you need to first get a copy of the source code using Subversion, and then once the source is downloaded, do ‘make check’ in the main folder. If your machine, compiler, and CPU pass the CrissCross test suite tests, then you can go ahead and run ‘make example’. And then to run CheckMark (assuming the build goes fine), simply ‘examples/CheckMark/checkmark’. CheckMark generates 100 1024-byte strings and times how long it takes to hash all of them 500 times. The output of the program for each hash algorithm is the number of hashes calculated per second. Since each string is 1024 bytes long though, the hashes per second number is equivalent to the number of kilobytes hashed per second.

The machines I tested with CheckMark used the following processors in 32-bit mode: ARM9 (specifically, the one used in my Nintendo DS), Intel Core Duo, Intel Core 2 Duo, Intel Xeon (with a Pentium 4 core, a.k.a. NetBurst), and a PowerPC G4. I also tested the Intel Core 2 Duo in 64-bit mode to show the speed difference in 32 vs 64-bit modes.

My results are pretty intriguing, and they can be found here. Please note that in the graphs, a smaller bar is better, because the processor is accomplishing more work per clock cycle. Also note that since the graphs aren’t based on time but instead based on work per clock cycle, the clock speed of the processors doesn’t affect the graphs. In fact, the clock speed is taken into account when calculating the number of clock cycles per hash. This shows more of the raw performance of the processor and how efficient it truly is. This just goes to show yet again that clock speed is not everything!

Okay then, how are we to read these graphs? What do these results mean? Well, the most obvious thing I see when looking at the graphs is that you probably shouldn’t bother with SHA-512 or Tiger hashes unless you’re running on a 64-bit processor running in 64-bit mode. It’s also plain to see that the Core 2’s 64-bit mode very very easily outperforms its 32-bit mode when doing 64-bit math. This makes perfect sense, as the SHA-512 and Tiger algorithms make heavy use of 64-bit math. In 32-bit mode, a lot of extra work has to be done to complete a single 64-bit math operation.

Another observation I could make about these graphs is that the PowerPC just isn’t doing well at any of them, except SHA-1, where it appears to do well because the NetBurst core takes a huge performance hit. I’m fairly certain that the NetBurst’s speed issues here are due to the fact that the NetBurst core lacks a barrel shifter, the component which makes shift and rotate operations blindingly fast. There are a large number of shifts and rotates that occur in the SHA-1 algorithm, so the performance hit is understandable. Not surprisingly, the barrel shifter has returned in the Core and Core 2 architectures.

I was very impressed with how efficient the ARM9 processor was at doing these hashing algorithms. It was accomplishing so much more work per clock, even though it is a RISC processor, like the PowerPC. The only case where the ARM9 does very badly is when 64-bit math is involved.

I would love to hear your thoughts about this, as well as your own results, if you’d like me to add them to the list. Email me directly at steven@uplinklabs.net and let me know what’s on your mind!

Okay, sorry about the delay on posting this one. I had some other priorities to take care of first.

Last time, I explained why antivirus is basically a sham. This week, I’m covering firewalls.

Firewalls are only a half myth, really. Generally, firewalls do as they should: block either incoming or outgoing connections (or both). But in order for people’s internet connections to be functional, firewalls have to have exceptions. Certain connections must be allowed to pass through the firewall, or the network is essentially rendered useless.

Problem #1: In the case of end-users, firewalls can end up causing confusing symptoms (for instance, Windows file sharing failing to work properly because of a denied connection). The typical user probably wouldn’t know why file sharing refused to work, and would eventually get frustrated and either give up on the task at hand or resort to an inappropriate means of sending files (such as email). An informed user would probably add an exception for that set of ports and allow Windows file sharing to function.

Problem #2: Unfortunately, exceptions are the second issue. Firewalls are blanket security that we can punch holes in when we need to. Exceptions mean that we’re selectively exposing ports that we probably shouldn’t for security reasons. Further, the Windows file sharing ports are the most exploited for security holes of any ports on Windows. Blaster, Sasser, Bagle, MyDoom, NetSky, and Sircam all used Windows file sharing ports for infection.

Problem #3: Open ports are really not the problem. The problem is poorly written software. Windows file sharing was exploited so many times because it was truly that badly written. So many security considerations were ignored. To Microsoft’s credit, they are now developing software in such a way that most buffer overflows are avoided. They’ve basically made their developers use their secure C functions (sprintf_s, strcpy_s, etc), lest they get a compiler error. I’ve seen this myself when visiting Microsoft.

But now we’re at the root of the problem: we’re covering up programmer errors by making those errors publicly inaccessible while reducing functionality. What really should be done? Programmers should thoroughly test their programs, and potentially even implement their own secure C functions (for non-Windows platforms). But unfortunately, we’re stuck with firewalls because programmers don’t write secure code.

I would love to hear any opinion you may have about this blog. Email me directly at steven@uplinklabs.net and let me know what’s on your mind!

Check it out. Some PhDs are slamming Java. As I said in 2006, Java’s far too much theory, and not enough practical low-level knowledge.

I’m tired of over-bloated applications. They really annoy me. I used to love Ahead Nero Burning ROM. But now, they’ve bloated Nero into a whole suite of applications which have functionality I don’t care about or get via other means. So I’ve started searching for better (i.e. more compact) CD/DVD burning software. Nero v8.2.8.0 is a 183MB download. Way too much. On Mac OS X, I use Disco for burning most things, and that’s only a 1.43MB download. Knowing this, I ask myself, “Why waste hundreds of times as much space on Windows?”

I figured the best place to search for new software that did what I want was to go to Download.com, find the CD/DVD burning category, and sort by user votes. I didn’t sort by number of downloads because the size of the userbase of an application doesn’t necessarily measure it’s greatness. At the top of the list was “Oront Burning Kit 2″. With an 8.83MB download size, Oront Burning Kit 2 looked tempting. It only costs $35 and does everything I need. CDs, DVD’s, DVD-DL’s, bootable discs, mp3 discs, audio discs, data discs… everything. I haven’t used it for the full 10 day trial period yet, but I’ve burned one DVD with it, and it worked beautifully. So far, I am really excited about Oront Burning Kit 2!

There isn’t such a thing as antivirus software, at least in the most ideal sense of the term. No software can detect malicious code without foreknowledge of specific patterns inside the program to search for. To detect new viruses before they wreak havoc on your system, you’d have to either monitor everything yourself, manually, or you’d have to have software with artificial intelligence. This doesn’t exist today. What we have today is not antivirus. What we have is essentially a sham. The top antivirus manufacturers, except for AVG, currently use tactics I despise. They’ve essentially made antivirus into a subscription-based service. Every six months, antivirus software will ask for more money if you want to continue getting sub-par service. They’re not looking out for their users’ best interests, they’re trying to rake in the cash.

How is the service sub-par? Antivirus detects only known viruses. What’s worse, if the virus you happen to get on your system is aware of your antivirus software, it’s possible for it to bypass or even disable it. For example, in 2001, it was widely reported that Norton Antivirus had a flaw which made it possible to change a single registry entry and disable the antivirus. So really, what good is antivirus software if a virus can simply hit the ‘off’ switch?

Even further, some antivirus software is incompetent. Much more recently than the aforementioned security hole in Norton Antivirus is the news that some new laptops pre-installed with Home Premium were infected by a 13 year old virus. Worse, the preinstalled antivirus software could not remove the virus. The fortunate thing here is that the virus itself was basically just a proof-of-concept and had no payload, so the damage was quite light.

A recent article on The Register brought to light a study by a German magazine in which they tested various antivirus programs’ effectiveness in detecting new variants of known threats. Antivirus companies make heuristics sound great and powerful, but the results of the tests were less than encouraging. 20-30% is pathetic. Why are people continuing to pay for such ineffective software?

An even more annoying flaw is when antivirus software yields a false positive when checking a piece of software for viruses. A very publicized incident of this kind of failure was most recently posted on The Register about how AVG thinks Adobe Reader’s installer is a virus.

Some have suggested that a solution for these sorts of problems lies in having independent testing firms to validate antivirus software’s capabilities. I don’t believe this to be the solution, because the security model itself doesn’t make sense and I believe the whole concept of antivirus needs to be redesigned. I also don’t believe blanket security is good security, largely because most blanket security solutions yield more problems than they solve. There are exceptions to this rule of thumb, but for the most part, blanket security is worthless.

Another solution that people have suggested is the concept of “intrusion detection”. Intrusion detection is the concept of monitoring programs for suspicious activity, such as deleting files, modifying registry entries, and so forth. There are intrusion detection programs available, like the OSFirewall feature in ZoneAlarm Security Suite. Intrusion detection systems will be very noisy about pretty much any suspicious behaviour, but such behaviour can be exhibited by perfectly normal programs as well. Programs add and delete files all the time, but this is also how viruses propagate. Programs modify the registry all the time, but this is how viruses inject themselves to run at startup. The intrusion detection model is far too noisy and picky about events taking place on a machine.

So what can be done about this difficult issue? How can viruses be effectively eradicated? Unfortunately, there is very little that can be done right now. Until someone writes a real antivirus program, you are essentially forced into using one of these pseudo-antivirus products on the market. Aside from being vigilant about what you download and run, you should always be sure to keep your antivirus software up to date. I recommend AVG to most people because it’s free. My own solution to the threat isn’t very useful to the average person, so I rarely recommend it. I’ll be detailing my own solutions to primary security concerns in a few weeks. Next week, I’m going to be covering firewalls, the next great security myth.

I will continue this article in part two next week.

I would love to hear about your own virus problems and solutions as well as any opinion you may have about this blog. Email me directly at steven@uplinklabs.net and let me know what’s on your mind!