Any interest in a "import from bank website" command?

[David Barrett]

Thank you everyone for the responses; I hear you loud and clear that you're
not interested in having this feature added to GnuCash.  I'm glad I asked up
front and saved everyone the time of me trying to submit it!  

Let me clarify a couple points in conclusion (inline):

> -----Original Message-----
> From: Andrew Sackville-West
> Sent: Thursday, December 13, 2007 11:38 AM
> To: gnucash-user at gnucash.org
> Subject: Re: Any interest in a "import from bank website" command?
> 
> On Wed, Dec 12, 2007 at 09:11:43PM -0800, David Barrett wrote:
> > That's not a bad idea, but it greatly restricts my ability to add new
> banks
> > and keep existing bank import engines up to date.
> 
> I think you're missing the point of open source software. It's not
> about *your* ability to add new banks. It's about the community's
> ability to take what you've done, expand upon it and make it more
> useable for the rest of the community.  The community will add banks
> as needed, given a good framework to start from.

I'm sorry, I didn't mean to suggest I was building an open-source banking
gateway specifically for GnuCash.  Rather, I'm building a closed-source,
hosted financial service (expensify.com), of which this gateway is simply
one component that happens to be functional.
 
The only reason I raised the offer on this list is I noticed MS Money
already has a gateway like this built in, whereas GnuCash doesn't.  I
realized with the "release early, release often" mentality it would be very
easy of me to offer GnuCash users free access to this service, and that
doing so would be a simple "win/win" basis for everyone: I get additional
users on my service helping me expand and test it, and GnuCash users get a
feature that MS Money users have long enjoyed.

However, I underestimated the strong and very reasonable security concerns
of GnuCash users, as well as overestimated how valuable this feature would
actually be.  Thank you for correcting my mistaken assumptions!  Perhaps I
was overeager to share the fruits of my labor with the outside world.



> This all sounds like a business plan to me. You've got a growing
> community of software users who have a less than ideal system for
> importing their banking records (OFX) and want to capitalize on
> that. That's fine, I'm all for people making money. Heck, the whole
> point of GnuCash is to help people manage the money they
> make. Great. But I get the feeling you're hiding a long-term
> for-profit goal behind a veneer of open-source friendly talk.

Again, I'm sorry for giving the appearance of suggesting otherwise.  I'm a
huge fan of open-source, having hosted my own open-source projects (iGlance,
QwikiWiki) in the past, and actively contributing to others (XySSL) today.  

But in this particular case, because I'm building a hosted service, I still
need to undergo the same hard task of earning the trust of my users --
regardless of whether the underlying code is open or closed.



> If you are trying to create a for-profit service, fine, just say
> it. Discuss how you are going to deal with the security issues, lay
> out how the service will be paid for (ad revenue, whatever), explain
> how you are bonded, insured, will cover people for any assets lost
> through the use of your site etc etc etc. Then see what happens.

Excellent questions and I'm eager to discuss this more, if you're
interested.  But in short:

The OFX gateway is completely stateless in normal operation (ie, no logging
of credentials or transaction data).  It only logs credentials when there is
some sort of problem, and even then only after being public-key encrypted
with 2048-bit RSA (with the corresponding private key kept off-site in a
different, password-protected TrueCrypt volume).  The intent is to further
restrict logging to only when the user explicitly allows it (ie, "I'm sorry,
there was a problem importing your transaction data; will you allow an
Expensify.com technician access your banking account on your behalf to
resolve the problem?").

I fully recognize that login credentials are dangerous to hold on to, and
thus I actively don't want to; I have every interest in destroying this
information as soon as possible and that design is carried throughout the
system.  After all, the best protection against data breach is having no
data to breach!  But sometimes, some sparing use of data goes a long way in
helping build a reliable service.

Finally, the complete service will be audited for PCI and Visa CISP
compliance, which is the gold standard for secure data handling in the
credit card world.


Anyway, thank you again for all the thought and feedback you've given, and I
apologize for any confusion or concern.

-david