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

[Greg Troxel]

"David Barrett" <dbarrett at quinthar.com> writes:

> Totally fair concerns.  I'll take each in turn:
>
> - As for the certificates, yes, I forgot to add the context that was part of
> my initial discussion on the gnucash-devel list: it's still very early and
> the final certificate hasn't yet been worked out.  But I agree, that's not a
> huge confidence builder, so perhaps it was premature to let people at it.

I would suggest that you take the website down immediately.  There are
so many problems with it conceptually - it's bad to train people to be
phishing victims.

> - As for phishing, you're completely right: I've got a challenge ahead of me
> to prove it's not a scam.  Other than being transparent about who I am
> (David Barrett, 846 Bush St #15, San Francisco, CA 94108, 801.860.0540), I
> think the best way is to show I've got "enough to lose" to honor my word.
> This is just one piece of a bigger system, so hopefully as I release other
> components I'll cross this nebulous line-of-trust in the near future.

Real banks have annual profits much larger than a single user's assets.
Compared to them, you don't (apparently) have enough to lose.  To offer
the servie, you ought to have something like a bank's assets, or a bond
posted against both negligence and malfeasance.  For a public
aggregation service, I'd say that should be something on the order of
$100M.

> - As for the fundamental issue of "can any gateway be trusted?" I realize
> that this list is probably more skeptical than most on this point.  However,
> I initially came to consider adding it to GnuCash when I noticed that other
> software -- like MS Money -- supports a gateway like this out of the box.
> Likewise, there are other web services (eg, mint.com) which provide
> interesting financial gateway services that are very popular.  So I know
> that *some* people like these features in other contexts; the question is if
> there are enough of these people in the GnuCash userbase to warrant the
> creation of the feature in this context.

There's a key tenet in security of which you seem to be unaware - the
principle of least privilege, which says that components in a system
should have the least amount of access necessary for them to function.

There are no good reasons why screenscraping code should be on *any*
website, instead of being in gnucash (or an extension module or
whatever).  To have it be web based is simply ridiculous from a security
viewpiont.

So no, no gateway should be trusted if it doesn't have a good reason to
exist.  Yours has no such reason.  Aggregation by the big banks is bogus
too, but trusting your brokerage with the password to your checking
account is much less broken - in that case the brokerage has quite a lot
of lose and the person already trusts them to handle considerable
assets.

> - And finally, though I haven't heard any confusion on this point but I
> realize I didn't spell it out in my original email: this feature differs
> from the existing OFXDirectConnect/AqBanking feature in that it's much
> simpler to set up (just your regular bank domain/username/password),
> requires no premium banking accounts, and focuses exclusively on the task of
> downloading transaction histories.  Thus if you just want to quickly import
> or update your transaction history with minimal fuss, use this, but use
> OFXDirectConnect for more powerful online banking scenarios.

You keep saying it's similar, but a feature that sends passwords to some
random web site is critically different than something implemented in
gnucash itself.  This difference is so important that it dwarfs all
other considerations.  Please stop pretending it's not a big deal.

> Thanks for all the feedback.  With the above clarifications, and assuming I
> can over time earn your trust, are there users on this list who would be
> interesting in using this feature?

No one should trust you, and no one should give advice other than not to
deal with you.  Code to talk to your website, or any site like it,
should not be added to gnucash.  If you don't understand the security
implications, which you really seem not to, then I don't see any basis
for confidence in any other security-relevant judgements you might make
in implemntation.  I suspect most other people agree with this, but that
they've been more restrained in commenting.

There's a further issue, which is that this is a Free Software project,
and so far you're talking about people using your website, but you're
not talking about sharing your code.

So: are you willing to publish the code and work towards integrating it
into gnucash itself, and give up on the idea of running an
apparently-phishing website?  If so, that would be a productive
contribution.  If not, Free Software is probably not for you.

> Basically, is the existing online banking featureset of GnuCash entirely
> adequate for existing users, or is there interest in a more trimmed down,
> streamlined transaction history import function?

That's an entirely separate question.  Adding better importing code *to
gnucash* is very likely a good thing.  But what you are pushing now is
to add code to talk to proprietary gateway running on a website that
can't reasonably be trusted.