NFCU wants different browser

yvonne116

How do you change the browser Quicken uses? I can download my mortgage and savings account, but then quicken browser pops up with NFCU web page and it shows that the browser is not compatible. Can anyone help?

Frankx

HI @yvonne116

Can you post a screen-shot (properly masked to remove any personal or sensitive information ) of what you are seeing?  That would be very helpful.

Frankx

UKR

Going from memory here ... doesn't the Q browser view have a menu item "Use Full Browser" (or similar text)? This should transfer the webpage request to your Windows default browser.
Some banks are finicky about which of the major browsers they allow ...

Chris_QPW

What is the connection type for the accounts?
If you do Ctrl+A it should show in the Transaction Download column.

If it is Express Web Connect like I suspect then the answer is no you can't change it.
I don't know the exact interplay of the flow for Express Web Connect, but there are only two possibilities.
One is that in fact it is an Intuit server that is contacting the financial institution's website with a program that simulates a web browser logging in as you.  The other is that it is Quicken the program itself using its internal web browser.  It would be most likely be required that it is the internal web browser doing this instead of an external web browser because it needs to see all the information being passed back (the transactions) once the user interaction is complete.

yvonne116

I hope these open when I post them. It is downloading the savings and mortgage, just not the checking.

Chris_QPW

It looks like @UKR has the right idea:


Try that.

Frankx

NFCU has historically (can't remember how long but it has been many years) been supporting Express Web Connect for Quicken downloads with respect to NFCU accounts - that's not been a secret, after all it is the largest credit union in the world.  And, no it does not support connections via Direct Connect and never has. 

So the OP has not been downloading via Direct Connect or Web Connect because NFCU does not support those.  I am not sure what the OP is trying to accomplish (perhaps someone should ask) but all the major browser applications are supported for access to accounts via the web.

Frankx

Chris_QPW

Frankx said:

 I am not sure what the OP is trying to accomplish (perhaps someone should ask) but all the major browser applications are supported for access to accounts via the web.

I don't use NFCU and as such don't know its details, and as such asked the questions about connection types.  But the screenshot provided clearly shows Quicken using its embedded web browser.  Can be one of two things, either what web browser it announces it is or the version it sends.  In fact this nothing more than a couple of strings that are sent in the HTML header.  Code can easily fake what browser they are (the only problem is making sure the code runs right for that browser type).

At this point I'm not sure if Quicken is using the embedded IE or if they are using the one that came from a Chrome port.  If it is IE then of course you will get websites that start rejecting that.  If it is the Chrome port well unlike a real version of Chrome this would be static could used from a library and the version number won't change.  So if the website is checking the version number of the web browser they can reject it for the same reason.

This has come up more than once for different financial institutions.  For that matter I remember it coming once when Quicken was posting a URL for the Quicken.com site!

Right now using "Full Browser" might be a workaround since it will popup the URL with the user's default web browser.

I might add that there are times that only the embedded web browser will do for what they want.  The disadvantages of not using the embedded web browser is that the web page will be outside of Quicken instead of a window in Quicken, and also if they want to "monitor" or automate any part of the conversation you can only do that in the embedded web browser.

Frankx

Chris,

You said "But the screenshot provided clearly shows Quicken using its embedded web browser.  Can be one of two things, either what web browser it announces it is or the version it sends.  In fact this nothing more than a couple of strings that are sent in the HTML header.  Code can easily fake what browser they are (the only problem is making sure the code runs right for that browser type).." - Really???  "strings it is sending"??

That screen, and I suspect similar other screens for financial institutions that have connectivity to Quicken, is NOT Quicken connecting through "its embedded web browser" - rather it is what you see when you do the following:

1) Go to "Tools" > "Online Center";
2) Select your favorite FI from the "Financial Institution:" Drop-down Menu, and click "Contact Info"; (see Snip1 below)


3) In the pop-up window - click on "Go To Website" - here's what you get - nothing more than the NFCU website inside a Quicken window. (see Snip2 below) and the ability to open the website in a "full browser window" if you like...



Nothing really to see here,  It has nothing to do with one's ability to download data into Quicken, as it is not at all connected in ANY way to that Quicken process.

Frankx

Chris_QPW

@Frankx it is next to impossible to show a web page in a window in an application without using an embedded web browser.  The whole term means that the application is using some "backend" libraries of a web browser to do the processing of the web data, and it can display that in a window or in fact it can completely hide this from the user.

The web languages can be very complicated, HTML, JavaScript, ... as such it is extremely unlikely that one would write that code from scratch.  On the other end of the spectrum you have a standalone web browser, it has no system for running in the background and sending its display to a program (not to mention receiving inputs to drive it).

Using a embedded web browser has what might be thought of as "two levels".  One is that you are just going to have a simple web browser in your application that the user pretty much just interacts with in the same way they might with a standalone web browser.  From what you and @yvonne116 have posted it looks like this connection is at this level (but I didn't know that at the start of this discussion).

The other "level" would be if the program has a need for "processing" the data sent/received.  For instance logging in for the user by sending the right data for filling in text and pressing buttons.  Or much more extensively like what the Intuit servers do.

Since the "protocol" doesn't change on the financial institution's website the embedded web browser has to follow the same rules as any web browser that would connect to the site.  That includes sending its "name" like "Chrome" and its version.  Given that this code is in a static library this doesn't change over time like a supported standalone web browser would.  And as such is subject to sending what the financial institution's website believes is the identification of an obsolete web browser.

To make things worse for Windows applications there are currently only two sources for embedded web browsers.  Microsoft's IE, and some small projects porting Chrome.  And of course Microsoft is obsoleting IE.  But one would believe that if one were to keep up to date with the Microsoft libraries Microsoft should be updating these backend libraries for embedding web pages in applications.  So the question comes up for which one is being used by Quicken in this case, and if it is the Microsoft one, then if they have kept up with getting the latest code, and if Microsoft has been updating the "name" and the version fast enough to satisfy website administrators concerned about what version of web browser you have because older ones wouldn't have the newer security changes.

A few years ago I know that Quicken Inc had changed at least part of this to using a Chrome ported library, but they might have backed out of that in time because that was only supported by a group of like two developers, and they were closing down that project.

But the very fact that the NFCU web site reacts the way it does to this embedded web browser tells me that the information it is sending is "obsolete" in the eyes of the people managing the NFCU web site.

Frankx

Hi @yvonne116

I would like to get this thread back on track and see if we can help you with your "problem."

So, there are three ways Quicken interacts with your bank: 

• Direct Connect
• Express Web Connect (Quicken Connect in Quicken for Mac) 
• Web Connect

The first two above are what I would call the "automated" ways to connect and they are clearly the easiest and most reliable.  They work completely within the Quicken application without any significant user involvement (other than to start the process).

The last one "Web Connect" is, simply put, a way you can download your transactions directly from your bank's website and import them into Quicken. This is basically a "manual" (not automated) process. From what you've said, I believe that is the method that you are currently using

NFCU does not offer the "Direct Connect" method, but it does allow and promote the use of "Express Web Connect".  With the Express Web Connect (EWC) method, Quicken communicates directly with your bank on your behalf. You don't have to sign in to your bank's website and manually download transactions - Quicken does this for you.  so, I would suggest that you switch to the Express Web Connect (EWC) method.

To setup the EWC method:
1) Open the account register and click on the "Gear" icon in the upper right corner;
2) Select "Edit account details" > and then the "Online Services" tab.  Here's what you'll see:



3) Next, click on the "Click here to find out more and get set up" link:
4) Follow the instructions that will lead you through the process.

Let me know how that goes and/or if you have any other questions.  Good luck.

Frankx