Your2ndPlace

While all of the banking issues of last week were in overdrive within Second Life, I was also working a bit on my next¹ O'Reilly Shortcut which is about connecting Second Life to the web. It had been bugging² me, and I meant to mention it at the First Annual Second Life Banking Sector Open Forum, but there were more pressing concerns for the public - so much so that getting a word in sideways would have required more lubricant than the average pharmacy carries. Still, since things have settled down a bit and it seems like a good time to bring this up.

A Large Role Of Code

In SecondLife, a 'bank' is made up of the person who owns the bank, a profit margin, auxiliary staff, customers and the glue that holds them together: software. And software comes with it's own problems - the interactions of a standard ATM with a single user and a server are not too complex; a simple XML-RPC interface is enough for the basic structure. Toss in a few calculations, either server side or on the ATM or both.

That seems simple enough, but now if you have multiple users you require multiple accounts. A database backend is then needed. ATMs use the Linden Scripting Language (LSL) to handle money transfers. As an example, for a deposit, the following basic steps happen:

• User pays SecondLife object (ATM)
• ATM accepts payment, subject to SecondLife simulator, LSL and grid stability.
• ATM sends a message (hopefully encoded!) to the server, on the internet.
• Message to the server is decoded, and the appropriate database entry is updated to reflect the new balance.
• Server sends a message back to the ATM through the XML-RPC interface, subject to SecondLife simulator, Linden Scripting Language and grid stability..

Of course, there are embellishments here and there - but that is how money is deposited into an ATM. The design is not very complicated, but it does require coordination of real world servers and virtual world objects³. It is asynchronous, and under load bad things can happen. What keeps those bad things from happening? What keeps the system working right, so that people's accounts are maintained with each deposit and withdrawal they may make?

Multiply this all by the number of ATMs in the network, it suddenly isn't so easy. A lot of things can be done to make the system better - error checking, governing the system load and verification. The standard ATM in SecondLife is not a system, it is part of a system which is as complicated as it is safe.

Second Life Risks

Anything scripted in SecondLife is dependent on Linden Lab servers. Section 5.5 of the Terms of Service are pretty clear as far as the Linden Lab stance on liability (though Terms of Service are not Law). The SecondLife side of all of this code is subject to the performance of SecondLife itself, and as recently exemplified, these things do come up. Before people get their underwear in knots, remember that most web hosting providers are indemnified in similar ways - the only reason I brought this up was to demonstrate that issues related to the SecondLife side can and do happen.

In the recent bout of grid issues, the inability to pay and accept payment was part of the problem - and that was not a real issue for the ATMs, since they were basically frozen and didn't have much to talk to the offworld servers about. But what happens if, for example, information becomes mismatched somehow? Let's say, for example, that two people are using the same ATM- both depositing funds - and somehow, between the Second Life servers and the LSL code in the ATM, the two different accounts are mixed up? It could be a race condition, a memory leak or even a hardware fault which could be part of the problem.

And this is just the SecondLife side of things.

The Internet Server Risks

On the web side, a lot can go wrong with similar results. Accounts can be improperly handled, and this is also dependent on the hardware of the server (heaven forbid it be a shared server). The code, be it in PHP, Ruby, Perl, Java or COBOL⁴, may also have flaws in it seen only under certain conditions.

The Human Risks

Most human risks with these sorts of systems involve someone screwing up. In SecondLife, for example, it could include giving the wrong people permissions to play with the scripts - or, possibly, the scripts being modified even without permissions. The former was seen in the WSE exploit; the latter can happen in instances where scripts can be copied, or otherwise fiddled with. While the script exploits aren't necessarily the fault of the owner (and, if we remember, Linden Lab says it isn't their problem), they are human risks.

So What Keeps These Things Going?

For obvious reasons, many ATM exploits wouldn't be written about or otherwise announced because people might would take advantage of them. So what does a developer do? A good developer attempts to make the code as robust as possible.

Who Keeps Things Going?

But who writes these systems? In the real world, banking software is maintained at very rigid standards to avoid issues - and even then there are problems that are heard of. I'm not sure many people have ever heard an ATM's modem dial in and handshake (those days seem to be gone, almost), but real world ATM systems are not all so different in these regards. The key difference is that the ATMs in SecondLife can't be stolen and opened up for cash. That and the fact that software in the real world is often audited, and even developed and maintained in compliance with software engineering standards imposed by regulatory bodies.

In SecondLife, there are no real 'software engineering standards'; a basic ATM system can be built by anyone with enough time and focus. There are no audits, there are only the sounds of "Whoops!" and irate customers when things go wrong. Just about anyone can purchase an ATM system and start a bank⁵.

To their credit, most ATMs seem to be solid with few faults; I'm always happy when I 'talk' to a SLExchange ATM because if it is busy with someone, it tells me - meaning that it will only handle one person at a time, decreasing risk.

In the context of the Open Banking Forum, there are some options for banks within SecondLife to assure quality software, but it begs the question: How much time and energy are these 'banks' willing to put into assuring that their code works right? What happens on a weekend when a bug is found which can be cataclysmic? What happens if the web server needs to be rebooted while someone is sleeping?

These are serious questions which, through the grace of few bugs so far, have gone largely unnoticed - though there are war stories out there. Coding standards for banking software within SecondLife seems like something to approach seriously given the amount of money involved, especially if the profit is real enough to warrant running a bank or even a stock exchange.

In a virtual world, any financial institution relies heavily on software. Who writes the software, who supports the software, and who controls the hardware it all runs on? These are important aspects of banking which I feel have been neglected in open discussion - maybe now is the time to start talking about them, especially if people expect banks and stock exchanges to be part of the future of virtual worlds. The next time you see an ATM error, or something happens with a bank in SecondLife - remember... there are no standards for the code (yet?), and the code isn't scrutinized by anyone but the same people who wrote them.

I have my own ideas about ways to address this - but what do you think?

¹Making Your Mark in Second Life: Business, Land, and Money, targeted to new Second Life users, was my first.
² No pun intended.
³Something which is being peddled as new, but only in the sense that the results might be more tangible.
⁴Old school! Yeah, I've been around a while. I think I still have a COBOL 77 manual around here somewhere... maybe I should put it on eBay.
⁵For example, this is a banking system found on SLExchange I found with a quick search. This is not to say that the system is high risk - it simply demonstrates how easily available these systems are, and at what cost.

Technorati Tags: Banks Business SecondLife Stock Exchange virtual world synthetic world metaverse 3d finance software software engineering bank stock exchange LSL