Hacker News Reader

Comment by slavoingilizov | Hacker News Reader

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.

View on HN

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.

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.

> 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.

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.

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.

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? :)

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.

Reply on news.ycombinator.com