Subject: Re: Billpay site problems To: OnlineTechnicalSupport@mybank.com To the attention of Joe, the online-banking tech-support supervisor I spoke with there yesterday, and anyone else he brings in on the problem. I believe that Joe verified my customer status to everyone's satisfaction yesterday, and gave me this email address to detail my findings to. The recent site cutover at Fiserv / Checkfreeweb is causing some browser compatibility issues for me, and quite likely some other customers as well. It only affects the bill-pay area hosted at Fiserv, while the rest of the Mybank site itself still functions properly. I can get to the "Payment Center" page where my billers are listed with boxes to fill in displays, but none of the buttons or payment-date calendar popups work. The problem appears to be due to an improperly handled Javascript error having to do with JSON capability, and the problem exists on the Fiserv side. This is long and detailed, please read carefully. Let me first describe the computing environment here. I'm one of those rare folks keenly aware and concerned about Internet security issues, and take numerous steps to protect myself against online threats. My main day-to-day machine is a Mac, whose operating system is not the absolute latest from Apple but in the meantime has been extensively modified and leaned down for the sake of securing its environment and how it interacts with online facilities. In the process of trying to work this particular problem I also threw together a couple of junker Linux machines, simply because I happen to have the parts and knowledge available for doing so. You will already see that this does not likely describe your typical end-user customer. Considerations are especially critical when I set up for an online banking session, or anything else involving financial transactions. I take steps to make sure that my traffic is going to the right places online, allowing only the connections needed and the functionality required in the client browser. In the case of mybankonline.com and its integration with Checkfreeweb, connections to only these networks are permitted: 128.167.0.0/16 and 128.11.128.0/17 : main mybankonline sites 63.251.0.0/16 : OLD checkfreeweb/fiserv before cutover 166.73.0.0/17 : NEW checkfreeweb, clearly completely different now Even these are deliberately left somewhat broader than they need to be, but I realize that the target sites may move around within those ARIN netblocks from time to time. Thus, *none* of the unnecessary third-party sites such as coremetrics, ml.com, webtrends, google-analytics, ensighten, mathtag, doubleclick, etc are allowed to receive ANY data about what I'm doing with Mybank. Why those are involved at all I can't imagine and they are *not* needed for me to accomplish what I need to do. The fact that I don't talk to those irrelevant sites also has 100% nothing to do with the present problem, so let's not even start down that road. The browser also starts off with completely EMPTY cache, cookies, and history, and gets flattened back to that state after I'm done. Thus, no data whatsoever about the bank interaction, including any permanent cookies that might have otherwise been stored, remains kicking around. This is done externally to the browser itself with utilities that OVERWRITE the relevant files with random contents before deleting them. This practice likely renders the recommendations given in 90% of your tech-support calls as irrelevant, because I'm already way past the point of "clear your cache and delete your cookies". Upgrading the available browsers on the Mac itself is largely out of the question, as the installation kits for newer ones won't even run on this platform due to short-sighted packaging and library support on the part of their suppliers. Thus, "upgrading" browser capability here would involve ripping out the entire operating system and starting over, and aside from the work I'd need to put into locking it back down, given the trends that Apple has been taking with their platforms toward more dependence on "cloud" computing and less on local resources that can be reliably secured, I am HIGHLY unwilling to even consider that especially on the ZERO notice I had about the Fiserv changeover. Therefore, the Mac stays non-negotiably where it is now, but let me be clear: the client software presently on it *does* function entirely satisfactorily against numerous other sites I use frequently, including those needing typical scripting and page style functionality to interact with them. In effect, I felt like Fiserv / Checkfreeweb was suddenly telling me I had to go buy a new computer just to be able to use their site anymore, and with NO prior warning or stated sunset date made clear to me at any time. When I'm at home on my normal network, I am presently able to throw these choices of browser at Billpay: Firefox 3 on the Mac Safari 4 on the Mac Iceweasel on Debian 7 Linux [roughly equivalent to Firefox 28] Firefox 38 on Ubuntu Linux Neither of the Mac platforms work against Billpay's "payment center" page anymore, but the Linux ones do. The "beater" Linux platforms, while they appear to let Billpay work again, do not solve the problem, because if I go on the road for an extended time I'm not about to haul a big klunky desktop setup along just to manage my finances and frankly a new laptop is not on my shopping list any time soon. Location-agile capability in a portable form factor was one of my primary reasons for setting up online payment in the first place, and having the Mac along has been a perfect and secure solution over the years. Now all of a sudden it isn't. But I believe I know why, and here's the part you really need to read carefully. A bit of debugging work over the new Billpay site's Javascript turned up at least one coding error, where unfounded assumptions were likely made about a client's capabilities. All the browsers have an "error console" where site coding problems can be viewed, in which we get the first hint as to what's going on. The error is: JSON is not defined on line 132 of https://paybills.mybankonline.com/App_Themes/Common/bundle.js?hash=XXX where XXX is a long base64 session tag or something. Retrieving bundle.js in all its 900 Kb glory and having a look at line 132 gives more insight. var b=JSON.parse(fiserv.localstorage._getSubscriberItem (fiserv.localstorage._topLevelKeyPaymentCenterBillerGroups)); Now, I certainly don't claim to be a Javascript coder in any sense but I'm pretty familiar with C and language flow and have some feel for how objects and methods work. In this case the browser doesn't understand what the JSON object is, and the error thus thrown is NOT caught by the code and handled in some graceful way -- because someone assumed that JSON.parse and JSON.stringify would always be defined objects ready to work despite the fact that your .js file doesn't provide them first. That's not necessarily a valid case, it turns out. A bit of research was needed on my part into what JSON is about, but along the way it was clear that people all over the internet have had numerous problems related to it and still do. The capability is fairly new, despite being on its way to a common standards track, and even today not all browsers necessarily have the native definitions for it built in. But it is also easy to both provide on a page AND test for the existence of, as the original JSON code and improved variants are all open-source and commonly available. So I would think that in that 900K monster you stuff down our throats in the first place, you could either include the 3 or 4 K of minified JSON code support, or at least test for its presence every time you call the functions and fall out to the other Ajax/XML facility otherwise. What's more curious about this is that there are other places in that same bundle.js file where simple tests ARE done and a different method called for marshaling up transaction data if needed. On line 14, for example, we have if (bT.JSON&&bT.JSON.parse) {return bT.JSON.parse(e)} which doesn't invoke the JSON stuff if it isn't defined for the bT object. [I may have some of the nomenclature slightly wrong; bear with me.] Similarly, on line 116 I see function e(j){return b.json?JSON.parse(j):j} which doesn't affect 'j' if 'b' doesn't have its json methods set up, etc etc. See what mean? So all that stuff starting on line 132 [of the big minified blob, to be clear] about setting up "fiserv.localstorage" has been written without proper error-checking. In the interest of code robustness across a large variety of platforms, I would expect that it should be. This is probably easy to fix at the code-development level, given the models that we see nearby right in the same file. Again, none of the other pages hosted at Mybank's sites proper are affected, and the old Checkfreeweb site used to function just fine a month or two ago so either JSON wasn't used or was specifically defined for client browsers. There is another advantage to downloading your own definitions anyway -- there are good and bad ways of handling json-format data, which affect client-side security. The easiest but least secure way to parse is to hand the whole string to eval(). Better json libraries actually pick through the strings their own way, with varying degrees of paranoia, but one would think you would want to use the most cautious methods for online banking! If you aren't familiar with the development of "json2" and "json3" open-source facilities including Douglas Crockford's original code, these are worth examining: https://github.com/douglascrockford/JSON-js http://bestiejs.github.io/json3/ But again, you cannot assume or even demand the 100% existence of browser- internal equivalents to any of these, or how any such capability within a given browser is even coded. In the end it may be best to download your own functions with known content, even perhaps to *override* the built-in versions if possible and thus be more sure about how the browser will handle transaction data. Given that the Fiserv code clearly draws upon many open-source resources in the first place, as shown by some of the comments inside bundle.js and friends, utilizing one more in the interest of platform independence couldn't hurt. It would also show a little more respect for the community that has made most of these web standards work at all and provided the foundations that you build on, specific implementation versions aside. Look up what people say about "polyfills", particularly for HTML5, to see the relatively easy steps that can be taken to bring browser capabilities up to the desired levels on the fly as they interact with a site. In many cases it is still going to be up to YOU to supply that functionality, with the added benefit that you retain more control over how it works internally. Please consider these simple additions to the Checkfreeweb site, which would help move it forward rather than set it back *and* likely solve my particular problem. * * * Somewhat related to this is another issue with how one reaches the "payment center" page in the first place. It is clear that the site is simply looking at the HTTP User-agent header to try and determine exact version of a client browser, which is another flawed assumption as the client can modify that string as it pleases. This gives rise to a real kicker about the integration between the bank and Fiserv sites, as what is seen upon trying to go to the Billpay page can vary. When we land on https://paybills.mybankonline.com/imm/BrowserPolicy/Index/4661 we are given a rather insulting-looking dead end with the four browser icons telling us to upgrade before continuing, and depending on the client User-agent string supplied there is either a button below to proceed anyway, or no button. If the browser is determined to be "too old", the button is not present and at that point there is NO way to proceed. There's no easy way to get back to the Mybank customer account summary or other pages, and if the browser's own "back" function is used the user is immediately LOGGED OUT of the site entirely -- possibly because of the session-timeout refresh, but I haven't really debugged that. But it not only stonewalls the user, but adds insult to an injury they didn't deserve in the first place by forcing them to start over. Just because of PERCEIVED client platform, which they may [and I often do] freely lie about the exact nature of to begin with. This is at best an unprofessional approach on Fiserv's part, and of course just started within the last month or two as the cutover was made. Please let the user decide how they want to proceed at all times, without interfering with the rest of their session. Customers aren't necessarily going to be happy with the idea of ripping up large parts of their computing environment just because you say so, and the least you can do if you need to fail is to gracefully degrade but still be as functional as possible. For a prime example of a commercial site that does this really well, including not even needing Javascript to log in, shop, build carts and check out, look at Amazon. Scripting is only used IF the client allows it, and it would be great if banking sites could work toward similar platform independence. One of the several reasons I jumped out of your Big Competitor down the road last year was because Mybank's online site seemed far more straightforward and workable. That's still true of their own facilities, and I hope that never changes for the worse. Third-party links and relationships should feel no different when integrated well and should not impose different requirements on anyone. These days, website robustness and variety of one's options for using it can really affect the decisions of customers both present and prospective, and the less you try and constrain their decisions or dictate how they should run their own personal computing environments the more confident they'll feel about entrusting their assets to your institution. Being more receptive and less arrogant when they reach out to try and *help you* also gains far more community goodwill than the profoundly frustrating two weeks I've been through now. Thank you for this opportunity for a conduit to Fiserv's development team. Hopefully this helps advance the ideals of true browser-neutrality and ultimately could lower the load on your own support helpdesks, as your many thousands of customers can enjoy a more solid experience that comes from *simplifying* your requirements and improving accessibility. _H*