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

[Andrew Sackville-West]

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.

...

> 
> Which leads me to my second point: without access to the login credentials,
> I've absolutely no way to test whether or not it's working, nor any way to
> fix it if it isn't.  

Much better for you to release the code, write up a How-To on screen
scraping bank sites and leave it at that. I will under no
circumstances give you, a third-party, my bank login credentials. just
won't happen.

> 
> Basically, while I love the security issues of a client-side scraping
> engine, I have enough experience running and contributing to open source
> projects to know that contributors come and go and the code must be testable
> and fixable even if they disappear.  Client-side scraping sounds really good
> in theory, but I'm afraid in practice will just result in a very high
> fraction of broken import engines, reducing the overall quality of the
> system beneath the threshold of utility.  

giving someone I don't know, or have any reason to trust, my banking
credentials sounds really bad in theory and is *disastrous* in
practice. The point of security protocols is not to find a way to
bypass them because they're a pain in the ass, but to accept that the
price of security is a certain amount of effort. 

> 
> At the end of the day, this is a component of a bigger system for a userbase
> having a much higher expectation of reliability -- including committed SLAs.
> Thus while I respect and appreciate alternate views on this, in my case I
> need to stick with a hosted solution.
> 
> The upside, of course, is once I sort out the trust issues, you can count on
> expensify.com for a much broader and more reliable catalog of bank import
> engines than could otherwise be feasibly obtained.

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. 

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.

A client-side screen scraping interface is great. It could even be
used as a sort of subtle pressure to get more banks to open up for OFX
downloads. But what you are proposing is a non-starter for me. 

A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20071213/1ad67fed/attachment.bin