"Abort, Retry, Ignore?" -- and Die

All engineering failures -- and disasters -- have a critical human element.  This observation applies across the spectrum: the Challenger shuttle explosion, the BP Macondo well blowout, the aircrash that wiped out Poland's government.

That element: someone in authority overrode the safety checks and ignored advice of those who knew the risks.  Launch directors pushed the launch schedule, BP execs told the drilling engineers to proceed, an air force general told the pilot to land, all despite warnings from rocket engineers, the rig lead, and the pilot and ground control.

Why does this happen?   Because we train people that it's okay to go ahead anyway or offer an option to continue despite a system interlock or warning.


On a microscale, consider system security measures for privacy and identity theft prevention.  How often have users ignored warnings like the one at right:

This warning appears when Outlook 2007 connects to an email server over an encrypted channel.  The purpose of the secure connection is to prevent a bad guy from stealing email identity (login/password) and ensure mail privacy.  But there's no clue about that in this warning, and the temptation is to blithely click through in order to read mail.

Here's another example.  In this case, the browser fails to validate Register.com's security certificate.  Multiple reasons could lead to this warning: the browser doesn't know about Register.com's certificate authority or the certificate is self-signed.

In both cases, it doesn't matter.  The user is given the option to "go ahead anyhow" and since most people deem reading email as urgent-but-low-risk, they click through to do the task that's uppermost in mind.

Similar messages appear for expired certificates.  Certificates must be renewed periodically, and many business, particularly smaller businesses, forget this administrative chore.  After all, the customers can still get in okay, right?

It makes no difference if the URL location bar turns "green" or the little security lock icon appears locked when security is validated.  The user has already clicked through regardless.  The security interlock has been ignored.

Once habituated to clicking through for email, ignoring warnings for banking, e-commerce, healthcare, government, and other security-required applications becomes second nature.  The "go-ahead, make my day" feature has trained users it's okay and nothing bad will happen.

Until something does.

The Real Problem

Several things are at work.  The total system (browser, application, website, certificate authority) offers a way to go ahead instead of enforcing the lockout and requiring the user to go to lengths to verify the security of the situation. Second, the reasons for the warning are obscure as it's assumed the user understands how certificates work. The onus is on the user to evaluate the risk without complete information or understanding the underlying causes.  Last, the user is likely under time pressure or other constraint to make a decision quickly and "just get on with it".

In short, the overall design permits a dangerous action by someone who is uninformed about the root problem and who lacks the training and patience needed to understand the matter and judge risks.

The built-in assumption is that value and convenience override all. The lesson drawn and reinforced: it's okay to ignore warnings because likely nothing will happen. So thus, a security blow-out.

Fixing the Design

This one is simple: make the security interlock positive and hard.  Never make it simple for someone to obviate.  Will it inconvenience people?  Yes.  Will they take the time to fix it by calling and complaining?  Maybe.  Will they leave the application, website, or abandon their task?  Likely, but that puts the onus on certificate owners and application and website managers to keep their stuff up to date and working.

Make applications and sites work securely from any URL in the domain.   Certificates are inexpensive and serve to advertise and secure the brand.  There's no excuse for Amazon.com (for example) to cheap-out on a cert for the domain amazon.com.   Even if this domain isn't the final target (www.amazon.com), buy a cert to avoid seeing this screen, then bounce the customer from the former to the latter.

Applications must offer an alternate path in the event of a lock-out.  The alternate path must inform the user what to do and whom to contact to correct the situation.  The information must be meaningful, helpful, and lead to a positive resolution of the problem, e.g., call this toll-free number to talk to our security division of customer service.  The goal is to correct the defect, not override it.

Last, inform the user about what's going on, what the risks are, and the "what to do next" alternate path. The generic security warning screen in Firefox 3.6 is much better than Internet Explorer 8 (above).  It cannot solve the problem with Amazon's website, but at least it explains why the problem occurred and offers a reasonable workaround, in this case, the URL of the correct site.

References

• Web users ignoring security certificate warnings 
• Benign security warnings train users to ignore them
• BP Representative Overruled Drillers
• Was Polish Pilot Under Pressure to Land?
• How warning signs were ignored before disaster shuttle's launch

The first two references discuss the impact of and cite the same Carnegie Mellon University study, "Crying Wolf: An Empirical Study of SSL Warning Effectiveness".


Addendum

28 June 2010 - Sean Kerner at eSecurity Planet reports a Qualys study suggesting that of 92 million active domains, 23 million were running SSL. Of those, 22 million had invalid certificates. See "SSL Certificates in Use Today Aren't All Valid".

---

Login AWOL

How do I log-in? Web sites that demand logins often make it hard to do so. Many make it hard to determine whether the user is logging in once inside the site. Why?

The New York Times gets it right. LOGIN and user session information appears clearly on every page. As a bonus features, a social tool drops down to show who's following you and what other Times readers recommend.

The Wall Street Journal used to be confusing and The Washington Post gets it wrong. It's in tiny type at the Post; LOGIN must be hunted down on the page. The WSJ has finally moved it from mid page somewhere on the right and it no longer disappears completely when the user navigates away from pay-walled pages.

Facebook gets it really right; it's the foundation of the whole business, of course.

The IEEE universe of websites is improving. To be sure, the IEEE relies on volunteers to create and maintain its collection of sites and services. Moving among societies and journals within the IEEE context used to be a LOGIN safari. A universal header and navigation control is helping.


Where is ACM's LOGIN? Buried somewhere under a tab. For a leader in Human Computer Interactions, hiding LOGIN is unfriendly to say the least and belies the mission to improve computing's utility.

Worse LOGIN encumbrances exist.

Some companies treat their customer's logins with contempt. For over a decade I held a login and profile at The Los Angeles Times site. In April 2010 and with minimal warning to its "valued customers", the paper ditched its logins in favor of those established on social networking sites, a cross-marketing play.

In an instant, The Times not only made it harder to log in but also severed the relationship between my identity and my editorial comments, news letters, and other onsite material. The site offered no opportunity to recover. Everything apparently needed to be re-entered and reconnected to LOGINs I may or may not wish to associate with my Times subscription. The frustration is best expressed by Search Engine Land's Danny Sullivan. He simply unsubscribed.


The Real Problem

LOGIN offers little value for many sites. It's a step to capturing demographic info which is usually sold and resold to marketers in aggregate. A login's approximate value: $0.37. Less than a postage stamp.

For the end-user or customer, however, LOGIN is a welcoming step. It signifies a willingness to belong and support a service or site, to join the community and identify with it. Signing up implies a social contract: I tell you about me and entrust you with that knowledge, you treat me like a friend and keep my info in reasonable confidence. No one likes a gossip.

LOGIN is a missed opportunity. Web 2.0 social sites and smart(er) vendor sites intertwine a welcoming LOGIN into the fabric of their information. It's not always about extracting maximum sales from a customer, but maximum value. A happy LOGIN tells three other LOGINs how to join; an unhappy LOGIN tells 20 others why they should keep away.

Happily, LOGIN registrations are becoming more streamlined. Instead of demanding names, addresses, phone numbers, birth dates (!), and other details marketers covet, a simple name/email/password triplet has become enough. Customers may volunteer additional info by optionally completing a profile later. People share more information as their trust in friendships and involvement grow.


Fixing the Design

If a website offers no premium for logging in, don't. Don't create user accounts. Don't demand identification or other personal information at all. Use a tracking service instead. Chances are the service is much, much better at it.

To create a customer relationship, optionally offer a login. Don't make it a requirement to complete transactions or find free information. I have abandoned many, many shopping carts because their sites forced me to register before checking out. No one has ever registered at McDonald's in order to get lunch. I have money and am willing to pay, what more is wanted? Pointless registration retards transactions.

Make it easy to log in and know I'm logged in. Don't hide LOGIN. Put it on every page if I'm not logged in. Replace the login box or widget with my name when I am logged in. And put the LOGOUT right next to my name so I know I can close my session, especially if I'm using a public or shared system.

Keep all the LOGIN/LOGOUT/User features in the same, visually-stable location on every page. Hunting for this information on a new page or section on the site is time consuming and annoying.

Last, treat login identities as what they represent: a social contract. They represent people and their good will. Friends never betray friends and a lifetime of trust can evaporate in an instant.


References

• The Associate for Computing Machinery
• The Institute for Electronics and Electrical Engineers
• The Los Angeles Times
• The New York Times
• The Wall Street Journal
• The Washington Post

---

Hurry up and Outsource

The program director handed me a thick document. "Could you guys look at this contract and give us a thumbs-up?"

"What's it for?"

"We're going with another service desk vendor. We need to sign this contract Friday."

It was Tuesday afternoon. "All my people are busy on other projects. Why the rush now?"

"We need it by Friday to make the deadline." (Whose?) "Just look at the technical stuff."

"We'll do what we can."

Wednesday, after some Quality Coffee and Fireside Time with his 120-plus pages, I returned it to the still-anxious director.

Bear bad news first. "Won't work. Don't sign Friday."

"What? Why? We've been working this out for more than two months."

"Look, sorry." In addition to several glaring contractual oversights (fodder for another post), the contract omitted a critical data requirement. The vendor's system had no way to know who was calling the help desk. Responsibility for the data exchange had been left out.

We went over the other details together. Not a good day, but not terrible. At least we caught it.


The Real Problem

Getting lost in requirement and design details almost always works to an outsourcing vendor's advantage. Design elements not explicitly spelled out in the contract become change orders.

Even at an agreed-to rate change orders cost a premium. They stretch out the contract because the customer has already bought in and fears losing the investment. They're the icing on the cake.

Software or system change orders are best. Now the vendor has an reason to start an engineering development project. New rounds of consultation with the system specialists, software engineers, architects, programming teams, project managers, and others begin, all billable. Even better is a change order so big the vendor brings in third-parties to fulfill the request and passes through their costs plus the vendors overhead. It's a rent.

Change orders also drive the in-house staff crazy. Wasn't the vendor supposed to take care of this problem? Why are we doing our work and their work too? Wasn't this supposed to save money?

Meanwhile, if the project is in implementation phase, good reason exists to miss the start-up deadline and press for the "on-time delivery" performance bonus. After all, the customer ordered the change; it isn't the vendor's glitch that made the project late.

The process design must be as complete as possible before contracting. It's especially hard when outsourcing services because the service boundaries may be loosely defined. The services drive the data and reporting requirements. Get these right before thinking about the details of, say, file transfer mechanisms.


Fixing the Design

Separate the contract into at least two pieces: legal boiler plate, and specifications, requirements, and design components. The boilerplate should reference the other document(s) as part of the binding contract.

Put the business and technical people to work on the design specs and the legal people to work on the boilerplate. Even if the final contract must be a single, unified document, the right folks will be looking at the right pieces instead of getting distracted by irrelevant work.

Go over the processes and hand-offs to find what information goes to whom, and who calls when. If it's within the team's skill set, I strongly recommend making a high-level UML Sequence Diagram to show these hand-offs. Flow charts can quickly become confusing and they obscure responsibilities.

Be sure the contract indicates who "owns" what pieces, of course. But also specify acceptance criteria on both sides, if possible.


The service desk project delayed three weeks until a new contract with the necessary changes went through.


References

• UML 2 Sequence Diagram

---