« May 2005 | Main | October 2005 »

June 26, 2005

Worth Their Weight In Silence

After a few phone conversations with Crutchfield, they shipped the Bose headphones (from Virginia, by the way) which Stuart & I had ordered on Monday, June 20th. They arrived at Guru Labs offices on Thursday. However, as I was in Austin, Texas at the time, I did not pick up my pair until Friday evening on the way home from the airport.

I left on my next trip, to Cincinnati, Ohio, the following Sunday, June 26th. It was a direct flight and I was upgraded to "First Class" (it's domestic so it's really Business Class, but we do not need to go into that now). This is the first time I have used them "on the road" and I must say that the experience was magnificent.

Both Bryan & Dax have had the Bose Quiet Comfort 2 headphones for nearly two years now. I have had the opportunity to "thy them out" on occasion, in the office. I already knew that I liked the sound, fit and comfort of them. I was also already well aware of the limitations of the noise canceling capabilities. For example, voices come through just fine and many times music will to (though greatly flattened out, I think). They work best at filtering out both white noise and gray noise.

Shortly after takeoff this afternoon, I slipped my new headphones on, plugged the airplane adapter into the on-board sound system, and flipped the switch. A moment later, the noise canceling kicked in. The difference, though noticeable, did not seem too large. As I wanted to watch the in-flight movie, I decided that even the small, perceived difference was still a good improvement.

About an hour later, I was unable to hear what one of the stewardesses was asking me, so I lifted the one side of the headphones off of my right ear and could not believe the difference. It seemed as though the noise of the jet engines rushed in to pound on my eardrum. The difference was nearly deafening. At that moment, I thought to myself, "This is what I had been subjecting my ears to all these years of traveling, and I didn't even realize it was that bad, until now. I will never travel without my Bose Quiet Comfort 2 headphones, again."

They truly are worth every penny I paid.
--
Lamont R. Peterson

Posted by lamontp at 9:33 PM

June 18, 2005

Some "Security" Measures are Just Plain Worthless

On Thursday, June 17th, 2005, Stuart and I placed an order with Crutchfield for two pair (one each) of the Bose Quiet Comfort 2 noise canceling headphones. However, getting Crutchfield to actually ship the order was just a little more difficult than usual for online ordering.

Over the past several years, I have placed many an online order. These have included purchasing RAM & other computer parts for several systems, two Sharp Zaurus handheld computers (PDAs) and other assorted items. As I can not guarantee that someone will be at my house at whatever moment a delivery service pulls up, I always have these orders delivered to my office (as do most of my co-workers). The problem was that Crutchfield had one of their agents phone the bank (who issued the credit card I had used) to verify the phone numbers that I had given them were listed on the account. My office number was not so they were holding the shipment until they could get me to fix it. This was after the bank had already approved the transaction (in fact, the money had been sent out to their merchant account by the time I first contacted the bank about this).

This was the first time I have had difficulty getting a merchant to ship an order.

The process of approving a credit card transaction involves the merchant providing the card processing system information that I submitted. This includes my name and both the billing and (if the merchant chooses to do it) the shipping addresses. If they do not match up or the shipping address is not listed with the bank as an authorized ship-to address on the credit card account, then the merchant will not get an approval for the transaction. Merchants are not permitted to verify phone numbers via the electronic submission methods and are, in fact, not required to even collect any phone numbers.

All entities which issue credit cards (more generally, those who issue "credit instruments") are required to maintain a verification phone line for merchants to use in the event of complications or failures in the normally employed authentication method(s). So, it turns out that Crutchfield as a matter of their own corporate policy will always phone your bank to see if all the phone numbers you provided are on the account. They have to do it this way, since they are not allowed (there is no way to) to submit phone numbers for verification electronically. Since no other merchant with whom I have done business has ever done this, I never bothered to provide the bank with the extra phone numbers. They only had the house number and my wife's old place of work.

After talking to the bank on Friday, I told Crutchfield that they should be able to verify the phone numbers. They called back late Saturday afternoon and told me that they still could not verify the phone numbers. From the next conversation with the bank, I discovered that the new computer system (which had just been put in a week before) used by the merchant verification call center at the bank will only show them the one main phone number and no others. So I phoned Crutchfield and told them the old number that they could not use to get in touch with me, but that would verify just fine.

Crutchfield upgraded the shipping for free to ensure that Stuart and I would have our headphones by the end of the week. They should ship out on Monday.

To summarize the security implications here, Crutchfield has implemented a "security" process as a matter of policy that fails. It's not surprising that it fails, since the credit card processing system was not designed to handle this extra mechanism (in fact, phone numbers are specifically excluded). In this instance, the extra process failed and caused delays in shipping that were grossly exacerbated by their further delays in contacting me regarding the problem.

This incident was a security failure because:

* In the end, they required false information in order to get past their "safeguard".
* It took three (3) days longer.
* It cost them extra money, both in the time wasted by their personnel in conversing with me & the bank and for "making it right" with the customer by upgrading the shipping.
* I would guess that they spent more than their profit margin, resulting in a net loss for the transaction.
* It frustrated the customer, making it less likely that I would do business with them again.
* It damaged the customer's faith in their business.
* It damaged the customer's faith in their security

Posted by lamontp at 6:54 PM

June 10, 2005

Linux Device Drivers Really Are Easy to Write

In the process of updating Guru Labs GL250 Enterprise Linux Administration course, I have learned many new and interesting things. This past week, I updated the kernel compilation lab exercises.

We wanted students to learn the different ways they can build and install additional drivers for the kernel. To accomplish this goal, we needed a driver that could be built & installed as well as applied as a patch to the kernel trees for all the distributions that our course supports. This presents many challenges which were most easily solved by writing a new driver from scratch, which I did.

"Come on, Lamont; why couldn't you have just used some existing driver out there?" The first difficulty is finding an available driver that is neither already included with the "vanilla" kernels, but has not been added to the distribution kernels by either Red Hat or SUSE. Another issue is that we have no way of knowing what hardware will be available in classrooms around the world. Guru Labs courses are taught in over 120 countries worldwide; any driver selected for use in the lab demonstration would have to be workable in so many different classrooms on such varied hardware that it really would be impossible to use any hardware driver.

"OK. But why does it have to support hardware that really exists?" The short answer: it doesn't. However, we do want students to be able to see, from the beginning to the end of the process, that they have successfully installed the new driver. The good news here is that we do not need it to support any hardware, at all.

So, I learned how to write a device driver for the 2.6 Linux kernel. The driver supports a character device that can be read from via a device node. When read, it will output one word per line, at random. The words are from the RFC3092 list, plus a couple of others.

In the lab, students will build this driver as an "External Driver" or, in other words, it will be built outside of the kernel source tree without building the entire kernel, as well. They will also apply a patch to a kernel source tree, which they configure in other ways and build, install & test a custom kernel.

If you want to learn how to write device drivers for the 2.6 Linux kernel, I would highly recommend the book "Linux Device Drivers" (3rd Edition, O'Reilly Press). It is also available online at http://lwn.net/Kernel/LDD3/ in PDF format, one file per chapter. This book is very well written, providing excellent sample code showing many good software engineering practices with good explanations of why things should be done this way or that for almost everything covered. I will be buying a copy of this book, soon.

Now that I know how to build drivers for the 2.6 kernel, I have a couple of projects that I will be able to do. Hardware for which no Linux driver has been available will not remain useless for much longer. Wish me luck.
--
Lamont R. Peterson

Posted by lamontp at 12:34 PM