What's stopping banks from creating FOSS (or atleast open-source) banking solutions (apps)?
What's stopping banks from creating FOSS (or atleast open-source) banking solutions (apps)?
cross-posted from: https://fost.hu/post/226135
Let's say, I create a bank with the caveat that all of my banking phone apps and webapps are FOSS (or if they depend on non-free components — banks probably do to communicate with each other —, then just OSS). Am I going to be behind the competition by doing this?
If the most secure crypto algorithms are the ones that are public, can we ensure the security of a bank's apps by publicizing it?
Are they not doing this because they secretly collect a lot of data (on top of your payment history because of the centralized nature of card payments) through these apps?
EDIT: Clarifying question: Is there a technical reason they don't publicize their code or is it just purely corporate greed and nothing else?
It wouldn't matter much.
Most of what a bank does isn't on your phone, but server side.
In fact most bank apps could be replaced with an internal web browser that is pointing at their website, and a password manager, with no loss in functionality or change in security.
And if you'd like to review the client side code the bank is using you can just open dev mode in your browser, right now.
OP raises a good point, though. Why isn't there a standard banking API that all banks could use, against which applications could be written?
People don't choose banks because of the bank's app. Banks are also pretty sticky. Having a standard would allow banks to save money on application development. I just don't see what the value-add of proprietary banking APIs are for them. It doesn't seem like much of a differentiator.
I think there's a sort of standard in the EU; why doesn't the US have one?
There are a bunch of APIs, actually. Plaid is a pretty popular one. The problem is getting the banks to implement them.
But people definitely choose banks because of their apps. For example, my bank doesn't have any physical branches in my area, so I do everything through the website or app. Remote check deposit through my phone camera, for example.
Are there any downsides to opening up the server-side code too? Would it also compromise other banks' security, since these banks need to interoperate?
It would be unwise for a bank to publish its exact fraud detection and risk management policies, otherwise they could be easily circumvented. A lot of these policies will be embodied in their internal backend services.
Someone will now inevitably mention "security by obscurity". But Kerckhoff's Principle is specifically about cryptosystems which should derive their security solely from the strength of the keys. That way, confidentiality is still ensured even when details about the cryptosystem become known to adversaries.
But non-cryptographic aspects of security benefit from asymmetric knowledge, from grey areas, from increasing risk for adversaries.
Yeah I thought you'd ask this. Basically they'll never do this, just because their attitude is "fuck you I'm a bank".
Beyond this, there's a big difference between source code and having a working system.
For very long running systems their state depends very heavily on how they were maintained, little bits of informal design decisions that get components working together, and the order stuff was loaded in, and what other services were up and running when you booted up.
None of this magic is captured by source code, and it can make even setting up a replacement server, even as part of the same infrastructure really hard.
Of course banks are moving to more modern dev methods that encourages turnkey deployment, but the fact that they still rely on a bunch of COBOL code tells you there's a lot of very old system running in "do not touch" mode
What's the advantage for the bank?
Remember that banking and finance is full of regulations, and have moving speed of snail. Opposite of IT. When asked for something like this (open source or cross compatibility or anything nerdy) the first question is "who will be liable for losses and damages when something breaks?".
Liability is probably the biggest factor. When something isn't working properly, they want to be able to point fingers at someone and blame them. The vendor then blames someone else. Open source tends to be the polar opposite, which means huge red flags - hippie stuff, no payment, no liability, no pointy-blaming game.
Or so I've heard from people working in that sector. For places as conservative as them to deploy FOSS solutions, you'll need the government branches cooperating with clearly worded laws and regulations, dragging them kicking and screaming into adoption.
And that's assuming no one will lobby against in the process.
A couple of reasons:
- Who would contribute? Banks are highly regulated and sometimes deal with complex products that most Devs don't have a background on. Even most Devs in banks rely on a team of business analysts, designers etc to shape the requirements. Add on top of that the general negative perception of banks, I can't think of a large open-source community forming.
- Competition. Bank's primarily compete with each other. They all offer very similar products, and any advantage they can gain by developing proprietary software will be explored.
- Third-party apps. Banks use a TON of third-party apps behind the scenes. A lot of times they will purchase licenses for existing products and then customise on top of that.
- Outsourcing. Even when they are building the app "in-house" they may have outsourced the development to another company, and will then just maintain the finished product.
- Banks move slooooowly. As it's a highly regulated industry, every deployment needs to go through a ton of red-tape. An exploit found in public might take weeks to be resolved internally.
- Reward is not worth risk. It simply isn't a priority and they can't see any benefit for doing it. It's more likely to cause a reputation risk than not.
You sweet summer child.
There is a middle ground reason, that being they simply dont care. There just isnt a good reason to open source their apps, they wont be accepting contributions, so what is the benefit to them?
There are.
https://wiki.ubuntuusers.de/Finanzverwaltung/
Sorry, I didn't find a good link about Linux accounting software in English. And I'm not aware of any Apps.
I've used GnuCash before but that isn't a fun way to do accounting. It's made for proper bookkeeping.
The Standard is called HBCI and needs to be supported by your bank. (it is relatively old, though)
Banking seems to vary a lot between countries. So I'm not sure what standards (and if...) they have where you live.
There are eCommerce solutions with payment and accounting. I'm not sure if the addons that connect to your provider/bank are open.
It all boils down to an open standard being available. It feels like there is some (international) regulation missing. At least for consumers. I bet large companies have their banking accounts tied into their (proprietary) software.
Keep in mind that while FOSS is doing well against MITM attacks it often falls short against MATE attackers. Whitebox crypto, obfuscation, integrity checks etc. are widely used to keep malware and malicious users from fucking with your binaries, extracting keys etc. They really don't want to leave it to their users to keep their candy crush clone riddled shitboxes secure
It does not matter how many ppl can look at the code when it comes to security. Either it is secure or it is not.
Security by obscurity is no securjty at all.