July 25, 2007
Second Life Bans L$ payouts for Random Number Generators
Recently, a SL-supporter asked me what the biggest business risk SecondLife/Linden Lab faces. I said “A major government determining that the L$ is a currency, in conflict with banking laws and/or fully taxable at conversion.”
It looks like they got one of those scary government letters indicating that L$ are a little too close to good-old American greenbacks, as Linden Lab has just banned gambling machines in Second Life.
We all saw it coming – admit it. What’s next? Hmm?
What do you think will happen if the Linden Exchange is closed for good?
Randy
June 5, 2007
Gnome Rain: BlockChat™ moves to Worlds of Warcraft
As I wrote in a recent post:
By hook, or by crook, customers will always find a way to connect with each other.
As with all worlds, this is now demonstratively true in Worlds of Warcraft, where a new text-filter on broadcast chat messages was recently installed to supposedly prevent gold farmers from spamming users about their websites.
It worked for a few days, until yesterday, The Day it Rained Gnomes.
Watch the video and duck…
I often have a conversation with online community/product managers telling them that text-filters are a symptom of deeper problems in your product and are not a solution. They usually don’t belive me – but now I have the video.
(For the comments section: How many design flaws/weaknesses are involved in the chain of events that lead to the world raining gnomes? Here’s a hint about where to start counting…)
May 19, 2007
Second Life History: The Jessie Massacre
Or: The first deployment of user-created WMDs in a 3D virtual world
As told by the perpetrator, Oracle Omega
My first impression of Second Life was formed when it was still under development, when Phillip came to visit Chip and me at our third little startup: State Software. Technically, it was pretty amazing. They’d finally created an extensible, programmable world with physics built right in. On the social side the model was that everyone would live and build on one of a few large continents. We cautioned that this would be fraught with peril. Even before the first beta testers arrived, they’d been warned that their biggest problems were going to be property encroachment, bad neighbors, and script-griefing. Alpha World had demonstrated that many of the neighborhoods would be something between garbage dumps, billboard farms, and smutty slums next to some amazingly creative and wonderful stuff. Much of the predicted chaos happened during beta, but the full force wasn’t felt until broader release, especially when anyone could join instantly and for free.
I happened to be unemployed during late alpha and early beta, and had been so intrigued by Second Life that I decided to run some experiments, pushing the limits of what how I thought future users would abuse the system, specifically property rights and scripting capabilities. As I’ve written elsewhere, regular beta testers normally don’t push the limits as much as we’d like them to because they fear losing their status as testers by being ejected.
Having co-created several of the progenitors of this type of system, I knew where to look for cracks. I had no fear of being ejected for taking the servers down. On the contrary, it was an explicit goal. Better now, during testing, than later with paying customers.
Probably the most legendary of my experiments was the Invisible Teleporting Grenade of Death. Nothing special compared to the offensive and defensive objects in Second Life today, but it caused quite a stir during beta because it was the first known deployment of a user-created Weapon of Mass Destruction in a 3D virtual world.
Note: This wasn’t the first programmable world I’d done massive damage to: Years earlier, after a certain Wizard on LambdaMOO decided to show-off and summon all the food in his world to our room for a food-fight, I was inspired to write a script that would summon all instances of any class into the room with me. I tried on it Class:Paper, and it worked perfectly , first try. It was at that moment I realized I had no way to put the paper back where it belonged! I quickly wrote a script that stuffed the paper into the pockets of their owners and reported this flaw to another Wizard. She was not happy.
During the Second Life beta test, its initial culture was starting to emerge. In my experience, worlds like this one attract early adopters of a somewhat democratic-libertarian bent – “Lets just all get along” and “Leave Real Life rules behind” often reflect the mentality of the most vocal users. But, something unusual happened this time – another virtualworld, called World War II Online, was failing and its 1940’s role-playing refugees migrated to Second Life, en masse. Since it provided for personal combat (hit points), death (teleport you home), and you could build just about anything, including weapons, it seemed like an ideal fit. Quickly they’d built up WWII cultural and military items, including Nazi uniforms, gear and propaganda, including flags and posters with Swastikas and the like. Eventually they took over the only remaining full-combat enabled simulator [patch of land], named Jessie, and made it their home.
A WWIIOL emplacement in Jessie
This ticked off many members of the existing community, who detested all of the pro-Nazi imagery. The WWII online-ers said they just wanted to be left alone to play their war games. Both sides were sniping at each other, both literally and with virtual weapons. Eventually there was a huge wall constructed separating Jessie from its neighbors. It didn’t help.
I’d built and run too many worlds and had seen this kind of thing end badly so many times that I just stayed out of it. Honestly, this was the kind of thing I’d warned about from the beginning and I just wanted to see what would happen.
Until the day I’d completed my latest experiment.
I’d been working with the object spawning directives in the scripting language. I’d also discovered that I could make an object very small (less than an inch in diameter), and very transparent (virtually invisible). It struck on me that I could make a weapon of mass destruction and do it very cheaply. It worked like this: a tiny invisible floating grenade that would explode into dozens of invisible tiny fragments flying outward spherically at maximum velocity and doing maximum damage and then immediately teleport itself to another random location in the simulator. It would be undetectable, unstoppable, and lethal: The perfect killing machine. It could only be stopped by me shouting the keyword: STOP!
Small-scale tests on my land were successful. It fired up to 100 rounds per minute. But, where could I test this at full scale? There was only one answer – Jessie – the only Sim with an active population and the fatality flag on. As a special guest beta tester I had 30 minutes early access to the servers, so I dropped six of these little gems in Jessie just before opening time, they wouldn’t have a chance to catch me. Back then, each object spawn cost $L10, so my balance indicator started fluctuating wildly as the invisible fragments spawn, flew, and eventually hit something or someone.
I flew to the simulators with the most users and tried to chat naturally, but it was difficult, knowing the chaos that was going on in Jessie when people arrived: Log in, poke around awhile then seem to randomly die, get teleported home, which is also in Jessie, wait a short moment, repeat!
After about a half hour, people around me were starting to say “Wow! Someone is slaughtering those WWII guys in Jessie!” “That place is in a panic!” “That guy’s my hero!” “Lets go see!” The grenades were working. Besides making my point about the scripting language, I’d created one of the first legendary events of the world. That was exciting.
But, only then did I realize I’d chosen sides in a fight that I didn’t really care about. I wasn’t really sure what to do at that moment, when I got an Instant Message from one of the Lindens: “Did you release an auto cannon in Jessie?” I had to be a smartass and answer: “No. I released six. I’ll go and deactivate them now.”
I flew to the edge of Jessie and shouted the keyword. My balance meter stopped jumping around and stabilized, the attack was over. It had been well over an hour since opening, and I was certain that I had the highest kill rate in Second Life history. But now I had a problem. I had no way to extract them (and I wasn’t about to enter Jessie at that moment anyway – I was certainly Kill On Sight at that point, assuming they knew the name of the bomber.
It turned out that my grenades were too small and invisible. Though they were now inert I couldn’t find them to remove them. In effect, they were a dormant virus in Jessie. So, I filed a bug report: “Unable to select small, invisible objects.” The in next day or two there was a patch to the client to “show transparency” so that it would be possible for me to see them, select them, and delete them – which I promptly did. But the legend remains.
In the end, very little was done to mitigate the design of WMDs like mine, and I was told that to “fix” the problem would put serious limits on the creativity of future users. So be it. But, given the history of the service since then, with so many sim-failures based on malicious and accidental infinite spawning scripts, I’m not so sure that ignoring this problem was the best choice. I hope it is not too late.
March 1, 2007
The Untold History of Toontown’s SpeedChat (or BlockChattm from Disney finally arrives)
In 1992, I co-founded a company with Chip Morningstar and Douglas Crockford named Electric Communities. We initially did a lot of consulting for various media companies that were looking to leverage the emerging online gaming industry. One of those companies was Disney.
Disney had formed a group to look into taking the brand online, including a full-fledged multiplayer experience as early as 1996, when the were considering a product called HercWorld, which was to leverage the upcoming movie franchise Hercules. Having built Lucasfilm’s Habitat and WorldsAway, we were clearly amongst a handful of teams that had successfully constructed social virtual worlds that’d made any real money, and Crock had media connections from his days a Paramount, so they brought us in to discuss what it would take to build a kid-safe virtual world experience.
They had hired their own expert to lead the project, a former product manager for Knowledge Adventure – a kid’s software company that’d done some 3D work as well as their own online project KA-Worlds, which was meant to link sick children in hospitals together using computers and avatars.
Disney makes no bones about how tightly they want to control and protect their brand, and rightly so. Disney means "Safe For Kids". There could be no swearing, no sex, no innuendo, and nothing that would allow one child (or adult pretending to be a child) to upset another.
I found myself unable to reconcile the idea of a virtual world, where kids would run around, play with objects, and chat with each other without someone saying or doing something that might upset another. Even in 1996, we knew that text-filters are no good at solving this kind of problem, so I asked for a clarification: "I’m confused. What standard should we use to decide if a message would be a problem for Disney?"
The response was one I will never forget: "Disney’s standard is quite clear:
No kid will be harassed, even if they don’t know they are being harassed."
"So much for no-harm, no-foul," Chip grumbled, quietly. This requirement lead me to some deep thinking over the coming weeks and months about a moderation design I called "The Disney Panopticon", but that’s a post for another day…
"OK. That means Chat Is Out of HercWorld, there is absolutely no way to meet your standard without exorbitantly high moderation costs," we replied.
One of their guys piped up: "Couldn’t we do some kind of sentence constructor, with a limited vocabulary of safe words?"
Before we could give it any serious thought, their own project manager interrupted, "That won’t work. We tried it for KA-Worlds."
"We spent several weeks building a UI that used pop-downs to construct sentences, and only had completely harmless words – the standard parts of grammar and safe nouns like cars, animals, and objects in the world."
"We thought it was the perfect solution, until we set our first 14-year old boy down in front of it. Within minutes he’d created the following sentence:
I want to stick my long-necked Giraffe up your fluffy white bunny.
KA-Worlds abandoned that approach. Electric Communities is right, chat is out."
That was pretty much settled, but it felt like we had collectively gutted the project. After all, if the kids can’t chat, how could they coordinate? It’d end up being more like a world where you could see other players playing but you couldn’t really work with them much. [Side note: Sadly, a lot of MMORPG play is like this anyway, see Playing Alone Together.]
As I starting daydreaming about how to get chat back into this project, we moved on to what activities the kids might do in the now-chat-free HercWorld. It was standard fare: Collect stuff, ride stuff, shoot at stuff, build stuff… Oops, what was that last thing again?
"…kids can push around Roman columns and blocks to solve puzzles, make custom shapes, and buildings.", one of the designers said.
I couldn’t resist, "Umm. Doesn’t that violate the Disney standard? In this chat-free world, people will push the stones around until they spell Hi! or F-U-C-K or their phone number or whatever. You’ve just invented Block-Chattm. If you can put down objects, you’ve got chat. We learned this in Habitat and WorldsAway, where people would turn 100 Afro-Heads into a waterbed." We all laughed, but it was that kind of awkward laugh that you know means that we’re all probably just wasting our time.
HercWorld never happened.
Once again, into the breech
Electric Communities moved on, renamed itself Communities.com (which has nothing in common with the current company/site using that name and url.) and did some wonderful design work on a giant multimedia 3D kid’s world for Cartoon Network, which ended up being much too ambitious to fund, but I mention it because the project was headed by Brian Bowman. Brian eventually left Atlanta for Disney, where he was in charge of the online experience for Zoog Disney, a pre-teen programming block. Brian remembered his work with us and asked us to help build a world for the Zoog audience. Nothing so extravagant this time, just something simple, like The Palace (which, by then had been acquired by Communities.com.), a no-download, in-browser, 2D graphical chat with some programmed object capabilities.
"The Disney Standard" (now a legend amongst our employees) still held. No harassment, detectable or not, and no heavy moderation overhead.
Brian had an idea though: Fully pre-constructed sentences – dozens of them, easy to access. Specialize them for the activities available in the world. Vaz Douglas, our project manager working with Zoog, liked to call this feature "Chatless Chat." So, we built and launched it for them. Disney was still very tentative about the genre, so the only ran it for about six months; I doubt it was ever very popular.
Third time’s a charm
But the concept resurfaced at Disney a few years later [2002] in the form of SpeedChat in ToonTown. It was refined – you select a subject and then from a submenu of sentences, each automatically customized to the correct context. Selecting "I need to find …", would magically insert the names of the items you have quests for. For all walk-up users, all interactions would be via SpeedChat.
They added a method to allow direct chat between users that involves the exchange of secret codes that are generated for each user (with parental permission). The idea is that kids would print them out and give them to each other on the playground. This was a great way for Disney to end-run the standard – since Speed Chat was an effective method of preventing the exchange of these codes, and theoretically the codes had to be given "in-person", making the recipient not-a-stranger. Sure, some folks post them
on message boards, but presumably those are folks who 1) are adults, or 2) know each other, right? In any case, as long as no one could pass secret codes within Toontown itself, Disney feels safe.
The Ghost of BlockChattm past
Soon after ToonTown opened its doors, they added Toon Estates – a feature that gives you a house with furniture, initially just a bed, gumball machine, chair, and armoire. Then they added the ability to buy more furniture of all shapes and sizes from catalogs, and then you could invite people to visit your house to see how you have arranged all your cool stuff.
Sure enough, chatters figured out a few simple protocols to pass their secret code, several variants are of this general form:
User A:"Please be my friend."
User A:"Come to my house?"
User B:"Okay."
A:[Move the picture frames on your wall, or move your furniture on the floor to make the number 4.]
A:"Okay"
B:[Writes down 4 on a piece of paper and says] "Okay."
A:[Move objects to make the next letter/number in the code] "Okay"
B:[Writes…] "Okay"
A:[Remove objects to represent a "space" in the code] "Okay"
[Repeat steps as needed, until…]
A:"Okay"
B:[Enters secret code into Toontown software.]
B:"There, that worked. Hi! I’m Jim 15/M/CA, what’s your A/S/L?"
It seems that many of The Lessons of Lucasfilm’s Habitat still ring true.
I’ll consider this as The SpeedChat Corollary:
By hook, or by crook, customers will always find a way to connect with each other.
P.S: Brian tells me that Cartoon Network is actually resuming the project, more than ten years later; "… now that is being ahead of your time."
[Thanks to the legendary Robin Hood of Neopets for telling me about this Secret Code exchange prototcol.]
[Yes, the BlockChattm brand is a joke.]
January 2, 2007
Archive Repost: Second Life in Fall 2003
[The MUD-DEV archives have been offline for several years and I know some folks have linked to the following post (and now have dead links). Since I re-tell parts of this story often, I thought I’d archive it here for posterity. There is no special meaning to me re-posting it now.]
From : “F. Randall Farmer”
To : “Discussion of MUD system design, development,and implementation”
Subject : RE: [MUD-Dev] The State of Play: On the Second Life Tax Revolt
Date : Tue, 23 Sep 2003 23:12:33 -0700
Monday, September 22, 2003 8:16 AM, J C Lawrence said:
> The State of Play: On the Second Life Tax Revolt Posted by James
> Grimmelmann on Sunday, September 21 @ 19:11:48 EDT Governance
I couldn’t let this one go without comment:
JC quotes a rather lengthy article attempting to tie a “tax revolt” in Second Life to an emergent democracy. As a long-time beta tester of Second Life (and a a User Experience/UI design contractor a few months back), I’d have to say that it is all much ado about nothing. The ‘protest’ was neither widespread, nor was it as ‘intense’ as as it could have been (see below). Virtual Press photos had to be re-enacted for the staff-written newsletter and the vast bulk of users didn’t know it had happened until he wrote about it, days later.
Specifically, Grimmelmann said:
> Other than quitting the game entirely (the threat which lurks
> behind all such protests), a street party is just about the only
> action you can take that will even come to the attention of the
> authorities.
This is an understatement of some scale for all systems, but especially Second Life.
A protest party is pretty much the _easiest_ action you can take in SL.
I personally (along with many others) have generated significant attention and action from ‘the authorities’ (and fellow citizens) using the built-in scripting, object creation mechanisms, and persuasive reasoning on the game Forums.
During beta, I built an invisible teleporting auto-cannon that fired 100 invisible rounds per minute and unleashed it in an area of WWII Online folks who had been at ‘war’ with my clan. It killed hundreds for about an hour before I was asked by the ‘authorities’ to remove it. Changes were made so that invisible objects can be seen in authoring mode.
After release, I created a world-touring, talking airship ALA Blade-Runner. Logs indicate that thousands of people had seen and interacted with over a two month period. It became well known, and the subject of some debate. This airship (along with various user-run air taxi services) often became ‘stuck’ over people’s land because of a mis-tuned property feature. One good rant posted on
their forums stating a rational case and citing Lawrence Lessig citing the Supreme Court’s decision in US V. CAUSBY and the problem was fixed in the next build. [See full post for excerpted discussion thread.]
And I’m not even close the most skilled or prolific scripters/artists/politicos on that system. Though my personal reputation may have helped convince the authorities in the case of the airship right-of-way discussion, that serves to reinforce my point: Well considered and executed individual action often facilitates change more efficiently than any mob-party.
Honestly, the Tea-Party in Second-Life had little in common with the historic event: Destroying ships and tea did real financial harm to the King of England (and loyalist businesses). The tea crates in the SL protest were bought and paid for by the protesters, who were taxed for them anyway. On the other hand, those few who tore down the structures that they knew Linden Labs liked to visit during their press demos (thus removing value from the system) were closer to those great American terrorists of old. :-) They were few and far between.
Most of the tax protesters aren’t all that serious. They aren’t en-mass taking the actions that would cause a change, because it isn’t that important to them. It is a street-party because they’ll keep playing even if the tax structure doesn’t ever change.
So, asserting that a real-time ‘street-party’ protest within a virtual world is the most effective form of facilitating change we can hope-for/expect is a supposition that I think deserves serious challenge. Users can (and will) do so much more.
The so-called Second Life Tax Revolt is a bad example of ’emergent governance’ for the reasons stated above: Taxes don’t matter enough for the users to do anything significant, even though they have the power and the skills.
Randy [September 23, 2003]
December 22, 2006
Smart people can rationalize anything
One of the things we were able to do at Electric Communities was to attract one of the highest density collections of scary-smart people I’ve ever seen gathered in one place before. There are a lot of nice things about working with smart people. For one thing, they’re not stupid. Working with stupid people just sucks. Smart people are good if you need to do a lot of really hard things, and we did a lot of really hard things. But it’s not all upside. For one thing, smart people tend to systematically overestimate the value of being smart. In fact, it is really valuable, but they still tend to weight it too heavily compared to other virtues you might also value, such as consistency, focus, attentiveness to the emotional needs of your customers, and so on. One of the problems with really smart people is that they can talk themselves into anything. And often they can talk you into it with them. And if you’re smart yourself, you can talk them into stuff. The tendency to drift and lack of focus can be really extreme unless you have a few slower people in the group to act as a kind of intellectual ballast.
Why do less when you can do more?
Smart people can invent solutions to problems you don’t actually have yet. The problem is, it’s easy to think of problems you don’t have yet. Stopping to solve them all now is a recipe for paralysis. Furthermore, while it’s easy to think of all kinds of potential future problems, it’s much harder to forsee which of those you will actually have, much less all the ones that you are going to have that you didn’t anticipate. People who are less smart manage to avoid pouring resources into unnecessarily solving future problems because they aren’t able to figure out how to solve those problems anyway. So they just ignore them and hope they don’t actually come up, which in a lot of cases turns out to be the way to have bet.
Programming sage Donald Knuth taught us that “premature optimization is the root of all evil.” It turns out that this doesn’t just apply to coding.
You can’t sell someone the solution before they’ve bought the problem
Smart people can invent solutions to problems folks actually do have but don’t know it yet. These solutions are usually doomed. This ties in with the whole You Can’t Tell People Anything principle. It is nearly impossible to solve a problem for someone if they don’t believe they have the problem, even if they really, really do.
For example, one of the deep flaws in many distributed object schemes, such as the CORBA standard, is that they make no effective provision for distributed garbage collection. This is a major pain, because if storage management is annoying to get right in a non-distributed system, it can be brutally so in a distributed system. Java’s Remote Method Invocation standard is somewhat better in that it does do DGC, but it still can’t cope with unreferenced distributed cycles. One of our wiz kids, Arturo Bejar, devised for us a truly elegant DGC algorithm, which is not only efficient but gracefully handles distributed cycles. (To my eternal shame we patented it.) Since to work well in Java it really wanted to be in bed with the Java Virtual Machine, we tried to sell it to JavaSoft, who were literally next door to us in Cupertino (actually, we tried to give it to JavaSoft), but they weren’t interested. They hadn’t bought the problem yet. So a small piece of great technology that could make the world a slightly better place sits on the shelf.
Generalitas gratia generalitatis
(For those of you who, unlike me, lack a co-worker who spent 7 years studying Latin, whom you can bug for stuff like this, that’s “Generality for Generality’s Sake”.)
Smart people love to think about the general case scenario.
For example, at Electric Communities we ended up making a big investment in developing an orthogonal persistence mechanism for our object infrastructure. For those of you who are unfamiliar with it, orthogonal persistence is one of the ultimate examples of highly generalized technical coolness. Basically, the idea is that you abstract away the file system (or any other persistent storage, like a database) by keeping everything in memory and then playing tricks with the virtual memory system to make processes immortal. The example we were inspired by was KeyKOS, a highly reliable OS for IBM mainframes that was developed by some friends of ours in the 1980s, in which you could literally pull the power plug from the wall, and, after plugging it back in, be rebooted and running again — including transparently resuming all the running processes that were killed when you cut the power — in about 8 seconds (this was actually one of their trade show demos). You gotta admit, that’s pretty cool. Some commercial installations of KeyKOS have had processes with running times measured in years, surviving not only power failures and hardware malfunctions, but in some cases actual replacement of the underlying hardware with newer generations of equipment.
Orthogonal persistence was attractive to us not just because of the reliability enhancements that it promised, but because it would free programmers from having to worry about how to make their objects persistent, since it abstracted away all the serialization and deserialization of object state and associated design questions. Anything that made programming objects simpler seemed like a big win. And so we built such a system for our object framework, and it worked. It wasn’t quite as awesome as KeyKOS, but it was still pretty awesome.
One of my favorite catch phrases is, “The difference between theory and practice is that, in theory, there is no difference, but, in practice, there is.” Orthogonal persistence was a great idea — in theory. Of course it cost months and months of development time, and it introduced a number of subtle new problems, any one of which would have a made a good PhD dissertation topic. If you are trying to produce a commercial product in a timely and cost efficient way, it is not good to have somebody’s PhD research on your critical path. For example, it turns out that for most kinds of objects, the amount of state you actually need to save persistently is a small fraction of the full run-time state of the object. But in an orthogonal scheme you save it all, indiscriminately. The problem is not so much that it’s bulky, though it is, but that the volume of semantic meaning that you are now committed to maintain in near-perpetuity is vastly increased. That turns out to be very expensive. The problem of schema migration as new versions of objects were developed (due to bug fixes or feature enhancements) proved effectively intractable. Ultimately we fell back on a scheme that compelled programmers to be much more deliberate about what state was checkpointed, and when. That proved more practical, but in the meanwhile we lost literally years of development resources to the blind alley. Less sophisticated developers would not have gone down this blind alley because they wouldn’t have a clue that such a thing was even possible, let alone be able to figure out how to do it. They would have been saved by their own simplicity.
Keep in mind that all of the foregoing is not an argument against being smart. Rather, it’s a recognition that human rationality is bounded, and even really, really smart people must necessarily fall far short of mastering the complexities of a lot of the things we do, as engineers, as business people, and as ordinary human beings. What works the kinks out of a thing is often just the passage of time, as the shortcomings and subtleties gradually emerge from practice. Because stupid people work more slowly, they get the benefit of time for free, whereas smart people have to work at it.
December 19, 2006
Raph Koster Soars Without a Net: Areae.net
Raph Koster has his first startup: Areae.
Venture Capitalist (and Areae funding partner) Susan Wu has a great post that says many of the things about Areae that I wanted to, so rather than repeat them, I’ll just add a few things of my own.
Raph’s design pedigree is impeccable, but this is his first startup – and that introduces a whole new set of challenges. Dead (and dying) virtual world businesses abound. Worlds/Games with excellent design and technical execution can fail for lack of business focus, non-existent market research, decent marketing, competent management, financial prestidigitation, faulty timing, audience mismanagement, and more. It is a much larger mountain to climb, especially for the first time.
Yes, Raph will have more creative control than ever and no bureaucracy to slow him down. Huzzah! But, in exchange, he won’t have the same resources that he’s used to at his command. That’s why he’s got his board of directors and his advisors. I’m proud to be a member of that team. Though we are a much thinner safety net than, say, SOE, we do represent a broad set of industry experience. Some say I’m old and cranky and perhaps that is why Raph asked Richard and I to help: we grizzled veterans know where mayny dragons there be lurking in the wylds.
Thus girded
we head off
to discover
new worlds
together
once again.
Dusting off my questing clothes,
Randy
November 6, 2006
A Contrarian View of Identity — Part 2: Why is this confusing?
This is Part 2 of a multi-part essay on identity. Part 1 can be found here. Part 1 ended with a promise that Part 2 would be up soon, but, as John Lennon once said, life is what happens to you while you’re busy making other plans. But at long last here we are; enjoy.
Part 1 talked, in broad strokes, about the kinds of things that identity gets used for and why, but ended with the assertion that identity is being made to carry a heavier load than it can really support given the character and scope of the Internet. Here I’m going to speculate about why discussion of this seems to generate so much confusion.
One area of confusion is illustrated by a long-standing split among philosophers over the fundamental nature of what an identifier is. They’ve been chewing on the whole question of identity and naming for a long time. In particular, Bertrand Russell and his circle proposed that a name should be regarded as a form of “compact description”, whereas a line of thought promoted by Saul Kripke asserts that names should instead be viewed as “rigid designators”.
The “compact description” point of view should be one that is familiar from the physical world. For example, if you are pulled over for speeding and the police check your driver’s license, they consider whether you resemble the person whose photograph and description are on it. The “rigid designator” perspective is more familiar in the world of computer science, where we use such designators all the time in the form of memory pointers, DNS names, email addresses, URLs, etc.
Without delving into the philosophy-of-language arcana surrounding this debate, you can at least note that these are profoundly different perspectives. While I personally lean towards the view that the “rigid designator” perspective is more fundamental, this is basically a pragmatic position arrived at from my work with object capability systems and the E programming language. In the present discussion you don’t need to have a position yourself on whether either of these positions is right or wrong in some deep, essential sense (or if that’s even a meaningful question). All you need to recognize is that people who come at the identity issue from these different directions may have very different notions about what to do.
Another wellspring of confusion is that different people mean different things when they speak of “identity”. Moreover, many of them seem unaware of or indifferent to the fact that they are talking about different things. While I generally think that the Parable of The Blind Men and The Elephant is way overused, in this case I think it’s a wildly appropriate metaphor. Identity is a complicated concept with a number of different facets. Depending on which facets you focus your attention on, you end up believing different things.
Let’s look at the relationship between two entities, call them Alice and Bob, interacting over the Net. I diagram it like this:
We call them Alice and Bob simply because anthropomorphizing these situations makes them easier to think and talk about. We don’t actually care whether Alice and Bob are people or computers or processes running on computers or websites or whatever. Nor do Alice and Bob both have to be the same kind of thing. All that we care about are that each is some kind of discrete entity with some sense of itself as distinct from other entities out there.
When Alice interacts with Bob, there are (at least) four different distinct acts that are involved, each involving something that somebody somewhere calls “identity”. (1) Bob presents some information about himself, in essence saying “this is me”. (2) Alice, using this information, recognizes Bob, that is, associates the entity she is interacting with with some other information she already knows (remember that we said in Part 1 that relationships are all about repeated interactions over time). (3) Alice, to take action, needs to make reference to Bob. She designates Bob with some information that says, in essence, “that is you”. (4) Bob, based on this information, plus other information he already knows, accepts that Alice is referring to him and provides access to information or services.
At various times, various people have referred to the bundle of information used in one or another of these acts as Bob’s “identity”. However, there are four, potentially different, bundles of bits involved. These bundles can be considered singly or in combination. Depending on which of these bundles your view of things takes into account or not, there are fifteen different combinations that one could plausibly label “identity”. Furthermore, you get different models depending on whether or not you think two or more of these bundles are actually the same bits — the number of possibilities explodes to something like 50 (assuming I’ve done my arithmetic correctly), before you even begin talking about what the rules are. Absent awareness of this multiplicity, it is not surprising that confusion should result.
Observe too that this picture is asymmetrical. Most real interactions between parties will also involve the mirror counterpart of this picture, where Alice does the presenting and accepting and Bob does the recognizing and designating. Note that though the two directions are logical duals, the mechanisms involved in each direction might be radically different. For example, when I interact with my bank’s website, I present a username and password, while the bank presents text, forms, and graphics on a web page.
Those of you of a more technical bent are cautioned to keep in mind that I’m describing an abstract model, not a protocol. In informal discussions of this diagram with techie friends, I’ve noticed a tendency for people to latch onto the details of the handshaking between the parties, when that’s not really the point here.
This model now gives us a way to get a handle on some of the muddles and talking at cross purposes that people have gotten into.
Consider the many people making claims of the flavor, “you own your own identity” (or should own, or should control, or some similar variant of this meme). If you are focused on presentation, this makes a degree of sense, as you are thinking about the question, “what information is Bob revealing to Alice?” If you are concerned with Bob’s privacy (as Bob probably is, let alone what privacy advocates are worried about), this question seems pretty important. In particular, if you adopt the “compact description” stance on names, it seems like this identity thing could be probing pretty deeply into Bob’s private business. On the other hand, if you are focused on recognition, the “you own your own identity” idea can seem both muddled and outrageous. Recognition involves combining the information that was presented with information that you already know; indeed, in the absence of that pre-existing knowledge, the information presented may well be just so much useless noise. From this perspective, a claim that Bob owns his own identity looks a lot like a claim that Bob owns part of the contents of Alice’s mind. It should not come as a big surprise if Alice takes issue with this. Note that this is distinct from a political position which positively asserts that there should be (or believes that there could be) some legal or moral restrictions on what Alice is allowed to know or remember about Bob; there’s an interesting debate there but also a distraction from what I’m talking about.
Note that although the model is explained above in terms of just Alice and Bob, the most interesting questions only emerge in a world where there are more than two actors — if your world only contains one entity besides you, the whole question of the other’s identity is rather moot.
Let’s introduce Carol, a third party, into the picture. Setting aside for a moment discussion of what the identity relationship between Alice and Carol is, consider just the issue of how Bob’s identity is handled by the various parties. Recall that there are four bundles of information in the identity relationship of Bob to Alice:
- the information that Bob presents to Alice
- the information that Alice holds, enabling her recognize Bob from his presentation
- the information that Alice uses to designate Bob
- the information that Bob holds, enabling him to accept Alice’s designation
What is the scope of this information? Is the information that Bob presents to Alice meaningful only in the context of their particular two-way relationship, or is it meaningful in some broader context that might include other parties? In particular, is the information Bob presents to Alice unique to Alice, or might Bob present himself differently to Carol? If Carol already has a relationship to Bob, do Alice and Carol have the means to know (or to discover) that they are talking about the same Bob? More generally, which, if any, of the above listed four pieces of information does Carol see? Where does she get this information from? From Bob or from Alice or from some third (er, fourth) party?
Similarly, is the information Bob presents to Alice unique to Bob, or might some other entity besides Bob present the same information to her? In the latter case, is she really recognizing Bob or just some abstract Bob-like entity?
Each of these questions, and countless others which I didn’t explicitly raise or perhaps am not even overtly aware of, defines a dimension of the design space for an identity framework. The explosion of possibilities is very large and quite probably beyond the scope of exhaustive, systematic analysis. Instead, it seems more useful to pay attention to the purposes to which an identity system is being put. Any particular design can’t help but embed biases about the ways in which the designers intend it to be used (in and of itself, this is only a problem if the design has pretensions to universality).
I’m not prepared to go into all of these questions here. That’s probably the work of a lifetime in any event. However, there is one very important consideration that I’d like to highlight, which hinges on the distinction between the information that Bob presents to Alice and the information with which Alice designates Bob.
The presentation information seems naturally to fall into the “compact description” camp, whereas the designation information seems to just as naturally fall into the “rigid designator” camp. Indeed, the very language that I’ve adopted to label these pieces contains a bias towards these interpretations, and this is not an accident.
From Bob’s perspective, the information that designates him is far more dangerous than the information he presents. This is because a designator for Bob is the means by which an outside party acts upon Bob. Such action can range from pointing him out to other people in a crowd to sending him email to charging his credit card, depending on the context. Any of these actions might be beneficial or harmful to him, again depending on context, but Bob is fundamentally limited in his ability to control them. Presentation, by contrast, is more clearly under Bob’s control, and the risk posed by presentation information is closely related to the degree to which that information can be reverse engineered into designation information.
Much of the risk entailed by these interactions stems from the fact that in the real world it is rarely Bob himself who does the presenting and accepting; rather it tends to be various intermediaries to whom Bob has delegated these tasks in different contexts. These intermediaries might be technological (such as Bob’s web browser) or institutional (such as Bob’s bank) or an amalgam (such as Bob’s bank’s ATM). Such intermediaries tend to be severely limited in the degree to which they are able to exercise the same discretion Bob would in accepting a designator on Bob’s behalf, partially because they tend to be impersonal, “one size fits all” systems, but mainly because they cannot know everything Bob knows. Analysis is complicated by the fact that they may be able to compensate for some of these limitations by knowing things that Bob can’t. The ubiquitous presence of these intermediaries is a major difference between our modern, online world and the evolutionary environment in which our instincts for these things emerged.
Note that designation is generally associated with specific action. That is, there is usually some particular intent that Alice has in mind when designating Bob, and some specific behavior that will be elicited when Bob accepts the designator. This favors the “rigid designator” perspective: highly specific, with little tolerance nor use for ambiguity. In particular, different designators might be applied to different uses. In contrast, presentation may be open-ended. When Bob presents to Alice, he may have no idea of the use to which she will put this information. The information may, in some contexts, be quite general and possibly entirely ambiguous. This favors the “compact description” perspective.
All of the above leads to the following design prescription: these two bundles of information ought not to be conflated. In particular, Bob most likely will want to exercise much greater control over designation information than over presentation information. In any event, the contexts which these will be used will be different, hence the two should be separate. Furthermore, designation should not be derivable from presentation (derivation in the other direction may or may not be problematic, depending on the use case).
In Part 3 (about whose timing I now know better than to make any prediction), I’ll take a look at some of the more popular identity schemes now being floated, and use this model to hold them up to some critical scrutiny.
November 1, 2006
The essential paradigm of cyberspace
TerraNova discusses “How to Deconstruct Almost Anything”.
Again. :-)
Chip and I will comment there for awhile.
October 13, 2006
Playing Catch Up: Habitat's Chip Morningstar and Randy Farmer
Gamasutra has a wonderful article about the history of Chip and I working together (with many others) pioneering many modern social software products and features, including some great reminisces of The Lessons…:
“Today’s Playing Catch-Up, a weekly column that dares to speak to notable video game industry figures about their celebrated pasts and promising futures, speaks to the creators of Lucasfilm Games’ 1986 groundbreaking online Commodore 64 game/virtual world Habitat, Randy Farmer and Chip Morningstar.” more
It’s a mini-history of on branch evolution of social software from the time before the web and and insight into how we have worked together for more than two decades across many different companies.