No Going Back | July 14, 2004

I bank with First Direct. They were one of the first "telephone only" banking services in the UK and were amongst the first to adopt internet banking.

I've been pretty happy with their online service despite the fact that - until recently - I've not been able to use Safari to access their site. The one annoying thing is that the banking screen is popped open in a window (sans toolbar) to prevent you from using your back button. If you do attempt to go back - using the keyboard for instance - you get the following message.

Your internet banking session has been closed.

This was because either:

Thank you for using first direct internet banking.

Now the first dozen or so times this happened it really annoyed me. However like a dog that gets electrocuted every time it tries to eat a bone, I eventually learnt not to use my back button on the site. I do sometimes forget, but generally the conditioning has worked.

Now I've always thought not allowing people to use the back button was kind of odd. I've experienced it in other places as well - usually at the end of filling in a multi page form - and the reaction I have goes from the mild annance to extreme frustration. I was never sure if it was a failing of the site designers or if there was actually some deeper reason.

A friend contacted me today about an email he'd received from his online bank Smile, explaining that they were also planning to log people out if they tried to use the back button. Being a developer himself, he contacted them to ask why it was necessary, and this is the answer he got back.

A lot of investigation went into maintaining the functionality of the buttons, however no acceptable, secure way was found to prevent this behaviour without affecting the site's accessibility and compliance with web standards. This is not likely to be changed.

Now I'm not really sure what these security issues are or how addressing them would have impacted on the sites accessibility or compliance with web tandards. If anybody could spread some light on this I'd be grateful as - at the moment - I'm just confused.

Posted at July 14, 2004 9:26 PM

Comments

Jonathan said on July 14, 2004 9:47 PM

I’ve never had a problem using Safari with First Direct. To avoid the pop-up window problem, change the bookmark to https://syhp37.first-direct.com/Independence/ which will take you straight to the login screen.

I think the back button problem is understandable - if it worked it would be possible to enter a page directly via URL, and I’d be worried about using a banking site that allowed you to do this!

I too like First Direct and joined about 12 years ago when it was very “exclusive” and their marketing made a big thing about applicants being “considered” - I’m sure putting “graphic designer” as my application helped! Now they’ll take anyone… ;-)

Rob Reed said on July 14, 2004 10:02 PM

Both examples you mention are financial sites where it is likely that your in an https session.

The default setting in IE is to save encrypted pages to disk. If you are in an internet cafe for example checking your account (I know…, I wouldn’t either), then the next customer could access your personal details by simply using the back button.

Gabe said on July 14, 2004 10:08 PM

I am not terribly familiar with the precise functionality of browsers, but I believe back-button functionality varies. Safari and Mozilla seem to store the previous state so they can reload the page without contacting the server. IE on the other hand reposts the information used to generate the previous page.

If you are completing a transaction over multiple screens then this reposted information may not be valid, and thus the screen would not be valid. With the Safari way you could get back, but the page might still be invalid in the context of a transaction and would have to generate an error.

Obviously using the back should only be a problem in multi-page transactional forms. Even then, the problem can be mostly avoided by using clever architecture to store all their data in a session, allow any of the pages to be submitted in any order, and set the values of the form from the internal data. Completing the transaction still invalidates prior pages, but it is more usable (especially if completing the transaction takes you back to the home page).

However, building web applications like this can be dangerous, because it’s much more difficult to secure a free-form transaction system than a linear one. That’s not to say that it can’t be done securely, but basically you need the scaffolding in place from the beginning to build a system this way. If you try to retrofit it into some of the typical web app gunk I’ve seen you are begging for a security hole or at least some odd bugs.

The whole underlying reason for this is that HTTP is designed as a stateless protocol, while things like bank transactions rely heavily on having some state. Solid engineering can overcome these problems, but it is a discipline very specific to the web, and something that most traditional programmers take for granted. For a seasoned programmer with little web experience disabling the back-button is a very sensible way to prevent mysterious and dangerous bugs, and for something as serious as banking it might not be a bad idea even for experienced webbies.

Joseph Lindsay said on July 14, 2004 10:10 PM

I suspect that it is to prevent double transactions, like submitting a form twice by accident etc. The banks here in New Zealand that I’ve used do it too. However, I have found that if you leave the site you can go back to the last page that you visited and continue withthe same session. The other thing is that their definition of ‘web standards’ is probably an internal one that relates more to security standards than HTML/CSS/accessibility standards

Matthom said on July 14, 2004 10:33 PM

"The other thing is that their definition of ‘web standards’ is probably an internal one that relates more to security standards than HTML/CSS/accessibility standards"

I agree. I’m willing to bet they weren’t referring to the same “Web Standards” that we are. A quick way to check is by viewing the DOCTYPE - is it XHTML 1, or HTML 4…?

My online banking has a similar problem too.. when I go to log in, they dis-allow use of the RETURN key. I have to actually click on the “Log In” button. Painful, but I have no choice but to deal with it…

Ken said on July 14, 2004 10:38 PM

This sort of thing infuriates me as well, I run into it all over the Intranet at my company. My other big annoyance is the use of javascript: instead of providing usable URLS+onclicks, which prevents the use of “Open in new window”. When these two issues are combined (as in my companies support desk system) it’s terrible, you can’t go back and you can’t spawn multiple windows making things increadibly painful to navigate.

Joseph Lindsay: There are much plenty of ways to prevent double-transactions without disabling back. Disabling back is a cop out. Some of the solutions include..
-Disabling the submit button onsubmit
-Using an token on submissions to identify re-submits

Jez said on July 14, 2004 11:16 PM

I may be wrong but surely aren’t those banks just abiding by British law, as it is in their interest to keep your data secure. So if you do happen to perhaps be using a public computer, which in all honesty isnt wise to check bank details, it is so others cannot access your data. But then again at an internet cafe or wi-fi area, any old person with the know how can get your details. Funny old world we live in.

Sarah said on July 15, 2004 12:29 AM

I work at a company that creates online banking systems for the Internet. We recently implemented a crude but necessary functionality where when the customer clicks “log-out” they are given an alert stating that they should close their browser, then, depending on the browser, the window closes.

The idea is to prevent people (esp on public computers) from being able to go back and view their account information. Even though they are “logged out” and they cannot do transactions, they can still view the cached information.

I am not sure how related this is to the First Direct issue, but it seems similar. It could be this or the double posting issue mentioned above.

In my opinion there are better ways to get around both issues without using such crude devices. I know the bank I use allows the back button and when you log out and use the back button it doesn’t show you any information. I’m not a techy so I don’t know how they do that though.

Joseph Lindsay said on July 15, 2004 12:33 AM

Ken, I know it’s a cop-out. However, decisions like that are probably made by technophobic managers, not programmers that know what they are doing.

amanda said on July 15, 2004 11:43 AM

One of the things I hate most about my bank’s online system is the message facility. It’s limited in length to 1000 characters. I don’t know about other people, but I find it quite hard to actually describe a problem with 1000 characters. Of course I’m also limited to the length of the session information when typing as well. I often compose a short message in a text editor before sending it, usually in successive parts, with [part 1 of 4] appended to the message. I’m told that some banks limit messages to 255 characters!

Another irritant with my bank’s system concerns forms. Using firefox I’m unable to click into form fields. Added to that is the problem that sometimes the tab order is less than logical,so I end up tabbing through all the links before being able to input the right info.

Robert Lofhouse said on July 15, 2004 8:49 PM

I just looked at the first direct web site. They appear to have completely sacrificed usability for security. They may as well have just stuck to being a normal bank.

There is absolutely no need to disable the back button. If you’ve logged out then your session will have expired and you will be continually redirected to a login screen - if you’re dealing with a bank that understands there has to be a compromise between usability and security.

Don’t mind me, i’m in a mood. Companies like that who “claim” to have researched all the methods really annoy me. An amateur programmer could build a web application which combines reasonable usability with reasonable security.

I understand their reason for such a high level of security, but everyone has become so paranoid these days. If a cracker really wants your information bad enough, no security system in the world will stop him.

Jeff Minard said on July 15, 2004 9:58 PM

I’ve got to agree with a good number of the other statements - this is a major cop out.

Between simple things like cookies to detect login state, or session variables on the server side you could easily prevent double transactions. (Which is probably the bank’s largest concern.)

In addition, it is possible to add header content to a page that will tell it to expire it two seconds - basically right after you view the page it will be deleted. (Of course, there’s no telling if the browser would actually obey this - that would need testing.) Even if you didn’t do that, a quick javascript could be used to check the “Logged In” cookie and if it’s not there, poof page is gone.

Things that don’t work:

Eduardo said on July 15, 2004 11:54 PM

It can be very tricky for transactional forms keep functionality with back buttons, example:

1. First part of the form add a new transaction to the database.
2. Second part updates de transaction

If you press the back button, the transaction will be added again, so you end with doble trasaction.

You can have a sessionID or something to prevent this, but is double work.

Ian Clay said on July 16, 2004 5:28 AM

I recommend The Cooperative Bank

its nice and green and works great on the mac.

Luke Redpath said on July 17, 2004 5:24 AM

Yeah, The Co-Op (who own Smile as well) do the same thing with their mobile banking. Annoying, but you get used to it eventually.

Michael said on July 18, 2004 12:44 AM

I have been developing web transactions for B2B online stores and the browser navigation buttons have always been an issue. The reason for the problems were explained above and it hits the nail on the head.

Besides, I’m a FD customer as well (using Safari without problems) and have never had any problems with their navigation systems. But maybe that’s just me. Their website does what exactly what it’s supposed to do.

If FD has concerns about security than I’d rather they switch the buttons off and basta. I don’t really understand some of the other comments above. If some of the commenters above would have to be responsible for online transactions of other people’s hard earned cash then they would probably eat their words.

Without being too naive, but FD and HSBC employ pretty clever specialists for these things and also use external consultants to prevent any security issues.

dusoft said on July 19, 2004 7:20 PM

Isn’t there a option to send pragma: no-cache as HTTP header, then the page is not cached!!! So what’s this stupid thing about - it’s about stupid programmers, that can’t read HTTP specs.

ezra143 said on July 7, 2005 5:07 PM

“Isn’t there a option to send pragma: no-cache as HTTP header, then the page is not cached!!! So what’s this stupid thing about - it’s about stupid programmers, that can’t read HTTP specs.”

There are soo many browsers. Not everything is written for IE. Netscape, for instance, does not obey the pragma:no-cache header. So then what?

I am a programmer, I read the specs. But not every browser obeys the specs to the letter. But, if a customer has a problem with an online application they are going to come after MY company, not the people who wrote the browser.

I would rather have two ways of controling something than one. That way, if a browser doesnt do one, the other backs it up.

If your personal informations was stolen…. you would be whining to whatever bank that thier application didn’t do exactly what your saying they shouldnt…