Second Life Faces Threat to its Virtual Economy

Second Life Faces Threat to its Virtual Economy

Groups of Second Life content creators were gathering digitally Tuesday to protest the dissemination of a program they worry could badly damage the virtual world's nascent economy.

The controversy gathered steam Monday when Linden Lab, which publishes Second Life, posted a blog alerting residents of the virtual world to the existence of a program or bot called CopyBot, which allows someone to copy any object in Second Life. That includes goods such as clothing that people purchase for their in-world avatars, and even the virtual PCs that computer giant Dell announced Tuesday it is going to sell in the digital world.

Related to this thread, especially my "Not Merely Predictable" post, as well as the various Lightweight Static Capabilities and Robust Composition threads. I'm absolutely convinced that a future language design will evolve to accomodate the development of distributed systems in which these kinds of issues are impossible to impose. Is it time to add an "object capability security" and/or "cooperation without vulnerability" (a great phrase from Mark Miller) category to LtU?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Threat or Thread?!

Is this a pun, a mistake, or technical evaluation of the situation?


A typo, but perhaps of the Freudian slip variety? :-)

How about "Safe Cooperation"?

"Cooperation with reduced vulnerability" would be more accurate -- many useful patterns reduce vulnerability but don't eliminate it. But it's too long. "Safe Cooperation" is short and loose enough to include reduced vulnerability patterns.

How does one add a category/department?

Basically, you convince me

Basically, you convince me and I add the department. For now, I remain unconvinced that this subject will have enough traffic and readership, but feel free to enlighten me!

Argument, in the Semi-Formal Sense

My argument would be that Mark Miller's thesis on Robust Composition lays the necessary groundwork by identifying concurrency control and access control. Few people, I believe, at this stage would deny that concurrency control is a pressing issue in software development in general and language design in particular. Coupled with the observation that one doesn't yet hear safe cooperation paradigms discussed in the same way that one hears concurrency paradigms, distributed paradigms, static vs. dynamic typing, etc. discussed, it seems to me the perfect time to put such a stake in the ground. Since security isn't a separable concern, language designs that ignore security are incoherent by definition (more accurately, they will embody an unintentional security design that is statistically unlikely to be coherent). Since the site is about language design, I believe our categories should reflect this state of affairs.

Connecting dots

IOW, to address Ehud's concern, the fact that this category will likely remain rather empty of posts in the near future should be taken as a challenge to the language design community? ;)

Exactly! [n/m]


Work in Secure Cooperation

It may or may not be appropriate to start a department on secure cooperation, but to answer the question of how much traffic this topic might generate, it may be worthwhile to observe how much work is being done in this area. When recently preparing a paper to submit to PLDI on the object-cap language Emily, I was surprised, upon re-reading the related work section, to see how much stuff there is. For those not keeping a scorecard, here is the list of reasonably serious (i.e., not static sandboxes, not clumsy authentication) active secure cooperation projects I know about:

Joe-E (caps for Java)
SCOLL (a spinoff from Oz-E)
Lightweight caps in Haskell
Caps in Python (supported by Guido, I'm pleased to say)

Caps in JavaScript (there is a secret project at one major corporate JavaScript player doing caps for JavaScript, and two others are secretly thinking hard about doing caps for JavaScript, it will be quite a party if they ever tell each other what they are doing)

Typed applets for OCaml (led by Xavier Leroy, not really an object capability system, but close enough so that some of the Emily work seems to solve problems they need solved)

Isolates (the documentation claims they'll use capabilities, can't tell if they're serious, but it is amazing to see the official Java folk use the term after having such a violent immune reaction to dynamic, fluid, fine-grain secure cooperation for all these years)

You are starting to convince

You are starting to convince me... I urge editors to post on these subjects (and you know how to signup). The dedicated department comes next...

E security model

I have been reading E in a Walnut to understand what E has to offer.

For concurrency, if I understand correctly it uses an actor model where objects are either static and copied around or they are dynamic and live in their own, protected thread. The programmer works with future data that gets an actual value when the actor comes around and actually processes the message.

Security is based on facets, which limit the capabilities of the object available to clients with limited trust. The author explains that as having a different set of keys for the different doors in the house, which he opposes to the widespread security model where one has or does not have access to the house.

I am not sure how this is very different from Java where the client need different permissions for different operations; is it that permissions are on a per-object basis as opposed to per-operation type? Does the MacOS X capability system join E in that (though the problem here is that Apple tries to squash all these authentication dialogs for a better user experience)?

What "MacOS X capability system"?

"MacOS X capability system"

What "MacOS X capability system"? (Googling this string yielded nothing.)

My Reaction as Well

Insert Scooby Doo "Hruh?" here. Let me gently recommend that folks discussing "capabilities" here check out the voluminous resources available at the E site to gain an adequate understanding of what is, and is not, a capability.

Why a threat?

There's a science fiction book from the '60s or '70s about what transpires after the invention of a copy machine that can copy arbitrary physical objects (I don't recall the title or author, maybe Robert Silverberg?) In the book, instead of this resulting in abundance and wealth for everybody, control of the copy machines is tightly held, and a kind of feudal society develops around the people who control the machines.

Perhaps Second Life is about to find out what happens when real humans find themselves in this situation, albeit with virtual goods. Why that's a problem, I'm not quite sure. Isn't that the goal of utopians everywhere: humanity sitting around indulging in leisure pursuits and not having to worry about resources? Perhaps the problem is that free virtual resources could make the game boring, whereas free real life resources would allow us to play Second Life all day, and compete for artificially scarce virtual resources?

Wouldn't be a Threat...

...except that Second Life only gets things half right: they rightly have an exchange between Lindenbucks and real dollars, and rightly allow people to buy and sell things that they create in the world.

This means that their business model really is based on enforceable scarcity. Unfortunately, it's clear from their CTO's comments that they have singularly failed to grasp this—they think that offline appeals to the DMCA are sufficient. Nevermind the difference between online time and real time; nevermind that the DMCA might not be enforceable outside the US; nevermind that the DMCA might be overturned... in short, they make the same security mistakes that most people make: throw up their hands and say that it can't be done. Mark Miller and friends know better.

offtopic, but i felt a lot

offtopic, but i felt a lot better seeking after high scores in games like Tempest back then than buying accessories in today's virtual environment thingys. boring stuff... same as the pursue of hyper realistic graphics, which are then used to recreate stupid everyday reality...

It can't be done

If we are sending the 3D model of the item to the Second Life program for display, it can be taken and copied, then presented as original work. No way to work around that limitation. If it can be displayed, it can be copied.

Venus Equilateral

I think the story you mean is "Special Delivery", part of the Venus Equilateral series by George O. Smith written during the early 1940s.

It's a hell of a threat if

It's a hell of a threat if you have an in-game business making real world money, like one of my partners does. It's worth noting that "virtual estate" to run your own space in costs actual money (this isn't surprising, as it requires physical hardware to run), and many places in SL attempt to recoup part or all of their costs by selling goods and services.

SF novel

Venus Equilateral does include some stories about replicators, but they don't resemble the plot Anton described (in VE the replicators are universally available and lead, after some initial difficulties involving cloned armies, to a reasonable approximation to utopia). The book Anton has in mind, I'm pretty sure, is A for Anything (a.k.a. The People Maker) by Damon Knight.

A for Anything

The book Anton has in mind, I'm pretty sure, is A for Anything (a.k.a. The People Maker) by Damon Knight.

That's the one, thank you!

Not a software implementation problem

This isn't a flaw in the SL software or language, but a result of conflicting design goals. Second Life proposes the ability to restrict copying of the properties of virtual objects that are sent over the network to users' client software. Unless Linden Lab is going to restrict Second Life to being accessed from black-box machines users don't own, they are allowing this data (textures and object geometry) to pass outside their control, and this sort of copying will always be feasible. This is a legal problem (copyright infringement), not a technical or security problem (access to secret data). LL's response to the situation ("File a DMCA complaint") is the correct one here, I think. They're only culpable to the extent that they have led people to believe that they could deal with this kind of situation by technical means.

Partially True

It's true that you can't plug the analog hole, but there's more to Second Life than creating your own models, textures, etc. You can actually write code that adds new behavior to the world and make this behavior interact with behaviors you didn't write. It's this pattern of code written by multiple authors, with sometimes cooperating, sometimes competing, goals that needs addressing, and is feasible to address—in particular, this is what E and much of Nick Szabo's work is about: the relationship between property/exchange/use rights and code.


Agreed, but as I understand the CopyBot situation, the controversy is over the "analog hole", or more accurately in this situation, the "TCP/IP hole". It's models and textures that are being copied, not the scripts, as far as I can tell. I do agree that a Second Life-type environment could be much richer and easier to develop for if E or a similar object-cap language were used instead of LSL, but this particular problem would still arise. CopyBot is a program that runs on a user's machine and connects to the SL servers; it isn't written in LSL.

Good Point!

I think we're going to see some interesting stuff revolving around the mutual requirement of Proof-Carrying Code and encrypted computing to help address the worst of the issues here. Still, in the context of this particular incident, you're quite right.

Analog plug

It's true that you can't plug the analog hole

Something like watermarking ought to be reasonably effective in a context such as SL, where data artifacts are only valuable within the program, where they can be checked. You'd need a system in which creators can register watermarks, and legitimate purchasers are recorded.

Of course, an arms race of cracking vs. protecting is likely to ensue, but that's not much different from e.g. counterfeit currency in the real world.


But I believe that the use of the term analog hole is incorrect here.

True, but

True, but there's a significant common factor in both cases: protection becomes difficult when a protected artifact is transferred through a device or medium that supports copying, whether it's analog or digital.

In that sense, there's not all that much difference between e.g. an all-digital screen capture and taking a photograph of the screen. Also, in both cases, watermarking is one of the few possible protection mechanisms that has even the slightest hope of helping.

Perhaps the term in both cases should be "the uncontrolled medium hole", with the analog hole being a special case.

I can't think of a plausible way to make any of this on-topic, though. :)

I think you're right.

I think you're right. Regarding watermarking: Even though watermarking should work in theory, nobody seems to have come up with a method that can withstand even the simplest of countermeasures -- or maybe there's something "they" aren't telling us :).

For the life of me I can't remember who said I, but I think the following quote is the best summary summary I've seen of the whole content-protection issue (paraphrasing):

It's very hard to protect your data when the legitimate customer and the adversary are the same person.


I had to read a bit in order to be able to remain on-topic. This link helped a bit.

It appears that the problem is the lack of DRM on user generated content. The CopyBot program can log on to the SL servers and download raw content freely. In order to be on-topic, we'd need to discuss what sort of restrictions there must be in place for user generated programs. But, that is not just a safety issue, it's a security issue, too, and goes beyond PLT imho.

(Back to the OT aspect: since there's no DRM, there's no analog hole. If tcp/ip was a "hole" in this sense, slapping DRM on wouldn't help, either, but it will afaics because the hole as defined for the analog hole stands for the condition where DRM'd or watermarked content exists in form A, and it must be converted into a form B that is not exact but acceptable, and there exists a conversion from B back to A. This only leaves taking a photograph of the screen as the possible analog hole (the app had better prevent taking screenshots).)


At a wild guess, this seems related to the electronic money problem, though easier in that anonymity and decentralisation aren't a necessity. And aren't the technical problems of electronic cash largely solved? It would be a bitter irony if the first successful rollout of such a system was to protect the value of MMORPG play-money.

Not really

This is about copying items, not money. Copying items does decrease the value of those items as the manufacturer is being undercut, just like those "designer" sunglasses in Times Square cut into the profits of the designer brands, but otherwise it has nothing to do with money.

I was aware that Linden

I was aware that Linden Dollars themselves aren't being duplicated using CopyBot - undermining the value of the things you can trade for with a currency will devalue it just as surely as counterfeiting the currency itself.

But basically you're right and I was wrong, since the CopyBot thing apparently copies the designs of objects - it doesn't let you create something which the system recognises as a pair of Joe's designer sunglasses, as I assumed, but rather something that looks like one to a human.

Still, that suggests that the problem could be fairly self-limiting. If you appear in public with your knock-off goods, humans should be able to notice that it lacks the correct "certificate of authenticity". (And while in the real world you can't walk up to someone and demand to see proof that their sunglasses are genuine, in a 3D game environment it should be possible to silently check on the provenance of anything you can see.) That would leave you vulnerable to social pressure and legal action.

Can we move this thread

Can we move this thread closer to the realm of LtU, please?

Draft course for moving on-topic

From what I read on this thread, it looks some people on LtU are interested in discussion of (interaction between PLT and) economic behaviors of selfish agents.
The closest field that it reminds of is Algorithmic Mechanism Design (AMD) (an introduction to it). Granted, AMD and its subfield Distributed AMD do not specifically mention PL, but there some problems that are both core to (D)AMD and need domain-specific languages (DSLs) to operate (one or more of the chapters (at least 3rd) of David C. Parkes PhD thesis mentioned very simple DSLs, like XOR language). It may be a nice opportunity for PLT community to see if they can help in this area.


It seems to me that we're talking about access and use control, and are therefore on-topic. Of course, it would be nice to get more specific, and talk about how, e.g. lightweight static capabilities might or might not help, or talk about proof-carrying code baked into language design, or about Nick Szabo's Secure Property Titles with Owner Authority, especially in this context.

A new kind of language and more on property titles

It gets us full on topic to mention that rights transfers in my contract language could be implemented using the secure property titles Paul Snively mentioned.

I am also working on a successor to the contract language that will highlight, simplify, and extend its unique control flow features. The language is neither procedural or functional, but as far as I can tell is a new kind of beast.

Designing the contract language radically changed my idea of what program flow and instruction pointers can be. Its successor, a general-purpose programming language, may thereby make event-oriented programming and concurrency far easier. The language is targeted at GUI programming as well as smart contracts, real-time, and workflow programming. My answer to the problems of concurrency and event handling is to make the ordering of instructions the syntactic and semantic core of the language. The order of execution and event handlers are the easiest things to express in the language rather than kludged add-ons to a procedural or functional language.

I'm interested in finding collaborator(s); if you are interested please let me know.

Back to the Second Life CopyBot problem: property titles can be used to claim not only object references but other bit strings such as GL textures or compressed "fingerprints" of same. Scanning tools (similar to those already used to detect text plagiarism or music piracy) can then be used to detect copied textures, or even to some extent textures copied and slightly altered in various ways. If the copy-detection algorithm doesn't come up with too many false positives it could be used to flag titles to copied objects as pirated and those to the first claimant as the original.

In a decentralized system this would depend on many end users agreeing(as a matter of voluntary oblivious compliance) that they don't want to see pirated copies, or at least want to see them tagged as "pirated" or "plagiarized" or similar. The property titles and scanning might thereby make it difficult to profit from copying. To the extent Second Life is centralized its operators could actually revoke plagiarized objects unless the owner of the flagged content proves (in some trial-like process) that it's not pirated. If there were too many false positives the burden of proof at such a manual proceeding would have to be reversed and the system would be too cumbersome.

All this interacts with actual copyright laws in ways beyond the scope of this post. I suspect most of us would agree that invoking traditional legal systems in these kinds of cases is a very costly kind of security. We should try to use computer security to minimize such disputes. That includes secure languages.

Assigning the burden of manual process

My comments about "burden of proof" were too obscure. It's better to say that this is about the burden of lawsuit. In this case the "lawsuit" may just be some manual procedure conducted by Second Life, which may not involve much more than a system administrator visually scanning the texture labeled "pirated" against the original to confirm or reject the scanning algorithm's verdict. The distinction I'm making is that if the algorithm's false positives are low enough, the code of a centralized system(or of a decentralized system, as a matter of voluntary oblivious compliance) can automatically disable the objects it labels as "plagiarized." Thus more costly manual procedures are invoked only if the owner of the disabled object complains to the administrator.

However, if there are too many false positives there will be too many unjustly disabled objects. Shifting the burden of manual process to victims (i.e. not disabling an object until a victim complains and the administrator confirms the complaint) may be far too costly a procedure to defend against a CopyBot.

How this relates to secure languages: if you use security to shift the burden of manual process, the secured transaction needs to be undoable somehow, at least outside the system. Only if you are very confident that the code is making the right decision in the first place, or if a manual process is simply out of the question and you are willing to put up with some injustice, should a secure language action be made irreversible.

If Satan can be Beaten...

E in a walnut gives us a nice discussion about cheating in a distributed game. We can always design a protocol where the client has minimal chances of forging or cheating. In this specific case the server could create a checksum of the unique item and compare newly created items to this checksum, refusing items with colliding hashes or delegating this situation for humans to handle. Essentialy this is a design issue, not a language issue because you must never trust the client.

Other possibilities include branding any created items with forgery levels, perhaps calculated given a checksum or using a distance calculating algorithm (if we can represent the item as a string we can use a Trie variant to allow for faster distance computations, also the server can partition this calculation in work units and distribute it randomly (and redundantly) between the untrusted clients, cross-checking the results and reducing the chance of damage from malicious clients) or just flipping the bozo bit on cheaters and ignoring (without directly hinting them) their items.

Perhaps it's a tendency I have to generalize issues but this problem is similar to reducing the noise to signal level in forums, filtering trolls and spam, making a peer to peer protocol robust against malicious peers, dealing with auto-aiming hacks in FPS, etc. All these issues are independent of PL choice, because they fundamentally are outside a language boundary (i.e. the server's language of choice can't influence my computer if I don't want to).