Why do we not see much AJAX in secure applications like internet banking?

Question

Can someone list with references / evidences if possible, why we don't see much AJAX in secure web applications like internet banking?

For instance - Internet banking has a list of tabs for Accounts, Payments, Tools, Reports. Normally you'd see these implemented as links to different pages. Why couldn't you just have one page and use AJAX to load the content of the different tabs? (eg. a JSF RichFaces tab control)

I'm assuming that bookmarking and handling the back button (or disabling it as is common for internet banking) for the different URLS will be handled in either scenario. So I'd like to hear other things, like how it could affect security, performance etc?

My team is about to start building a web based payment management system (think setting up payments, managing client account balances, reconciliation etc.). Its not going to be making the actual payments, but it will at some point integrate with a leading bank's internet banking system.

We're divided over using one page and using AJAX for everything else

or

using AJAX only where its really helping user experience.

Gullet

My bank (USAA) launched a nice Ajax interface months ago. I like it. – Strategy

@Neil, is this just for the public facing site, or the secure internet banking? – Gullet

Even the secure, logged in areas, use ajax extensively – Strategy

@Neil: great bank and a great website. – Verbose

Answer 1

Ajax can improve usability but adds complexity.

• http://www.useit.com/alertbox/web-2.html

Banks need security.

• http://www.which.co.uk/money/bank-accounts/reviews-ns/online-banking-security/compare-online-banking-security/

Complexity is the enemy of security.

• https://www.schneier.com/blog/archives/2018/06/thomas_dullien_.html
• http://www.educause.edu/Resources/SecurityStandardsComplexityIst/162968
• http://portal.acm.org/citation.cfm?id=1218063.1217951

Therefore Ajax is the enemy of Banks ;)

Erv

Basically- what I said in less words =) Bravo. I prefer the concise answer (for once). +1 is well deserved. – Anna

I have been apart of designs in which Ajax much simplified the backend logic in some specific scenarios. Obviously this requires using it with restraint. – Azine

Answer 2

I have a counterexample for you. I'd say mint.com fits into the same category as internet banking sites, and they make heavy use of Ajax. I'd also hazard a guess that their security is better than most banks, but I have no proof of that. The banks just "feel" like they're cobbled together by Highly Paid Consultants, rather than developers who know what they're doing. Mint is a fairly recent startup, and their site design still shows the control the developers have/had.

Pipistrelle

Answer 3

I'd say the biggest reason is that banks tend to be very technologically conservative/hidebound. It's not uncommon to find a banking site that recommends or even requires using IE6.

Apologist

Until recently mine suggested that I upgrade my browser from Chrome to Internet Explorer Six, or later. Tsk. – Spathe

I have worked with the banking sector, and yes, banks are very concerned about reaching the biggest possible user base, so they are very conservative about the browser/technical requirements for their users, for example, this bank still supports IE6, and as a developer I didn't like it, but from a business perspective it made sense because there is still a lot of people using IE6. – Biflagellate

IE6 has no problem with AJAX (assuming you write the cross browser variants of xmlhttp, or use a js library like jQuery). So how does that really matter? And if we decided not to support ie6, does that give the use AJAX everywhere argument, more weight? – Gullet

I'm not saying IE6 has a problem with AJAX. I'm merely saying "you have to use IE6 to visit this site" indicates a very, very outdated system. – Apologist

Answer 4

There are several possible reasons and several possible explanations (some good, some bad). It differs from bank to bank and from programmer to programmer why they use the systems they use. My bank actually has a flash-based online banking system as of a year ago, which with all of the security vulnerabilities turning up in Flash has had me really edgy.

Some things to take into consideration:

• Most banks are very old. They've been around since the early 1900's, and some even earlier. It's rare to find a bank who just started up 5 years ago. These banks started out with pen and paper systems and so they are slowly inching into the digital age. This is in stark contrast to businesses who got their start on the internet like Facebook.

• When you work at a bank, you want to hire the "best and brightest" programmers to keep your system efficient and secure. The problem is- the people who own banks usually don't know the different between MSWord and WordPad. For this reason, positions as programmers for banking software are usually offered to the candidate with the "most business experience". Or, in real world terms, the oldest. Face the facts- as you get older you stop keeping up wit modern trends like AJAX. I wouldn't be surprised if half of the bank's back-end was coded in Java

• Banks want to keep things simple so that "it just works". Why do you think power goes out during storms but the water in the sink always works? The simplest systems are least likely to fail. If you increase the complexity, you increase the number of things that can go wrong. Even if it's a proven system that has never failed before, it's extra details and that's extra worry.

• Although my bank really can't say anything here (since some computers don't have Flash and certain iDevices won't even allow it), many banks may say no to required javascript simply because not all browsers support it or it's possible to disable it. If Mrs. Piggsworth the 80-year-old librarian down the street wants to access her bank account from her 1992 Pentium I, she certainly won't be doing it on anything newer than Internet Explorer 3

Also, I'm not sure off-hand if AJAX and SSL play nicely. I'd like to look into that.

As far as speed/efficiency goes, you'll actually find if you started using it that AJAX is faster. You only load the necessary data rather than entire webpages and you can switch between frames without having to make HTTP requests. It can also make more a more intuitive interface when you incorporate click/drag functionality and sortable lists. The problem lies mainly with the increased complexity and the fear which that should bring to any system. The more pieces you have, the more pieces which can go wrong.

Anna

"bank's back-end was coded in Java" If only, lots of banks are still on mainframes, and their programmers are suspicious of newfangled inventions like SQL. :-P – Samos

Ajax and SSL play together fine, assuming both your initial HTML page load and your Ajax calls go via the same SSL secured domain. – Erv

I suspect that Java is a bit newfangled for some banks... COBOL is much more likely I bet. :) – Prophesy

"Why do you think power goes out during storms but the water in the sink always works? The simplest systems are least likely to fail." I think that's more a function of the water pipes always being underground. If you live in an area with underground power lines, the power tends to be much more reliable. – Apologist

Even in an area with underground power, you can still lose power if the generators stop functioning. Water pressure in water towers is maintained by good old-fashioned gravity. – Anna

Answer 5

There are a few entities that are always about 10 years behind in technology: banks, insurance companies, and governments. For proof, check out the customer list for companies that do nothing but "modernization" (that is, converting companies from old COBOL systems to Java/.NET, etc), such as this one.

There are good reasons:

1. Change is harder in these institutions, mostly by design (fast change => errors => big problems)
2. Quality control is often much more involved, since screwing up even a rounding error can cause huge problems.
3. Unless there's an obvious monetary incentive, the status quo is usually "acceptable" enough to not warrant messing with.

...and there are bad reasons:

1. These are typically large institutions with large layers of approval and red tape
2. Fewer people actually care

Casas

Answer 6

Because the only problem with javascript is it has no security.

Picture this, I have loaded the funds transfer form into my browser. I give it some entries and the Javascript is so great it computes the total for me before I send it back.

Due to Javascript being a scripting language, and can be edited and returned to the server with/without user knowledge (or cross site issues), then there is zero trust of the information coming back.

When you want fancy widgets and 'stuff', now you are potentially serializing objects and using Eval() to get anything done (I am looking at you GWT).

Javascript has a nice security context and containment for the browser, but leaves the data and potentially the server very vulnerable.

Cubbyhole