Hacker News Reader

Comment by javiercr | Hacker News Reader

Because of this we created Bankscrap[1], a Ruby gem to access multiple banks. We basically find the APIs that the Banks are using for their mobile apps and expose them through a common Ruby library with an unified data model.

Each bank has an open source adapter (this is different to Teller) and we encourage the community to help us building more adapters. So far we got adapters for 4 major banks in Spain, and 3 more are a work in progress.

Whether PSD2 is going to happen or not, we believe public APIs for banks will happen (even if banks don't like it).

IMHO banks arte not scared because of security concerns: they all have APIs in production already, they are just not documented. Their main concerns is basically how APIs used by third party services could affect their businesses.

[1] https://github.com/bankscrap/bankscrap

View on HN

So who bears the legal responsibility? Is it the business which uses your gems or the customer? You're effectively breaking most banks' terms of service, at least in the UK. It's great that you've solved the tech challenge, but that's not the biggest one to solve.

From our understanding what we do is legal in the EU, according to the European Union Computers Programs directive 2009:

> The person having a right to use a copy of a computer program shall be entitled, without the authorisation of the rightholder, to observe, study or test the functioning of the program in order to determine the ideas and principles which underline any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.

There is in fact a EU proceeding against MathWorks for preventing a competitor to reverse-engineering their product to achieve interoperability [2]

In any case, we currently offer no guarantee to our users and we encourage them to use our open source libraries at their own risk.

[1] http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2...

[2] http://europa.eu/rapid/press-release_IP-12-208_en.htm

I'm not sure you've addressed the concern. Sure, reverse-engineering an interface is legal. However, use of these APIs by third-party, non-vetted apps or libraries potentially incurs other legal risks.

I suppose you've somewhat addressed it with your final comment: "...at their own risk." I'm not risking access to all my money on using your library to access my bank account. If you say the risk is mine, and, since I'm using your library rather than an approved binary, the bank can show that the risk is mine, when someone finds and exploits a weakness in your library to take my money, I'm screwed.

> when someone finds and exploits a weakness in your library to take my money, I'm screwed.

I'm not sure what kind of exploit or weakness you are thinking about. But the risk of using Bankscrap's gem from your computer is similar to using your bank's mobile app. Bankscrap itself doesn't store any data nor send your credentials to any place other than your bank's API (the same that your mobile app does).

In other words, if you use Bankscrap's gem to build a web app to fetch and store your bank transactions (or someone else's), and your webapp or server gets hacked, obviously the responsibility is yours.

Who pays when the open source library triggers a bug in the bank's computer and takes the whole system offline?

If you had your own API exposed to the internet and someone made an HTTP call that "triggers a bug" in your server "and takes the whole system offline", would you sue the guy who made the HTTP call or would you assume it was a bug in your server / app?

And we're not talking about HTTP calls with SQL injection or things like that. We're talking about identical HTTP calls to the ones that the banks' mobile apps do. Same headers, same body.

If they're identical to the official app, they likely won't trigger an unexpected case. If they're not identical (maybe your open source lib has a bug, or the API changed) I could see lawyers trying to sell it as a deliberate hacking attempt to a court.

The open source library simply helps a programmer put together HTTP requests. If an API crashes because it receives an unexpected HTTP request its certainly not the requesters fault.

At Delft University of Technology we're working on this also for about 2 years. Currently 8 (big) banks reverse-engineered, the smartphone way (no scraping).

Besides universities there are not many non-profits that will have the legal and financial means to publish an open source lib. The legal landscape for managing a complete library with numerous banks is complex. As we see in this discussion thread, there are some fragmented solutions with limited coverage.

https://github.com/Internet-of-Money (empty placeholder)

What's the best way to contact you guys? :)

That is reasonable technical approach to the problem, but not how the courts work. On the other hand in court also should ask and answer the question of whether you triggered such behavior intentionally or not.

Also, if it's their public API used by their mobile/web apps, it would likely be crashing all the time anyway from normal user interaction (if some OSS were able to crash it via HTTP).

Nah, you can totally walk a tightrope where one's app is never crashes the API, but only because it has no input fields that allow you to try to transfer currency in the amount of "spaghetti" from one account to another.

You make it sound silly. But the "unexpected HTTP request" may in fact be a SYN flood (yes, that has happened), or looping some non-trivial request for an ad-hoc DoS. That is indeed the requesters "fault", even if there is clearly no intent and hopefully no legal ramifications.

Exactly! If someone hacks my bank, I can sue them and get my money back. If someone hacks the app using your library, I have zero rights.

No business would take that risk and use your library at scale. Yes, open source is great, etc. But it doesn't solve the problem.

> If someone hacks the app using your library.

Sorry, but I still don't understand what you mean here. There could be a bug in the library in the same manner that there could be bugs in any other open source library. Could those bugs become a security issue for your app? Yes, they could. Despite of this we all use open source software, right?

Let's say you were using Active Merchant[1], would you sue Shopify if someone hacked your app to process irregular payments through your Bank's payment gateway (accessed by Active Merchant [2])?

[1] https://github.com/activemerchant/active_merchant

[2] https://github.com/activemerchant/active_merchant/tree/maste...

Also, most OSS licenses protect the developers against this kind of nonsense anyway ('...not guaranteed fit for any purpose...'), for good reason.

If someone hacks your business checking account, you have 24 hours to detect and report the unauthorized transfer. After that, the UCC doesn't require the bank to give you your money back.

And yet every business has a checking account, and many aren't that diligent about checking it every 24 hours.

Sometimes ago I found the weboob (Web Outside Of Browser) which has CLI for french banks : http://weboob.org/applications/boobank

We weren't aware of this project. It's interesting.

However it looks like is just a collection of web scrappers. This is the implementation for Barclays bank:

https://git.weboob.org/weboob/devel/blob/master/modules/barc...

Bankscrap, despite of its name, tries to avoid web scraping in favor of XML/JSON apis provided by the banks. Right now all our working adapters are API-based, not web scrapers.

That is an unfortunate domain name, unless it's meant to be purposefully amusing.

It seems to a be very recurring discussion in the comments on each LinuxFR release post.

You can add that some modules have the same kind of name (BNporc which would translate to BNswine for BNP Paribas[0]). Or some applications: QHandjoob[1], QFlatBoob[2] or QHavedate[3] where the icon is a stickman with an erect penis getting ready to have sex doggy style[4].

They used to have a nazi svatiska on the Caisse d'Épargne module logo[5]. At least they changed that one.

Really, how anyone could use that professionally is beyond me.

[0] http://weboob.org/modules#mod_bnporc [1] http://weboob.org/applications/qhandjoob [2] http://weboob.org/applications/qflatboob [3] http://weboob.org/applications/qhavedate [4] http://weboob.org/media/images/applications/qhavedate.png [5] https://symlink.me/projects/weboob/repository/changes/module...

I think it is :-)

Why doesn't the User-Agent in this adapter reflect the actual library?

https://github.com/bankscrap/bankscrap-bbva/blob/master/lib/...

Does it break functionality if you don't pretend to be an Android phone?

Adding the library version in their would be helpful for debugging too. Ideally it'd be possible to override at the app level so that it correctly shows up in their logs.

That's a good question.

We try to mimic as much as possible the requests that banks' mobile apps would do to avoid them becoming "hostile".

Reply on news.ycombinator.com