Bad Design (LONG post, behind cut)
Some online systems are well designed. They are responsive, user friendly, have good security for their content and don't cost the earth. On the other hand, there is Second Life.
OK, it's not quite that bad, but there are some serious flaws that have been built into the design right from the outset, it would seem. If you've not seen the reports on ZDnet, or CNN or any of the other tech news type places, the gist is that an open source project which originally intended to provide an open source client to the Second Life world produced a program that allowed for complete, unrestricted copying of any objects within the world, ignoring any copy restrictions placed on them, and resulting in a huge number of in-world businesses to shut up shop for at least the duration of however long it takes Linden Labs to come up with a) a solution, b) a way to remove all content that was copied in this way, and c) an apology.
The basic method that the copying takes place is by reading the data stream to the client software, which includes all the data for any objects within viewable range, then feeding it back to the server as a new object belonging to whatever account the interception software is accessing the grid though. It's really the equivalent of the analog hole in music copy protection - if you can hear it, so can a computer's sound card, and therefore, merely by playing it back though the soundcard, you can create a DRM free copy.
The difference with the Second Life issue is that there is a way to detect that this is taking place: the entire world is run on controlled servers, which have all the data on both what objects any given account has, and the copy status of these objects. This difference, although it may seem quite small, is where the solution to the problem lies.
The current copy process is entirely client driven, which, when compared to other things within the system, is slightly strange. Each account's inventory is stored entirely on the server, and it isn't even cached fully on the client side - changing clothes, or opening things within the inventory requires a server request for the object data, then another for the texture data, then another for the attachment position and so on - yet it appears that the client data is fully trusted by the server.
As anyone who does any type of interactive network type programming will know, client data is always treated as dirty. You might have a complex system that only ever submits a weird binary data structure from a known, closed source client, but it is still considered dirty until the receiving server has fully checked the information for unexpected input, whether this is a space in the wrong place, or something more obviously dangerous, such as the classic "SELECT * from table where col='userinput'; SELECT * from users;'" example, that every beginning form collection system programmer should be shown, and taught to protect against.
In Second Life, however, the client, which has been closed source since the world opened, is trusted by the server totally. Part of this is probably because there are server issues here - it takes quite a lot of processing power to handle 1,409,203 users (as of when I write this. There have been 567,011 users who have logged in in the last 60 days, and merely 13,887 users online at this moment, but we're still talking quite large numbers. For the websites I administer, we get about that many unique visitors each month, but we don't have to track any data between their visits) - but even so, performing verification of the client's requests is something that would be considered standard in any other online system (a shopping cart is the obvious example, where you check that the user isn't attempting to pass a request for more items that the browser is showing as available, but the same principle applies to virtually any interactive system).
The problem appears to be that trusting the client completely, and opening access to third party clients are complete opposites. Even trusting the client completely isn't clever, but at least with a closed source client, attackers have to do some work to decrypt the signals bouncing back and forth. The opening access part is clever in a different way: the owners of Second Life, Linden Labs (yes, it is a commercial enterprise. However, the people who pay Linden Labs for their online spaces are quite often the ones who develop in game objects and sell them for profit. Without these users, the total user levels drop - who wants to play a game where you have to learn how to do everything for yourself? Would WoW have been so popular if users had to first get a job in a mine to get iron ore, then do a seven year apprenticeship with a blacksmith before they could get their first sword and attack some rats? - and the people who are paying begin to wonder just why they are bothering to pay this company each month) know that there are problems with the existing client software. Designers don't like it as they have to spend ages waiting for their new texture to render, programmers don't like it as they have to wait for a server to get round to compiling everything they write in order to test every single change, players don't like it because it has all these features for designers and programmers that they never use but still get in the way of playing around.
Linden Labs spends most of their time doing maintenance in order to keep the world running smoothly for the paying players, the ones that they want to keep, and don't want to spend time on fixing the client to make life for the users easier. By allowing open source clients to be developed, they keep control of the servers (no-one has suggested that they open source the server side code - apart from anything else, it would result in a number of disconnected worlds appearing, which wouldn't take much effort to overtake Linden in terms of features, even if the user numbers are lower), but don't have to worry as much about the end user experience, as they can rely on third party developers "scratching their itches" with free or even commercial interfaces to the servers.
However, as the massive shutdown of in-world businesses has shown, even an unfinished open client can result in mass disruption to the world. At no point have any servers been compromised this time (back in September, the user data servers were compromised, resulting in every user being forced to obtain a new password - why the passwords were not encrypted on the server is another issue, but it does back up the point stated all the way back in the second paragraph: there are massive implementation and, presumably, design flaws in the system, and these run right down the the heart of the code), but the failure in data checking has resulted in over 800 comments to the official Linden Labs blog, and more in-world traffic complaining about the systems that are in place than even the potential for access to credit card details did back in September.
The problem for Linden Labs is now not only to fix the flaws, but also to regain the trust of the high paying suers, who, unsurprisingly, have been the main victims in the problems shown by the Second Life software and development systems. To begin with, they need to rethink the client-server interaction from scratch. There are far too many holes in the current system. At the very least, it would be required to introduce server-side checks on all transactions, whether in terms of in-world currency, items or even just textures. By this, I mean not trusting the client, but working on a request system: client says "I'm A and have bought X from Y", server then checks that Y is actually able to sell X to A (permissions check on the object owner, and within the object data for known permissions), before either confirming the transaction, or denying it. You would need to be able to handle the numbers of transactions at any given moment, but with query caching at a database level, common transactions would soon become quicker, while the rarer ones would take slightly longer, but as they happen less frequently, it's not a problem.
They then need to think about checking per use of items - it wouldn't be impossible (well, OK, it would be trivial) to write a client that considered any response from the server to be positive, and hence continuing to act as if the user has an object the server says they haven't got, weren't allowed to purchase, or whatever the reason had been. Therefore, it's important to check that objects transfered within the current session are valid for use. It doesn't matter if someone thinks "hmm, how about a client that never closes the session", as long as it remains a per session check. Add a maximum limit for a session (24 hours would seem sensible, but it could be shorter if required), and then check all transfers for an account on session close, and you've got a transfer system that responds correctly to the client claiming inaccurate data.
Yes, it takes more server side grunt, but it's by no means impossible. Especially when you are charging as much as Linden Labs do for space on said servers.
There are competitors to Second Life out there, and if Linden doesn't act fast, it wouldn't take much for their users to migrate. Too many flaws in the system have come out recently, and the paying users, the ones that matter, aren't happy.
OK, it's not quite that bad, but there are some serious flaws that have been built into the design right from the outset, it would seem. If you've not seen the reports on ZDnet, or CNN or any of the other tech news type places, the gist is that an open source project which originally intended to provide an open source client to the Second Life world produced a program that allowed for complete, unrestricted copying of any objects within the world, ignoring any copy restrictions placed on them, and resulting in a huge number of in-world businesses to shut up shop for at least the duration of however long it takes Linden Labs to come up with a) a solution, b) a way to remove all content that was copied in this way, and c) an apology.
The basic method that the copying takes place is by reading the data stream to the client software, which includes all the data for any objects within viewable range, then feeding it back to the server as a new object belonging to whatever account the interception software is accessing the grid though. It's really the equivalent of the analog hole in music copy protection - if you can hear it, so can a computer's sound card, and therefore, merely by playing it back though the soundcard, you can create a DRM free copy.
The difference with the Second Life issue is that there is a way to detect that this is taking place: the entire world is run on controlled servers, which have all the data on both what objects any given account has, and the copy status of these objects. This difference, although it may seem quite small, is where the solution to the problem lies.
The current copy process is entirely client driven, which, when compared to other things within the system, is slightly strange. Each account's inventory is stored entirely on the server, and it isn't even cached fully on the client side - changing clothes, or opening things within the inventory requires a server request for the object data, then another for the texture data, then another for the attachment position and so on - yet it appears that the client data is fully trusted by the server.
As anyone who does any type of interactive network type programming will know, client data is always treated as dirty. You might have a complex system that only ever submits a weird binary data structure from a known, closed source client, but it is still considered dirty until the receiving server has fully checked the information for unexpected input, whether this is a space in the wrong place, or something more obviously dangerous, such as the classic "SELECT * from table where col='userinput'; SELECT * from users;'" example, that every beginning form collection system programmer should be shown, and taught to protect against.
In Second Life, however, the client, which has been closed source since the world opened, is trusted by the server totally. Part of this is probably because there are server issues here - it takes quite a lot of processing power to handle 1,409,203 users (as of when I write this. There have been 567,011 users who have logged in in the last 60 days, and merely 13,887 users online at this moment, but we're still talking quite large numbers. For the websites I administer, we get about that many unique visitors each month, but we don't have to track any data between their visits) - but even so, performing verification of the client's requests is something that would be considered standard in any other online system (a shopping cart is the obvious example, where you check that the user isn't attempting to pass a request for more items that the browser is showing as available, but the same principle applies to virtually any interactive system).
The problem appears to be that trusting the client completely, and opening access to third party clients are complete opposites. Even trusting the client completely isn't clever, but at least with a closed source client, attackers have to do some work to decrypt the signals bouncing back and forth. The opening access part is clever in a different way: the owners of Second Life, Linden Labs (yes, it is a commercial enterprise. However, the people who pay Linden Labs for their online spaces are quite often the ones who develop in game objects and sell them for profit. Without these users, the total user levels drop - who wants to play a game where you have to learn how to do everything for yourself? Would WoW have been so popular if users had to first get a job in a mine to get iron ore, then do a seven year apprenticeship with a blacksmith before they could get their first sword and attack some rats? - and the people who are paying begin to wonder just why they are bothering to pay this company each month) know that there are problems with the existing client software. Designers don't like it as they have to spend ages waiting for their new texture to render, programmers don't like it as they have to wait for a server to get round to compiling everything they write in order to test every single change, players don't like it because it has all these features for designers and programmers that they never use but still get in the way of playing around.
Linden Labs spends most of their time doing maintenance in order to keep the world running smoothly for the paying players, the ones that they want to keep, and don't want to spend time on fixing the client to make life for the users easier. By allowing open source clients to be developed, they keep control of the servers (no-one has suggested that they open source the server side code - apart from anything else, it would result in a number of disconnected worlds appearing, which wouldn't take much effort to overtake Linden in terms of features, even if the user numbers are lower), but don't have to worry as much about the end user experience, as they can rely on third party developers "scratching their itches" with free or even commercial interfaces to the servers.
However, as the massive shutdown of in-world businesses has shown, even an unfinished open client can result in mass disruption to the world. At no point have any servers been compromised this time (back in September, the user data servers were compromised, resulting in every user being forced to obtain a new password - why the passwords were not encrypted on the server is another issue, but it does back up the point stated all the way back in the second paragraph: there are massive implementation and, presumably, design flaws in the system, and these run right down the the heart of the code), but the failure in data checking has resulted in over 800 comments to the official Linden Labs blog, and more in-world traffic complaining about the systems that are in place than even the potential for access to credit card details did back in September.
The problem for Linden Labs is now not only to fix the flaws, but also to regain the trust of the high paying suers, who, unsurprisingly, have been the main victims in the problems shown by the Second Life software and development systems. To begin with, they need to rethink the client-server interaction from scratch. There are far too many holes in the current system. At the very least, it would be required to introduce server-side checks on all transactions, whether in terms of in-world currency, items or even just textures. By this, I mean not trusting the client, but working on a request system: client says "I'm A and have bought X from Y", server then checks that Y is actually able to sell X to A (permissions check on the object owner, and within the object data for known permissions), before either confirming the transaction, or denying it. You would need to be able to handle the numbers of transactions at any given moment, but with query caching at a database level, common transactions would soon become quicker, while the rarer ones would take slightly longer, but as they happen less frequently, it's not a problem.
They then need to think about checking per use of items - it wouldn't be impossible (well, OK, it would be trivial) to write a client that considered any response from the server to be positive, and hence continuing to act as if the user has an object the server says they haven't got, weren't allowed to purchase, or whatever the reason had been. Therefore, it's important to check that objects transfered within the current session are valid for use. It doesn't matter if someone thinks "hmm, how about a client that never closes the session", as long as it remains a per session check. Add a maximum limit for a session (24 hours would seem sensible, but it could be shorter if required), and then check all transfers for an account on session close, and you've got a transfer system that responds correctly to the client claiming inaccurate data.
Yes, it takes more server side grunt, but it's by no means impossible. Especially when you are charging as much as Linden Labs do for space on said servers.
There are competitors to Second Life out there, and if Linden doesn't act fast, it wouldn't take much for their users to migrate. Too many flaws in the system have come out recently, and the paying users, the ones that matter, aren't happy.