Wednesday, November 17, 2010

Boycott KLIF's Advertisers?

So i just got finished listening to some of Chris Krok's broadcasts for KLIF radio in North Texas:
After a bit of outcry, he later issued an "apology" in which he defended his right to have an opinion on what is said in Ft. Worth Council meetings. His apology did not extend to incendiary remarks he made about LGBT persons and his antagonistic attitude towards the LGBT community. (And personally, I think his comments were pretty disrespectful of Mr. Burns, his district and of Ft. Worth.)

It's pretty clear he's using queer-baiting as a professional ploy. He moved from Chicago to Madison to Minneapolis (the latter two being relatively liberal) to Atlanta to D/FW in search of a market where he could sell his agenda of discord. The guy is clearly pandering to angry right-wing listeners, trying to boost his ratings by being "shocking." His tired schtick is grating and relatively unpleasant, but I'm comforted to know his audience only supports a part-time AM radio listenership. Seriously, there are probably internet podcasts with larger audiences.

Still, his whole queer-baiting act is unworthy of KLIF radio, and the guy will get dropped once the old guard that still go for that kind of vitriol die off. LGBT folk come from all walks of life and have significant economic clout. Sure, maybe we have more organized political muscle in San Francisco and New York than we do in Dallas, but the bottom line is this joker is making coin by disrespecting me, my family and my friends. LGBT individuals have made significant gains in mainstream acceptance in the last couple of decades, but let's not kid ourselves about this, there are still people who have nothing better to do than get worked up over who's sleeping together.

I think this kind of message is on the way out; but we can accelerate its departure by contacting KLIF's advertisers and letting them know we do not appreciate their support of programming that is demeaning of us personally or advocates a political agenda that disenfranchises us. So... anyone who wants to start taking shifts listening to KLIF and noting the names of their advertisers is welcome to join me.

If you happen to find yourself listening to KLIF, tweet the name of the advertisers with the hashtag #klifads. Include contact info for the advertiser if you have it. Every couple of days come back to twitter, search for the hash tag and call the advertiser to remind them they do not want their product associated with Mr. Krok's message.

Also, you may want to contact Mr. Krok's supervisor at KLIF directly and let him know how disappointed you are with Mr. Krok's comments on-air. His name is Jeff Catin. He can be reached at +1 214 526 2400 and his email address is jeff.catlin@cumulus.com. Please remember to be respectful of Mr. Krok and Mr. Catlin. They may have opinions we disagree with, and they may be making money peddling a message of hate, but we have the moral high ground here. We'll lose if they can drag us down to their level.

On The Dangers of Depending on a Single Provider

Yesterday I encountered a bit of a shock when I attempted to log into Second Life. Rather than seeing the familiar setting of my in-world beach house, I was greeted with a rude error message. "Login Failed. Second Life cannot be accessed by this computer. Contact support@secondlife.com."

"Ugh," I thought, "another error in an error-filled day." I had recently modified my settings.xml file to accomodate the weird screen size of my laptop and was convinced I had somehow managed to hork my settings to the point the viewer couldn't figure out which way was up. But after issuing the command `rm -rf ~/.secondlife` to perform a second life settings labotomy failed to clear up the problem, I started to get worried. Thinking my client install had somehow gotten horked, I re-downloaded and re-installed the linux client. Still no love.

At this point I sort of paniced and thought I had been permabanned. Fortunately friends were around to remind me to try to login from other machines. Fortunately, I could log in from the ancient iBook G4 I still have laying around the office running an old copy of viewer 1. After downloading viewer 1 to my main machine and trying to log in, still no love.

For whatever reason, my ID0 or MAC had been banned.

Something was seriously horked here, so I did what you're supposed to do in situations like this: I emailed support@secondlife.com like it says to do in the error dialog. In a few moments I got a response back saying that even though the client told me to send them an email, I'm really supposed to use a web form to file a ticket. After filing a ticket and getting confirmation from Linden's automated support tracking system, all I could do was wait.

While waiting, I found some Second Life Forum discussions about exactly the same problem. Apparently back in the old days this would happen from time to time and after about four hours after filing the ticket, someone would get to it and unban them. So I waited.

I'm a bit lucky in that I have a few support resources that most Second Life residents do not. As a former Linden, I have several personal friends who still work at the lab who were able to confirm that there's nothing on my account "rap sheet" that would indicate my account had been banned (we knew this already). The weird bit is there was no record of my IP address or my MAC addresses being banned either.

Yay! Random weirdness.

So I wait and wait and wait. This morning it's still not resolved so I send an email to a friend at the lab jokingly suggesting this is Linden's way to prevent me from attending virtual world standardization meetings in-world. Let me just stop here and say that while it's fun to let paranoia sweep you away and imagine a consipiracy to prevent you from doing your work in world, it's probably not accurate. Remeber the saying.. "do not attribute to malice what could easily be attributed to incompetence."

Rather than there being a conspiracy to keep me from logging in, here's what probably happened... When you log in to Second Life, your client sends a couple of numbers that uniquely identify your PC: the MAC address and the ID0. These values are used to identify the PCs of griefers, scammers and generally bad people. This is one of the reasons I was surprised to get the ban hammer. What the heck had I done to warrant banning?

MAC addresses and ID0's can easily be spoofed; "bad guys" do it all the time. And probably what happened is somewhere out there a random griefer picked a random ID0 and got caught. The random ID0 they picked happened to match mine and when they were "banned," Linden added the spoofed ID0 to the black-list. Once the "bad guy" in this story couldn't log in with my ID0, they probably picked a new one at random and went back to griefing. I, on the other hand, was left unable to get in-world because it's a violation of Linden's acceptable use policy to spoof these values. You're supposed to resolve the issue through the support center.

So you see what's going on here, right? Linden is using a technical mechanism to enforce a decent policy. But the only people punishes by its enforcement are legitimate users who don't spoof the second life servers.

After working my personal connections inside the lab, I was able to get this issue resolved. But I can't help but wonder what people who are NOT former lindens do.

So let me try to wrap this up with this thought: doing business in Second Life is unnecessarily risky. While it's a wonderful platform for people to express themselves and it's a great, social immersive experience, the policies that govern this virtual world are a bit wonky. And they're likely to stay wonky for the near term.

As messed up as Second Life is, it still has some great things going for it: lots of participants and lots of bling you can buy to name a few. But at the end of the day, if you run a business in Second Life, you are dependent on an external for-profit organzation for your bread and butter. In the 2D-web world, services are neatly interchangable. If you don't like Google's privacy policy, you could get an account at Yahoo! or Hotmail. Or at your local ISP. Or if you knew what you were doing, you could build your own email server. Ditto for other basic web services,

But you simply can't do this with Second Life because Linden owns the service definition. Not to mention, they've got a great head-start against potential competitors like InWorldz and ReactionGrid. Both are great services offering experiences that are more or less the same as Second Life, though with a significantly reduced community. Owners of virtual businesses stick with Second Life in spite of it's seemingly random behavior because "that's where the money is."

When we chartered VWRAP, our objective was to create a truely open virtual world ecosystem. The protocols we worked on were intended to be implemented by a wide array of participants allowing Second Life to grow beyond it's "walled garden" beginnings. By opening the virtual world up to potential competitors, Linden risked short-term reduction in revenues from land sales, but could have participated in a "3d web" that was more attractive to businesses (and educators and ...)

VWRAP is now effectively dead. The HyperGrid lobby may try to recharter VWRAP to focus on HyperGrid, but it's an implementation rather than a protocol. The IETF is sort of allergic to these types of efforts; taking a protocol implemented by a single product and "blessing" it as "the" standard. And with due deference to the activities of ReactionGrid and InWorldz, the larger business community is probably not interested in risking an investment in a protocol with a single implementation. (Thankfully, there are enough bleeding edge users out there that RG and IW can probably survive.

But at the end of the day, when you depend on someone else for technology, you depend on their business remaining stable enough to support your business until you've recovered your investment. This is why Linden makes a lot of people nervous. Sure, they have to adapt to changing business realities, but it's irritating when they behave seemingly randomly. It's even more irritating when you realize that it's their economy you're playing in.

And this is why dealing with OpenSim grids is irritating. You wonder if they're going to be around long enough for you to recover your investment in their economy.

Clearly it's not so irritating that I don't involve myself in their use and development. But I think I'm likely to be cranky and irritable 'til... well... until Second Life and Reaction Grid are dim memories (like AOL and Compuserv) and their creators move on to more profitable open virtual ventures.

[author's note: Kyle, Robin and Chris, who are employees of Reaction Grid have protested in the comments below. I think there's some validity to their comments. I was unclear in that last paragraph about what I wish goes away. For the record, I TOTALLY love what Kyle &co are doing at Reaction Grid (the company). I have nothing but best wishes for Reaction Grid (the company). What I wish goes away is the concept that you can only make money in virtual worlds if you're a "grid operator." That is, I hope we land in a future where "the grid" as a concept goes away and is replaced by a cluster of services that implement a virtual world. I hope Reaction Grid (the company) or Reaction Grid (the community) or Reaction Grid (the collection of virtual locations) all have a prosperous future. I do, however, hope that Reaction Grid (the artificially walled garden of content and identity) evaporates in the future. Given Reaction Grid's (the company's) support of HyperGrid and OpenSim, I believe they share that goal. This meaning was pretty obvious in my head when I wrote that last paragraph, but clearly it was unclear. I apologize to Kyle, Chris and Robin for the confusion.]

Monday, November 1, 2010

fun with sl8.us

so i've been playing with the sl8.us URL shortener-redirector for a bit and have figured out a few fun applications. (for peeps that don't know about it, the sl8.us redirector shortens second life URIs like secondlife://Meyers/171/13/48 and converts them into http URLs like http://sl8.us/mHcs48A9P, that redirect you into Second Life.)

sl8.us was originally intended to shorten SL URIs so they could be easily included in tweets. so the first obvious application is to tweet your location. i've been using it to tweet about interesting in-world locations. you can search for shortened URLs on twitter by searching for "sl8.us" to see locations other people find interesting.

you can shorten a URI by visiting the social avatar site or by using the in-world HUD that shortens (and optionally tweets) your location. (you can get info on it's installation and use at the HUD intro page at sl8.us.)

the in-world HUD lets you "mark" a location for url shortening or look to see who else has been making marks in your current location.

but something more convenient i've found is the ability to bookmark in-world locations in my web browser and online tools. some social bookmarking sites barf on secondlife:/// URIs, so having a http:/// URL that does the same thing is rather convenient. i've added a list of locations i visit frequently in-world to my browser bookmark bar. it's nothing major, but it makes SL a little more "fast." i'm kind of surprised linden hasn't tried to roll out something like this.

Friday, September 10, 2010

announcing project brookdale

this is a quick post to announce "project brookdale," an open source implementation of the Virtual World Region Agent Protocol (VWRAP) suite. VWRAP is a collection of specifications produced by the IETF's VWRAP Working Group. these specifications define interoperability for a "second life-like" virtual world. you can find more information about VWRAP on my VWRAP Page or the blog post "what's the virtual world region agent protocol?"

project brookdale will produce PHP, JavaScript and C/C++ middleware that manages protocol interactions. it is not, in and of itself, a complete virtual world implementation. it is instead designed to be used to simplify the development of VWRAP compatible tools and services. this division is not completely unlike the division between libomv and OpenSim.

here's a quick list of things you'll find in brookdale:

Dynamic Structured Data (DSD) and HTTP Transport Bindings

"DSD" is an evolution of the previous LLSD and LLIDL abstract type system and interface description language. the main difference between DSD and LLSD are minor changes in the XML serialization and a "layered" approach making it easier to use VWRAP messages with non-HTTP transports. more information about the motivations behind DSD can be found in a "abstract resource definitions vs. LLIDL". the internet draft draft-hamrick-vwrap-data-00 describes DSD in more detail.

one feature desired by implementers of previous OGP and early VWRAP work was clear guidance or agreement for how to handle content negotiation and caching of VWRAP messages carried over HTTP(S). draft-hamrick-vwrap-foundation-00 builds on the previous work and describes the use and interpretation of HTTP headers and status codes for content negotiation and caching.

project brookdale provides PHP and JavaScript classes and C functions implementing the interface semantics of DSD. it allows web and application developers to easily manipulate VWRAP requests, responses and events.

a capability management facility and capability broker

web capabilities are an integral part of VWRAP. they allow distributed, trusted systems to grant fine grained access to sensitive resources without a global identity management system. an informal introduction to capabilities in VWRAP can be found in the earlier blog post, "VWRAP essentials : capabilities".

capabilities serve as aliases for RESTful VWRAP resources. composed of a cryptographically unguessable URL, they combine authorization to access a resource with that resource's address. the "capability broker" is the system component that maps a URL managed by a system to the object or database row it represents.

a simple VWRAP event queue over long poll

the VWRAP event queue is a simple abstraction for unsolicited server to client communication. VWRAP currently reifies the event queue as a "long poll" over HTTP. it is hoped that future work will specify the use of WebSockets as a carrier for VWRAP events.

simple connection manager with trust model support

trust between components in a VWRAP system is established by asserting identity using an X.509 client certificate. the VWRAP specifications do not require systems to trust any particular entity or certification authority, but they do require entities accept connections that use client side certs. in other words, a VWRAP system is free to ignore X.509 credentials from a client, but it must not disallow clients from sending them.

one ramification of the VWRAP trust model is it requires a "trusted" service to potentially present a destination-dependent certificate to a remote peer. an authentication service, for instance, may identify itself to an asset service by presenting it with a certificate issued by the asset service (or a trusted third party certification authority.) the brookdale connection manager maintains a mapping between destination URLs, client certificates and their related private keys.

VWRAP Authentication (including OAuth support)

VWRAP defines several "native" authentication technqiues as well as the use of OAuth in protocol transactions. the brookdale authentication components manage the process of user authentication and the seed capability lifecycle.

Client Application Launch Message processing

the VWRAP client application launch message (CALM) is an optional message sent to a web browser with specific details of which servers a client application (like the second life™ viewer) should contact to complete the login and rez process. intended to be used in conjunction with web authentication and authorization schemes like OpenID or OAuth, brookdale contains PHP, JavaScript and C functions to generate and process calm messages.

we're starting by publishing a few PHP and JavaScript files at the project brookdale page. these files are much more "middleware-ish" than they are "application-ish," but more will be coming in the next week.
the release of the code corresponds with the latest VWRAP abstract type system proposal. more code will be released at the brookdale site as the newer VWRAP drafts are published this month.

Thursday, August 26, 2010

net video startups, you don't get me

one of the great things about being me is i have a bunch of friends who work for startups in sili valley and i sometimes get invites to beta their wares. i work as a software developer instead of a marketing guru, so peeps frequently invite me to look at things late in the development process, usually to show off their technical mastery.

and i have to admit, i'm usually impressed. there's a lot of cool tech going on in the valley at the moment (even though we're in the middle of a double dip economic downturn.)

but i'm now a single co-parent. my extra time and cash goes into my family life and a college fund for the offspring. so if you want me to subscribe to your service (or buy your latest tablet) you have to show me some pretty clear value.

i had a netflix subscription until i realized i could easily replace my netflix use with hulu and redbox. and my hulu use is pretty minimal. i tried to watch lost and heros, but just couldn't get into them. i LOVE eureka and my son loves the clone wars. between my son and i, we consume about 2.5 hours of traditional televison content per week. the rest of our packaged video entertainment time is maybe 3 hours of movies per week. and when i remember to do it, i watch john stewart's daily show.

the rest of our inside entertainment time is spent playing video games (maybe an hour per day in the summer, but about two hours per week during the school year if all our homework gets done on time.) i spent a couple hours per week in second life or one of the independent OpenSimulator virtual worlds.

and i watch a metric boatload of youtube videos. i can't get enough dancing cats. i consume my media on my computer; but i would LOVE to watch videos on my TV. right now the only thing i use it for is to play DVDs and vintage nintendo games.

from talking with my peers, it seems like the main difference between me and other people is that the ratio of TV programs to youtube videos is a little bit skewed.

so i'm always surprised when companies like apple, sezmi, boxee and hulu try to shove "premium content" down my throat. i would rather wedge sporks in my eyeballs than watch most sitcoms. i won't pay to watch friends reruns or current episodes of two and a half men.

i would actually pay to watch google tech talks and nova on my TV (instead of my computer.) but i don't think i would pay much.

on thing that fascinates me though; watching movies online with friends. i used to work for the people that made second life, so it shouldn't be a surprise i have some social contacts "in world." one thing i really enjoy doing is getting a group of people together and watching a movie inside the virtual world. sadly, there's little content legally available.

the other evening 200 of my closest friends and i watched a broadcast from within second life on treet.tv. the program was obviously supported by advertisements, and i hope the treet.tv folks were able to charge enough in advertising to cover their streaming costs. the particular show, which dealt with weirdness in the emerald viewer community, had a very focused audience. if i were running ad sales at treet.tv, i would have charged a premium for the ads during that hour (due to the larger than average market,) and tried to find ads targeted towards content developers, super-users and open source developers.

i guess what i'm thinking here is there may be a "long tail" play here in internet video. youtube has part of this niche, but what i would LOVE to see is a ROKU or Nintendo video channel for "interesting science and technology programs." i have a nice television set i would like to use. but i don't want the hassle of a complete windows media center PC. i sure as heck don't want to browse the web on my TV. and i'm totally down with the idea of configuring my device on a web page i access via a desktop or laptop computer.

but the main thing i'm interested in is "watching TV with my online social network." i would love to have a "geek tv channel" that i program, that i invite my friends to view with me. i would populate the channel with live video broadcasts from the web: treet.tv, kink on tap, google tech talk reruns. i want to watch the video on my TV, but have a group text or voice chat session on my laptop.

i'm not so conceited as to think this is "the future of television," but i have to think it's closer than someone trying to sell me friends reruns for $20 per month.

Wednesday, August 25, 2010

VWRAP essentials : the event queue

this week on VWRAP essentials, i wanted to talk about the "VWRAP event queue." in the world of second life(tm) viewer development, the term "event queue" has a very specific meaning. it is a set of data structures, functions and UDP message types that communicate events from servers to clients. that's not what we're talking about here.

VWRAP is intended to be an application layer protocol that can be carried over multiple transports. implementers MUST support transporting VWRAP messages over HTTP(S), but there's been a lot of interest in optionally moving some traffic over XMPP and RTP. so defining anything in terms of HTTP is sort of a problem for VWRAP.

instead, we define an abstraction and then define a bunch of ways the abstraction can be reified by network protocols of real software. the VWRAP event queue is an application layer abstraction for a facility that delivers arbitrary, unsolicited messages to a network peer. in other words, the event queue delivers messages from servers to clients without a specific request from the client.

this is a general problem with interactive web applications as well, and a couple solutions have surfaced in the web community. embedding flash or java content in an HTML page is one solution. plugins for these technologies are readily available for popular web browsers. but VWRAP doesn't use HTML, and it certainly doesn't use a web browser.

another popular technique is "the long poll." interactive web apps implement the long poll by using the JavaScript XMLHttpRequest object to query a specific URL on the server. if the server has nothing to say to the client (i.e. - there are no unsolicited server to client messages) the server just waits, leaving the connection open. as soon as it has something to say, it delivers the message to the client. the client processes the event and queries the poll URL again, waiting for the next message. this technique is simple, but can be wasteful of resources in some programming languages.

more importantly, it's a hack. in a RESTful world, where accessing resources of HTTP is supposed to be idempotent, the idea getting something different each time you access a resource seems somehow unclean.

but there's an emerging standard for how servers should push streams of unsolicited data down an HTTP connection. it's called WebSockets. it's not without warts, and will require a little retooling of some of the web's infrastructure. it didn't include every feature that everyone wanted, but there's general agreement that it's "good enough" and is much better than using the long poll.

VWRAP could have defined the event queue in terms of WebSockets, but at the time it wasn't clear WebSockets would become "the" standard. it may also require some amount of tinkering with the infrastructure to implement, so it's not entirely clear WebSockets will work everywhere all at once. it's also possible that some organizations may be behind aggressive firewalls that will block WebSockets,

for all of these reasons, the VWRAP designers decided to create an "abstract" event queue that could be reified by sending messages over long poll or WebSockets.

the current foundations draft only defines the event queue over a HTTP long poll. future versions will describe it's use over WebSockets.

Tuesday, August 24, 2010

does the linden third party viewer policy sidestep the issue?

the second life community has spent the last week following a reasonably important controversy now referred to as "emeraldgate."

if you're a member of this community, it's hard not to have heard about it. for the benefit of those people who don't follow second life closely, here's a brief backgrounder.

so linden lab has this virtual world called second life(tm). the state of the virtual world is held on servers operated by linden. these server remember things like where people and things are, who owns what, and what direction things are moving, etc. second life users access the virtual world using a "viewer application." the viewer communicates with lindens servers and renders information from them in a nice 3d scene on the users' personal computer.

to spur innovation in virtual worlds, linden open sourced it's viewer software a couple years ago. several teams started adding new features and fixing bugs linden was slow to address. one of the single most popular "third party viewers" was a project called "emerald."

we recently discovered that the emerald viewer has been doing some "bad things." for a couple months people have noticed some weird encrypted data being sent from emerald installations. turns out it's information about the client's PC. granted, the emerald viewer isn't trying to sift through your hard drive trying to find credit card numbers, but the information it leaks (user name and emerald executable location) could help skilled bad guys compromise emerald user's systems.

very recently people discovered a distributed denial of service (DDoS) attack being launched by the emerald viewer. blargh! thousands (if not tens of thousands) of users were unwittingly being co-opted into attack on the rival of one of the emerald developers.

needless to say, a lot of people are beginning to question emerald's ability to manage their developers and produce quality software. twitter and facebook are filled with status updates from users saying they're ditching emerald for linden's official viewer or another third party alternative.

the most recent entity to weigh in on the issue is linden themselves. philip rosedale, linden's CEO published a quick blog post on the issue: Malicious Viewers and Our Third Party Policy. linden is removing the emerald viewer from a directory of third party viewers linden maintains. the "third party viewer directory" is a list of viewer applications (most of which are based on linden's source code) which purport to be essentially well behaved.

emerald's removal and rosedale's blog post were not surprising; the emerald viewer did a couple of bad things they should have known were bad. the lab's actions are hoped to distance the second life service from a few bad developers.

the good news is that some of the old emerald team is reforming and will be trying to build a project where "bad things" like what came to light last week can't happen. we'll see if they can convince their user community and linden of their ability to follow through. the jury's still out on this issue; but it's early in the project cycle so it's anyone's guess how this all resolves itself.

but there is one aspect of this crisis that bugs me: why do we need a third party viewer directory in the first place?

to understand why there's a third party viewer policy and a third party viewer directory, you have to understand a little about the second life virtual world. second life is frequently described as "the 3d web," but there are some notable differences between the web and second life.

first off, second life is not "open" in the broadest sense of the term. the lab has done some wonderful work open sourcing the second life viewer and supporting the ecosystem of third party viewer developers. but the limit of their openness is to release the source of the viewer. this creates the unsatisfactory situation where the protocol used to communicate state of the virtual world is owned by a single entity capable of making unilateral changes.

in the web browser development world, core standards like HTTP, WebSockets and even JavaScript are defined by industry standards coalitions. linden did support the VWRAP effort to develop open standards, but withdrew support for the standard and laid off the staff responsible for it's implementation in the lab.

but maybe one of the most important differences between second life and "the web" is the idea of content. on the 2d web, content is embedded only in the place. it is rare for content to follow a user around from site to site. yet this is the moral equivalent of what's going on in second life when you move your avatar from one location to the next. when you see other web users, it's usually as an image icon right in front of some text. second life users know that their avatars are much richer and more varied. second life users are represented in world as collections of shapes, skeletons, meshes and textures.

and this brings up the next major difference between the virtual world and the web: content protection seems MUCH more important in second life. don't get me wrong, i'm not trying to discount concerns of content thievery on the web. but the web's business model is that content "lives" on a web page and isn't supposed to move. in the virtual world, content creators sell content to individuals with the intent they'll move from place to place.

and it's this expectation of content content control that lies at the heart of the third party viewer policy (and directory.) were second life like the web, content creators would sell content to people and be done with it. but the primary technique for monetizing content on the web is to sell advertising next to it (or sell memberships to content that remove invasive ads.) the web seems to reward content that persists in one location long enough to be indexed by google or microsoft.

tracking down DMCA violations are pretty straight-forward when you can refer to the google cache and the internet archive.

but not so for the virtual world. in second life we rarely extract value by advertising. sure, linden is happy to take a cut when you search, find and buy something from xstreetsl, but the full content is not available on that site for bad guys to purloin.

content creators in second life make their living from selling their goods directly. there's a marketplace here for goods because, quite honestly, the direct cost to users is pretty low. for about the cost of a discount cola from my grocery store, i can purchase a very fashionable outfit for my avatar. for the cost of a latte, i can purchase a complete meeting center to hold virtual meetings with friends or co-workers.

revenue on individual sales are low, but the distribution and copying costs are effectively zero for content creators. the primary costs for second life vendors are non recurring production costs and the cost to maintain a store front. but with xstreetsl offering people a web experience to discover and purchase goods, the "real" costs of doing business in second life boil down to paying yourself for the time you put into building something.

and this is why "less than moral" actors in the virtual world fall to temptation. it's laughably easy to copy someone's work, repackage it as your own, and sell a few on xtreetsl before anyone notices what you're doing. why bother going to the trouble and expense of actually making content when you can just steal it?

in the web world, this content would likely not be of any use to you until it's been optimized and indexed by google's search engine. if you were a purveyor of purloined content on the web, the same tool that provides you the ability to monetize your stolen content is the tool that lets content creators detect your theft.

but search in second life is "sub-optimal" and advertising has been effectively quashed in the interest of user experience. it turns out that people don't want to wander around a virtual world filled with billboards.

the second life economy is dependent on scarcity. there MUST be some scarcity in content community's creative output in order for the virtual goods market to work. but these are digital goods we're talking about, and it turns out that if you're reasonably handy with a C++ compiler you can quite easily make illicit copies of restricted content.

left unchecked, high margin content would be hoovered out wholesale and sold at discount prices by IP thieves. at the end of the day, there is very little linden lab can do about this from a technology perspective.

if it can be rendered on your screen, it can be saved on your hard drive and later re-uploaded. this is the main reason you'll frequently hear people say "put all the value of your content in your scripts." LSL scripts are the only bits of content that are not downloaded to the client. bad guys can't easily copy them with hacked client software.

it turns out that yes, bad people are making a living off stealing other people's content. and there's little that can be done to completely eliminate it. the linden third party viewer policy is an attempt to slow down the dissemination of tools that make content theft easy.

it's a great idea, and i think linden is demonstrating the best possible motives here. but we have to be realistic about what the policy can and can't do.

it is extremely difficult to craft technological prohibitions that will keep all the bad guys out. client IP addresses are rarely stable for long periods of time and the "bad guys" have already figured out how to hack the client software to present fake MAC addresses and viewer strings to the second life servers.

but what _is_ a little easier to do is to crack down a little on the distribution of software with illicit intent. linden's third party viewer policy tells the community what third party software can and can't do and still be considered "virtuous." the third party viewer directory gives users a list of viewers made by people who have promised to honor that policy.

and what's at the core of emerald gate is not that the stock emerald viewer is being used to steal content, but that it was doing things with encrypted messages that made it difficult to figure out if it was stealing content as well as coercing user's PCs to behave in a "bad" way.

so given the current state of the world, and the fact that it would likely be economic suicide for linden to abandon it's content creation community, the third party viewer policy makes a lot of sense.

there is still an open question about "walled gardens' like second life. one can certainly imagine a service where content flows easily in and out of the virtual world. where content doesn't live on linden servers, but lives on public (or semi-public) web servers. the value of the content is not in it's raw bits, but in the way it's marketed, aggregated and distributed.

maybe in future virtual worlds value will derive from creator reputation and recommendation in social networks. maybe the future will see a world of abundance where value and monetization potential is extremely ephemeral.

but we're not there yet, and that's why the third party viewer policy is a necessary evil.