Quantum announced that they think 2006 will finally be a good year to market security for tape backups. They just announced that they will be ready in the first quarter of 2006 to provide an authentication (locking) mechanism tapes:

Quantum’s DLTSage Tape Security is a firmware feature designed into its newest DLT tape drives that uses an electronic key to prevent or allow reading and writing of data on to a tape cartridge.

Sounds interesting. The two big hurdles to encryption on tape have been how to handle key management and the performance hit. With key management integrated first, Quantum still has to generate some buzz about performance. They mentioned it briefly in their DLTSage announcement, but it sounds like they are still working on what to do with the technology in an appliance they acquired:

The DataFort appliance provides wire-speed, transparent encryption and access controls for disk and tape storage systems, delivering best-in-class security, performance and key management for heterogeneous storage environments. In addition to the joint sales and marketing efforts with Decru, Quantum also plans to offer tightly integrated encryption and security management capabilities within its product line.

Quantum could be hinting that their encryption appliances will give way to a more integrated solution, which sounds like a reasonable and well-worn approach to enhancing big company legacy products with innovation via acquisitions. If the integration is successful I expect we will find ourselves without any good reason not to encrypt at the block-level, especially on recovery systems. Until then, it seems we must continue file-level encryption prior to backup.

So, is a lock on a tape worth the hassle? It does not comply with breach-notification laws and yet introduces risk of lost keys, so there’s no real ROI there, but it does pre-stage the backup processes with tighter authentication. And that may be worthwhile if you can ensure that time spent on key management now will help reduce the cost of encryption down the road (when performance is a truly dead issue).

Donohue and Levitt are somewhat famous for their bold claim, published in the May 2001 edition of the Quarterly Journal of Economics, that legalized abortion has reduced crime.

The Economist just put forward an amusing update that discusses a Federal Reserve Bank of Boston working paper and counter-claim that is based on a re-test of the data and analysis of the computer code used by Donohue and Levitt:

Messrs Foote and Goetz have inspected the authors’ computer code and found the controls missing. In other words, Messrs Donohue and Levitt did not run the test they thought they had—an “inadvertent but serious computer programming errorâ€?, according to Messrs Foote and Goetz

Fixing that error reduces the effect of abortion on arrests by about half, using the original data, and two-thirds using updated numbers. But there is more. In their flawed test, Messrs Donohue and Levitt seek to explain arrest totals (eg, the 465 Alabamans of 18 years of age arrested for violent crime in 1989), not arrest rates per head (ie, 6.6 arrests per 100,000). This is unsatisfactory, because a smaller cohort will obviously commit fewer crimes in total. Messrs Foote and Goetz, by contrast, look at arrest rates, using passable population estimates based on data from the Census Bureau, and discover that the impact of abortion on arrest rates disappears entirely.

I look forward to the question of this programming “error” being addressed by Donohue and Levitt. It does not seem to refute the premise of their conclusion outright as much as question the methodology and provide an opportunity to fix a control and re-run the tests themselves.

The big question, of course, is still whether there are controls that have a direct relationship to reducing crime and at what cost.

On-Track has released their annual report on the top ten data disasters. It is a serious business, and OnTrack has built quite a reputation for saving the day(ta):

10. PhD Almost an F – A PhD candidate lost his entire dissertation when a bad power supply suddenly zapped his computer and damaged the USB Flash drive that stored the document. Had the data not been recovered, the student would not have graduated.

He must have been in a state of shock — “Teacher, the electricity ate my homework”.

4. Drilling for Data – During a multi-drive RAID recovery, engineers discovered one drive belonging in the set was missing. The customer found the missing drive in a dumpster, but in compliance with company policy for disposing of old drives, it had a hole drilled through it.

Can we please see the top tep without the remarkable recoveries included (just the failures)? That would be more interesting, I think. Or, as the infamous WWII story goes, if you are going to better-protect your pilots you should review planes that were shot down rather than just the ones that returned.

Don Norman, former VP of Apple’s Advanced Technology Group, posted a comment on TedBlog about a common failure of Apple designs:

But now let me tell you my pet peeve: the on-off switch of both the regular iPods and the Shuffle. Historically, one thing Apple has always gotten wrong – on all products, big and small — is the power switch (I even wrote a book chapter about this once). The iPod on-off is a mystery to behold, a mystery to explain to others. The Shuffle is even worse. You have to slide a very-difficult-to-slide slider down some unknown amount. It has two settings, but no marking to let you know where you are. Actually, it has markings but they have zero correspondence to the switch setting. You know, this is NOT a tradeoff. Having a little mark on the sliding part and corresponding labeled terms on the fixed case would be trivial to do. Make usage smoother and easier. Cost no money. Bah.

Why is the slider so hard to slide? Their Industrial Designers seem not to have heard of friction — the fingers slip over the nice smooth surface, while the switch remains stationary. Finally when I finally squeeze really hard, the slider does move, but too far, to the wrong position. And those blinking lights. Secret codes that mean who-knows-what. It sometimes takes me 5 minutes to get my Shuffle to start playing, me continually sliding the switch up and down, pushing various buttons, watching lights go on, blink on, flash, turn various colors. All meaningless.

Just the other day I was reviewing racks of servers with bright warning lights. “What does that indicate?” I asked the admin responsible to see if they could decipher the code. Unfortunately, I was told something similar to what Don might have guessed, “no idea, but they seem to come and go.”

All the way from the personal mp3 player to the datacenter, the sole LED has become a cornerstone of messaging and yet no one seems to be very worried about learning how to interpret its meaning. The old-school hex number codes were one thing, but it seems like an amber or green light blinking erratically is almost guaranteed to be ignored.

To be fair, Don could have mentioned that Apple does provide an iPod shuffle reference card to break the codes.

I like the Check battery code: if you do not see a light, there is no charge. Ah, yes, and if your shuffle is wet, it must be raining.