Establishing secure connection

So we wrote a perl script that printed out a bunch of platitudes like these, while printing out an ASCII "progress bar." It had some randomly determined sleep() calls in there to make it seem like it was doing something.

  Optimizing priority queues...
  Recalculating scheduler lookup tables...
  Terminating unused system processes...
  Recovering memory leaks...
  Flushing network buffers...

We called it "speed" and deployed it to the app server. Some folks started getting into the habit of running it every morning and swore by it.

edit: I've seen this on too many financial apps to think it's an isolated incident. It's clearly a "thing" in financial apps (TurboTax.com does it all the time; I see it on my Bank app, lots of mobile apps, etc.)

There's gotta be a reason, even if it's wrong.

If I had to guess, there's a login page. When you submit your login, this page pops up and displays while the login is processed.

source:

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

  <html>

  <head>

    <title>Loading....</title>

  </head>

  <body>

    <p align="center">

      <img src="https://a248.e.akamai.net/6/248/3583/000/wellsoffice.wellsfargo.com/ceoportal/DocumentumRepository/content/images/signon/messaging.gif" width="300" height="30" border="0" alt="Loading Status" /><br />

      <img src="https://a248.e.akamai.net/6/248/3583/000/wellsoffice.wellsfargo.com/ceoportal/DocumentumRepository/content/images/signon/statusbar.gif" width="300" height="30" border="0" alt="Loading Status Bar" />

    </p>

    <script type="text/javascript">

      var selfClose = function() {

        self.close();

      };

      window.onload = function() {

        setTimeout(selfClose, 10000);

      };

      window.onblur = function() {

        selfClose();

      };

    </script>

  </body>

  </html>

What would be bad is if this page would accept a parameter to redirect you to somewhere, but it appears it doesn't do that -- it just closes itself. Presumably this page appears in an overlay that then closes itself.

One example of this is shown in a usability study by the Baymard Institute on top ecommerce checkout processes [1]. The goal of the study was to determine best practices for checkout usability by testing the top 15 ecommerce sites. One of the more fascinating finds they made was that during the checkout process, users perceived certain fields as being more secure than others. Even though the fields were all part of the same form and on the same page, users still believed fields with a little lock icon were more secure than the rest of the fields! It didn't matter if the entire page was encrypted. Users would abandon the checkout process because the credit card fields didn't "feel secure" compared to the rest of the page.

To most of us, this looks like a frivolous feature suggested by a "UX monkey" (as one commenter put it) but don't underestimate the power of making users feel safe. For all we know, this stupid gif could have cut support calls 20%.

[1] http://baymard.com/checkout-usability

Then someone else from within your company must repeat a similar process to approve your action. So you always need at least two people within your company to perform any action.

Typically the CEO portal is used for wire transfers where security is pretty damn important--once the money is gone--its really, really gone.

It's the "Save & Exit" button TurboTax has. I'm sure that they are saving all info as it is entered, but users of QuickBooks, Excel, etc., I'm sure are used to having to save their data manually then exit.

I think all the guffawing at this progress bar is a little overblown. If a question or concern comes up in user testing multiple times -- "How do I know my connection is secure?" -- then why not put something in there that makes the user feel safer? What's the problem with that? Sure maybe it's a little overblown graphically but, c'mon, when you're a bank you need your customers to feel secure, in addition to actually being secure.

https://a248.e.akamai.net/6/248/3583/000/wellsoffice.wellsfa... https://a248.e.akamai.net/6/248/3583/000/wellsoffice.wellsfa...

:-)

But as a Wells Fargo customer, I've never seen it while using their website, and I use the site to check my accounts and transfer money between accounts once or twice a week.

But this is just a silly static image. What if the server takes longer than the image to load?

If the issue was transient, like a dropped connection to the database or memcached or some obscure deadlock, the "automatic" fixes worked as expected from the user's perspective. We, of course, still got the full error report to diagnose the issue.

I even have a few gems in our user feedback system where the users outright praise the "automatic error fixer" and they wish every website/app had a tool like ours.

"The salesman had been selling hydrochloric acid, sometimes known as muriatic acid. The industrial grade usually had a green tint caused by contamination with iron. The company that the salesman worked for improved its equipment at considerable expense and proudly began putting out water-white muriatic acid. The salesman immediately began getting complaints from customers who did not want that weak white stuff. They insisted that they wanted that strong green stuff that they used to get. So, for those customers, the salesman arranged to have a small nail dissolved in each jug shipped to them. Result: happiness."

http://news.ycombinator.com/item?id=2007385 (807 days ago)

And the corresponding HN discussion that followed:

(Apple's iOS is "deceptively fast") http://news.ycombinator.com/item?id=4047032

In this case, we have security instead of speed. That's not to say it isn't secure anyway.

Fun aside this portal uses two factor authentication with RSA tokens (that were promptly replaced after RSA token vulnerability was found).

Sounds about right.