OFX Support

[bock@step.polymtl.ca]

En réponse à Linas Vepstas <linas@linas.org>:

> Harumph.  At the time, I was working with an OFX server whose source
> code I had full access to, as well as a specially modified copy of 
> quicken (provided by intuit) that made it easy to probe and test.  
> Quicken does *not* query the OFX server, and does not use the OFX 
> protocol to obtain the list of URL's.  (circa 1998). Rather, it 
> downloads a file from intuit containing bank identifiers and some 
> other encrypted crap that I couldn't make out.  It then performs 
> a second query to Intuit that somehow seemed to determine (well, 
> this is weird, maybe I'm wrong) it seemed to know if you were a 
> legit banking customer, and it did *not* attempt to contact the 
> bank if you didn't have an account there.   Basically, I couldn't 
> get it to connect to any other OFX server other than our own, and 
> thus couldn't sniff URL's.  Given the armada of tools & access I 
> had at the time, I walked away quite disappointed.
> 
> I did *not* have a windows binary disassembler, which would have
> been needed for further progress.

(This is the second time I write this message because a stupid web interface ate
it, this one is shorter, and probably even worse for spelling, sorry ;)

Actually I didn't know somebody in the GnuCash project tackled this specific OFX
problem.  I only read two years back in gnucash-devel when I got onboard.  

It may not have been clear from my previous message, but at this point
everything I say is specultation on info available to me and educated guesses. 
I didn't have time to try sniffing yet.  Before I had a working parser there was
no point, and after that I've been kind of busy with a certain transaction
matcher ;)

The information I have at my disposal:
-Recent Quicken include a file in plaintext containing info about banks,
including a field that is clearly a unique id to lookup in a database.  I
haven't checked if it's the same one that is returned in most ofx files in
<INTU.BID>.  Nothing in the file one of our users sent me is encrypted, but
nothing is directly of any use either.  They may have changed their system since 98.
-From this SlashDot article
(http://ask.slashdot.org/askslashdot/02/12/08/2244213.shtml?tid=156) it would
seem that even OFX import is sometimes disabled if the bank didn't enter in the
appropriate agreement with Quicken (such as paying for mac support)
-When I last played with Quicken 2000's OFX (I didn't know much about the OFX
protocol back then) I found a whole bunch of OFX formatted data in my log that
was clearly not gererated by my bank.
-From reading their mailing-list, Moneydance (A small comercial project) seems
to have two way communication working for a small list of banks.  I doubt they
have much more clout than we do, so it would seem it IS possible.

> > doubt that would last very long once they notice... 
> 
> Wouldn't matter: with millions of quicken users, its not like
> they can just turn this feature off.

No, but they can use the licence number for crypto (if they don't already) 

> > However, perhaps banks might let us do it "? la Quicken":  A centralized 
> > server, run by an organisation.  
> 
> Well, lets think this through.  Once a cracker has the gnucash source 
> code, then they have access to the list of banks on the central
> server.  The only way to stop this is to force the user to not be 
> anonymous, i.e. by registering each user, and then issueing them 
> a unique key that grants them access to the central server.  Thus,
> misbehaviour by miscreants can be tracked down according to the
> registration of the key.
> 
> We conclude: the former approach provides no additional security
> whatsoever, and the later approach has a large administrative 
> overhead, a legal burden, and many distasteful personal-privacy issues.  

(There used to be a two page discussion of how Quicken might have tried to keep
that list secure, too long to type again)
 
Anyway, you are right, it's a bad idea.  I never pretended it gave any real
security, just that it might make some banks feel better to have a single
organisation to talk to (if for no other reason than to send updates if they
move their servers) as well as a false sense of security.  Whatever way Quicken
implemented it, there is a password equivalent stored on disk and any half
intelligent cracker could get the whole database.

But I think now I approached this backwards.  Once we get two-way communication
working with a few banks (no reason to think we would fail, much of the hard
part is done), we should build our own list of hostnames/port numbers and
distribute it in the source.  It should be relatively easy to do since ofx
travels over http, and would go something like this:

-Fire up sniffer or connection monitor
-Fire up Quicken, use direct connect with the bank we need the info for.
-Note the hostname and portname of the connection that was generated
-Send this info, along with bank's name and perhaps what was used as the
username back to the LibOFX project.

We may not even have to get a real account at a specific bank to do it.  Some
banks might scream, but there is nothing they could do.  Even for americans and
the DMCA.  A hostname/port number pair is hardly a circumvention device, nor is
a library implementing a public spec.  Since we didn't get the info from Intuit
(we only monitored who our computer talked to, not even what it said) there are
no copyright issuse.

Seems too simple, I must have missed something.