DIY optimize

Publicize your prohibited applications


For a good part of last Friday, I felt like the Allison family on the Titanic. First class passenger and investment banker Hudson J.C. Allison and wife Bess were traveling with their children, three-year-old Loraine and one-year-old Trevor, and with the children’s nurse, Alice Cleaver. After the collision with the iceberg, Alice took Trevor, and without telling Mr. and Mrs. Allison where they were going, left the stateroom, got into a lifeboat and was later rescued along with Trevor.

What do you think the Allisons did subsequently? Do you think Bess and Loraine accepted a chance to get into a lifeboat? Of course not. Hudson, Bess, and Loriane spent the rest of the time looking in vain for Trevor, unaware that he already was safe. All three of them died when the Titanic sank, and only Hudson’s body was recovered.

How does my situation relate to that of the Allisons? Last week, I was in the Temple University law school library. While there, I wanted to make telephone calls using Skype, the voice over IP service. Several months previously, I had purchased their unlimited calling arrangement. Earlier that day, I successfully used Skype at another location, using my same computer. However, when I tried again, this time in the library, I received from Skype an “out of Skype credit” message. By the way, I had headphones, and wanted only to check my voicemail. Of course I had no intention of talking on the phone in the library.

I tried several times to make a call, each time receiving that same message. I then sent a message to Skype technical support (but to this day haven’t received a response). I also checked the “Help Yourself Center” for Temple University Computer Services, by doing a keyword search for “Skype,” but found no information.

A few minutes later, I saw the director of information technology for the law school, and asked him for information. He told me Skype is unavailable from the Temple network due to security concerns.

I’m sure you would have reacted the way I did, with frustration. That frustration had less to do with the merits of the technical limitation itself than it did with the failure to publicize that limitation. Those two issues, in my view, are completely separate. Whether or not I agreed with the limitation, my lack of knowledge about it caused me (and possibly other people as well), wasted time and effort, similar to the Allison situation.

I understand that security concerns make necessary the explicit restrictions on certain applications, and that security settings may prevent others from running. I also understand the impracticality and impossibility of identifying and publicizing all of them. However, if you’re the security person, or if you have the ear of the security person, ask them to do an “80-20 rule” analysis. Can they determine, of the most common or popular applications, which ones might be affected? Can they determine a way to document this restriction, perhaps via an e-mail note or a knowledge base entry? Regardless of whether the customer agrees with the policy, that customer saves time by knowing the restriction.

By being open about these restrictions, you save time for the customer. Sure, that customer will still be frustrated, but he or she will be even more frustrated by having to waste time before learning the restriction. In addition, both the internal support organization and the vendor support organization save time by receiving fewer repetitive calls.

In short: don’t treat these restrictions like nuclear launch codes and don’t act like Alice Cleaver.

About

Calvin Sun is an attorney who writes about technology and legal issues for TechRepublic.

0 comments