Excessive Javascript at financial sites

Finance
#1

How much javascript is too much for a bank / finance website?

I recently opened savings and checking accounts at Ally bank. The former was to take advantage of their 1% bonus, and the latter was to investigate Ally as an alternative to my previously semi-fast and semi-efficient Chase checking account.

Upon logging into my Ally account, Firefox’s NoScript add-on threw up a slew of domains wanting javascript access. Fortunately, I only had to enable Ally.com for most of the site to work properly. Here is what NoScript showed as wanting access to my machine:

Ally_javascript_cropped
Ally_javascript_cropped.png342×742 50.1 KB

Is it normal for financial entities to run javascript from this many domains? I’ve come to expect it from many free and retail sites, but my other financial sites only ask for access to two or three domains, all of which they own. From a legal standpoint, if a non-bank owned domain is compromised, steals my credentials and then drains my account, would the bank responsible?

… guess I should change my nick to tin-foil-hatted honkinggoose. Uh, where’s that new icon thingy.

1 Like
#2

This is an automatically-generated Wiki post for this new topic. Any member can edit this post and use it as a summary of the topic’s highlights.

#3

liveperson is for the chat. The rest are probably ads and analytics. If any of them get hacked and your logins are stolen, better have email or text alerts enabled for any changes or transfers (and hope that changing an email address or phone number will trigger those alerts to the old email or phone).

For accounts I have, looks like Barclays is the best (just one internal and one unnecessary external), Citibank is the worst (maybe not as bad as ally), the rest are somewhere in between. Most of the time external scripts are not needed unless you want to chat, provide feedback, or find a branch.

You must change the settings to enable using the full address, because many domains have lots of completely unrelated subdomains (like cloudfront) that should not be all enabled at once.

Also this looks like the pre-Quantum version of NoScript. The new version uses a more compact menu.

2 Likes
#4

Aren’t banks generally liable for the funds if the accounts are hacked?

I thought that was the deal. Not to say its fun to get hacked or necessarily easy to get the money returned but ultimately I believe the bank is supposed to make it right for you financially and return the funds. They’re the ones guarding the money…

(I mean assuming you’re not an idiot giving out your password or otherwise being negligent. )

#5

I know what most of them are for, but am surprised to find so many on a bank/financial website.

Chase is pretty good, with only internals, unless you want to comment on their new website, in which case you have to allow an external.

I agree with your comment about using the full address. On this machine, I only visit my financial sites and only allow javascript from that site. My other machines are set as you suggest. And I’m using a pre-Quantum version of Firefox. Yes, I know.

Edited to add: Discover is also pretty good, only asking for two external sites and functions perfectly without either being granted access.

#6

The only one I found that sometimes does not function correctly without external scripts is Citibank, which sometimes requires nexus.ensighten.com. I think it’s only when you try to make profile changes or go to another service, like Virtual Numbers.

#7

I think it depends. Regulation E would apply to electronic transfers out of an account, and would limit the liability of customers to $50 or $500 if the customer notifies the bank within a certain period of time. I think a lot of banks contractually decrease the customer’s liability to $0. But if certain damages as a result of a hack are not covered by Regulation E, I’m not sure who would be liable.

1 Like