All of those analytics would already have the ability to run in the bank's origin and steal my money. What threat model are you operating under where malicious code running on your bank's website is trying to do something other than steal all of your money (which they're already able to do if they're executing on the bank's origin)?
The threat model where the analytics company is hacked. I don't know why you would trust your bank to never let that happen.
There are some APIs on the bank site you need to conduct your business, and there are also some extraneous APIs. Yeah, sure, you tell the bank it's their fault clickwatcher.js got hacked, and maybe they give you your money back, but it seems like unnecessary exposure to unnecessary hassle to leave all that crap running fully trusted.
But having a more hardened browser literally does nothing to protect you. If your bank's website is hacked because of a third party API, the most well-hardened browser (as the commenter that I replied to describes) in the world will happily allow all of your money to be stolen. A slow-but-secure JS engine does not protect you from JS that's doing things it's allowed to do.
Oh, oh, oh. I thought this was the thread where we turned javascript off or used adblock or some such. Yeah, secure vs insecure jit engine isn't going to help here.
