Thursday, March 18, 2010

Viewer To A Kill

Linden Lab has released a beta version of "Viewer 2.0," what's been touted as a huge ground-floor revamp of the Second Life client experience. The client has been in the works for some time, and reportedly represents the Lindens' best efforts to bringing the client interface into the current decade, more tightly integrate with the so-called "social Web," and add some major new features that try to bring a bit of the Internet in to the virtual world. Anyone with a Second Life account can download the beta and give it a whirl.

Linden Lab's Viewer 2.0 beauty shot

I'm not going to "review" Viewer 2.0, or even run through a bullet list of positives and negatives—plenty of other people are doing/have done that and, really, my opinion doesn't matter. Bottom line, Viewer 2.0 has remarkably few new features; however, one is a humdinger: "shared media" or what's commonly called "Web on a prim." With Viewer 2.0 just about any surface of any object in the virtual world can be turned into a completely functional Web page. This has mammoth implications for educators and content creators—for instance, almost anything on the Web can be brought into SL, Flash can be used instead of craptastic animated-GIF-style texture animations, etc. However, it also has profound privacy implications, a couple of which I'll detail below.

I dove in with Viewer 2.0 so quickly because the world of Second Life viewers is getting very complicated—more on that below—and I had hopes that perhaps Viewer 2.0 would represent a major re-conception of a Second Life client. I'll just say it right now: Viewer 2.0 does not represent a fundamental paradigm shift for Second Life clients. Viewer 2.0 does represent a substantial "reskinning" of the Second Life client, and that in itself says something about what the creators and operators of Second Life feel is important and what is not.

Rear Viewer Mirror

The Second Life client software situation is complicated, and I'm kind of talking out of my ass here because, apparently, no one who is in-the-loop can be bothered to write anything down for the rest of us. So some of my facts here may be jumbled because I can't seem to find any authoritative sources, and ones I've talked to who claimed to be kind of semi-authoritative on parts of it don't really agree on the details.

The Second Life client software started off as a proprietary application, albeit built using OpenGL, a cross-platform technology for handling 2D and 3D graphics. OpenGL is how everything gets put on screen in the SL client, from buildings and avatars to windows, menus, and buttons. (That's also why SL doesn't use proper windows or controls for your operating system.) Around 2006 some folks got the idea to reverse-engineer the way the Second Life client and server talk to each other in order to make different applications to connect to the Second Life grid: the result was libsecondlife.

Libsecondlife was seemingly well-intended and apparently received some unofficial(?) Linden support. The idea was to enable people to create things like text-only SL clients, to let computers do stuff only avatars can do (like receive IMs, act as in-world persons, etc.), and (perhaps most significantly) back up your creations. Second Life is kinda unique in that if you build something in-world, it's your intellectual property: you have copyright, you can sell it, and it's yours. When I make an original piece of jewelry in Second Life, I not only own the virtual prims that compose it, but the intellectual property for its design and functionality. The problem, of course, is that my property only exists in SL: if SL hiccups (or gets attacked by giant robots or goes bankrupt) my property goes with it. So being able to back up my own stuff—something the standard SL client won't let you do—seems like a nifty thing.

One problem: libsecondlife led directly (and pretty quickly) to the creation of CopyBot, software that connects to the Second Life grid, ignores Second Life's built-in permissions system, and enables users to make copies of…well, almost anything. Textures, prims, avatar skins, hair, shoes, eyes, clothes, houses, trees, plants, space stations…basically, if you can see it in SL, CopyBot could nab it. (And CopyBot was hardly a secret: it was apparently published in public SL forums for months.) Some CopyBot users immediately set up shop, ripping anything they liked, then re-uploaded it to Second Life as their own property. That's a good way to get stuff cheap. It's also a good way to make money, selling knockoffs of high-$L items for a fraction of the original price to unsuspecting residents. Barring security loopholes (and there have been a few), about the only thing safe from CopyBot are LSL scripts. LSL scripts execute on Second Life servers: they're never sent to the client, so they can't be copied by a client.

Of course, the existence of things like CopyBot kind of cuts Second Life content creators off at the knees. Make something cool? Sooner (not later) someone is going to copy it and start selling or giving away the ripped versions, often with full permissions so they can be passed around indefinitely. And because everything is digital, all the copiers have the same means of production and distribution as the original creators.

To be sure, CopyBot wasn't the only piracy tool used in Second Life at the time: it was just the center of a big furor. (Another common way of stealing textures was/is GLIntercept, which works with the normal SL client.) CopyBot hasn't really gone away, but it's now kind of a generic term for any software which can steal client from Second Life.

Open Wide and Say "Argh!"

Linden Lab's response to CopyBot was interesting. In late 2006, they declared (well, re-iterated) use of CopyBot and things like it as violations of Second Life's Terms of Service and promised support for Creative Commons licenses, improved ban lists and reputation management, etc. to help content creators cope. It's now 2010 and I don't see any of that last part, but I only started in SL about a year and a half ago so maybe I can't see the forest through all the trees.

Another action has had bigger ramifications. The Lindens seemed to the think legit uses of something like libsecondlife (like backing up your own property, creating new kinds of clients, etc.) were worth pursuing—more clients ought to spur broader adoption of the platform, after all. The Lindens could have broken libsecondlife (and with it, CopyBot) by modifying their client and server protocols so libsecondlife it no longer worked, but doing so would be to engage in an arms race: the Lindens would alter the protocol to defeat CopyBot, the CopyBot fans with their packet analyzers would work around the fix, and the whole cycle would start again. The result would be forcing users to constantly update their Second Life clients (and at 70 MB or so for each download, that's is a pain in the butt!) along with grid instability as Linden Lab continuously rolled out new server software (across thousands of sims!) to fight off CopyBot. That arms race would quickly deteriorate the Second Life platform.

So the Lindens chose to zig instead of zag: in early 2007, they made the Second Life client software open source. Anyone who wants to make their own Second Life client can start with the Lindens' own source code. Now, not every single line of the SL client is in the open source—there are some unpublished "third party" components Linden Lab says are proprietary (e.g., Vivox's VoIP voice technology)—but the principle is there: if you think you can make a better SL client, go for it. According to the Lindens, part of the goal of open-sourcing the viewer is to "accelerate the development of new features, the resolution of bugs, and enhance the security for all residents." [Sic on the parallelism problem there—I didn't write it I'm just quoting.]

And people have jumped into the code. At this point, more than two dozen alternative third-party viewers are listed on a maybe-official-can't-really-tell alternative viewers page. Some of these are text-only clients; some are lightweight clients aimed at iPhones and other mobile devices; some are full-fledged viewers with heaps of added and modified features; some are high-end viewers pushing SL graphics to the limit. Linden Lab even has its own open source viewer, dubbed Snowglobe, which aims to introduce features (and roll in bug fixes from the Open Source community) faster than the mainstream viewer.

So far, the most popular third-party viewer on the grid is Emerald. The Emerald viewer represents a kind of "power-user" version of the standard Second Life client that pulled together features from a number of other more-specialized third party viewers and heaped more on top. Popular features in Emerald include things like a built-in radar of nearby avatars, command-line-like capabilities in the chatbar, building enhancements, "clothing layer protection" against content thieves, along with a bunch of other enhancements, like the seemingly-wildly popular "breast physics" feature that makes female avatars' breasts…well, you know. Emerald has earned a strong in-world following owing to features appreciated by power users, along with regular updates and enhancements—of the third-party viewers, Emerald is the one that seems to be making the most effort to keep quality high and communicate with its user base.

Of course, as with libsecondlife, there are people taking the open-sourced code and using it to make their own viewers with nefarious custom tools. You won't see them listed on Linden Lab's list of third party viewers, but things like Chocolate, ThugLyfe, Cryolife (seems dead), ShoopedLife, HXO-Life, and NeilLife are out there if you know who to ask (or who to pay). They all offer tools oriented towards griefing, ban evasion, and outright content theft. Still other viewers—often claiming to be Emerald—are directly malicious to their users, acting as Trojans to infect users' computer with worms or viruses, and (quite probably) stealing users account names and passwords so their Second Life accounts—and Linden dollars—can be accessed. Some of these viewers are based off Linden Lab's own code base…but, of course, many use the Emerald code base as their starting point. (Under the GPL license on the official Second Life viewer, the Emerald team must also publish its source code.) And there appears to be no small irony here: although I haven't tried to fully untangle the threads of multiple avatar identities, forum handles, writing styles, and signoffs, it seems pretty clear that Emerald's development team includes (or has included) the creators of the original CopyBot and at least the content-theft-enabled Second Life viewer Vlife.

So, the net result is what I'll politely call a fetid cesspool of viewers that are capable of connecting to the Second Life grid. Some of them are well-maintained and well-intentioned, others are not, and there's no real way to for an average Second Life user without +5 Wand of Geekery to discern the differences between them. In an effort to alleviate that confusion, last month Linden Lab published a Policy on Third-Party Viewers. The actual text contains a lot of contractual language, but basically it requires third-party viewer developers assert their software conforms to a set of requirements like not stealing user's passwords, not including griefing or ban-evasion tools, not including content-theft tools, or putting undue burden the Second Life grid. As part of the self-certification process—the Lindens aren't going to actively verify the claims—at least one developer must apply from an account in good standing and that's been age-verified or has payment info on file with Linden Lab.

Linden Lab as also created a Third-Party Viewer Directory listing viewers that assert they conform to Linden Lab's third-party viewer policy. As of this writing, only two viewers have made those assertions—and neither of them is Emerald. And the clock is ticking: Linden Lab published the policy on third party viewers on February 23, 2010, and is providing a two-month grace period before some sections to into effect. However, the full policy will be in effect April 30, 2010. At that point, being listed in the Viewer Directory will not be a requirement for connecting to the Second Life grid, but in the Lindens' own words: "Beware of third-party viewers that are not in the Viewer Directory—they have either declined to self-certify or been refused for noncompliance with our policies."

Wait, I Thought You Were Talking About Viewer 2!

So into this mess, the Lindens have injected their beta of Viewer 2.0, which will (pretty quickly) also be available to open source developers to integrate with their own viewers. The "killer feature" for Viewer 2.0 is generally conceded to be "Web on a prim:" basically, almost any surface of any object in Second Life can show a fully functional Web page from the real live Internet, complete with scroll bars, forms, Flash content, JavaScript, and more.

Lou, looking at Lou's blog. The mindbends are just starting.

To do this, Linden Lab leveraged the open source WebKit Web browser framework, which is the same engine that underlies Apple's Safari browser and Google Chrome. (Actually, they're using QtWebKit, from a company just bought by BlackBerry maker RIM to put WebKit into Nokia's Qt framework. Layers like an onion. Confused yet?) The upshot is that by using expanded authoring tools, anyone in Second Life who can rez a prim (and that's everyone) and display any Web page on any surface of it just by plugging in the URL. You can even have different pages on the different faces of the same prim: a wall could have one page on the front and another on the back.

The implications of this expansion to Second Life are potentially enormous, and could represent another content revolution in SL akin to those previously (I guess) engendered by the introduction of flexible prims (flexies) and sculpted objects (sculpties). Although Flash content can't be embedded directly on a prim, Flash applications that work within Web pages pretty much work on prims too: users can click links, push buttons, fill out forms, stream media, play games, and much more. The ability to bring Web content into Second Life on a prim obviously has enormous implications for educators and corporations using Second Life as a virtual meeting space; it also unleashes heaps of new possibilities for in-world content creators who can Internet-enable their objects, environments, products, and builds.

The Web-enabling also has enormous implications for user privacy. When Viewer 2.0 users encounter a prim with shared media, Viewer 2.0's built-in WebKit browser goes out to the Internet to fetch its content automatically. That request for a Web page is issued directly from your computer. When you see a regular prim or texture in Second Life, that data is sent to your computer directly from Linden Lab. However, shared media on a prim is sent to you directly from whatever site hosts the Web resource on that prim. That means the remote site not only gets to see and log the IP address you're using to connect to Second Life. They also know you're using Second Life (rather than Safari or Chrome or whatever) and when you're using it, because the remote servers will log the time stamp of every connection.

This kind of connection information is well-known to be sent with every page request issued by a standard Web browser. For better or worse, Internet users either accept that fact or go to a little bit of trouble to protect their Web-browsing privacy. However, Second Life has now blurred the distinction between viewing an object on a grid in a proprietary virtual world and requesting some random Web page on the Internet. By default, Viewer 2.0 will fetch shared media on a prim automatically without requiring the user's consent, and—depending how a particular prim has been set up—there may be no indication at all that someone is seeing content served to them directly from outside Second Life.

Think that not much information can be gleaned from an IP address, a timestamp, and knowledge that someone has been using Second Life? You might be right. Depending. Or you might be wrong. You can get a quick, high-level, not-at-all-detailed idea where you sit.

Now, to be fair, these risks are not entirely new. Other forms of shared media in Second Life—most notably audio and video streams—have also been served directly to users' computers for years. When you listen to a live performer or a DJ in Second Life (or hear any streamed music at all) or watch a video, you're also disclosing your IP address (and a timestamp, and some other information). However, previously, those shared media types have been tied to particular parcels of virtual land—if you didn't enter the parcel, the Second Life client didn't try to connect to the audio or video source.

Now, however, shared media is associated with prims. And not only can your average avatar rez prims in a lot more locations than he or she can stream parcel media, avatars can wear prims as attachments. That means if I were a malicious person wanted to find out your IP address, all I have to do is create a Web page somewhere, link to it with a shared media prim, wear that prim, and get near you…and I have an instant bug that gives me information about your real life. Logging into Second Life from work? Not really where you say you are? Don't want me to know where you are? Don't use Viewer 2 and get near me: I might just find out. Using shared media and very simple LSL scripts, it would be trivia to collect mountain of data accurately associating IP addresses with SL avatar names. In many cases, that would be a great way to uncover alts. There are also ways to combine shared media with LSL scripts to collect IP and avatar information without using any services outside Second Life.

And I'm just touching the tip of the iceberg here: by incorporating support for technologies like JavaScript and Flash, shared media potentially exposed all Viewer 2.0 users to security and privacy vulnerabilities in those technologies—of which, history has shown, there have been a great many. Shared media is an all-or-nothing deal in Viewer 2.0: you can't separately disable JavaScript, Flash, or other plug-ins: heck, right now you can't even stop shared media from accepting cookies from remote sites.

Viewer 2.0 does include controls to enable users to selectively enable and disable shared media: just like you can turn video and audio on and off arbitrarily, Viewer 2.0 users can disable Web-on-a-prim on a URL-by-URL basis, or turn off shared media altogether in the Viewer 2.0 preferences. The URL-by-URL approach is better than no control at all, but a cube as six sides: I'm pretty sure it would be trivial to set up a few prims and overwhelm the shared media controller's tiny scrolling list with a bunch of long confusing URL strings so users can't easily discern where they might be connecting. (It appears Viewer 2.0 currently limits the number of shared media prim faces it will load at one time to eight, however.) And for many users it won't matter anyway: "playing" shared media is enabled by default, and many Second Life users will never bother to figure out how to turn it off.

Linden Lab introduced shared media without any public discussion, and has been touting the capability as the premiere feature of Viewer 2.0 without any mention of the potential privacy and security implications of the technology.

Right now, I can only recommend that users of Viewer 2.0 disable shared media until issues surrounding the technology are ironed out. It's not going to be an easy problem to solve: if Linden Lab addresses it at all, I expect they will have to settle on a solution that enables users to accept media from "trusted" sites and/or parcels. And the default will still be to have all shared media enabled all the time.

If shared media turned out to be the game-changer in Second Life that Lindens (and many Second Life users and content creators) think it will be, it's only a (short) matter of time before Web-on-a-prim turns up in third party viewers. Then Second Life users will face even more complicated decisions about who they trust.


  1. Extremely well done Lou...that's as clear a description as I've ever read
    And I think you know me well enough that I'm certainly no geek.

  2. Very interesting and informative post, Lou. Just a question and a comment. You suggest, "it seems pretty clear that Emerald's development team includes (or has included) the creators of the original CopyBot and at least the content-theft-enabled Second Life viewer Vlife," but you don't explain why this "seems pretty clear." The post is very detailed on a number of other topics, but I felt left hanging here. Could you elaborate, even just a little bit?

    And the comment, also Emerald-related: Emerald's status with LL is discussed occasionally in the Emerald group IM (which is pretty chatty, and I have it going on in the background most of the time). Concerned residents ask about it, and the dev team, many of them active participants in the group, respond. They say they aren't worried about the fact that Emerald is not currently ok-ed by LL. They were LL-approved prior to the policy changes, and they meet actively with Lindens to work out what needs to be changed. There is, apparently, a review process underway that they expect will end in Emerald's approval. I provide this angle because your description of the process sounds a bit like Emerald is simply holding out on agreeing to LL's terms, which would be suspicious indeed. The dev team's line is that the process is more one of working with LL to determine how to come into compliance.

    Other than that, I enjoyed reading this. Thanks for your insight, Lou.

  3. Lette, I deliberately avoided pointing any fingers at the Emerald development team or individual current/former Emerald developers - I'm not familiar with the Emerald development team, process, or project goals, nor do I currently use the Emerald viewer. However, in researching specific technologies with ban-evasion and/or content-theft capabilities, particular sets of avatar and real-life names kept coming back up, both in materials available online and in private conversations with folks who's involvement with these topics is broader and deeper than my own. I have no desire to try to whittle down the legitimacy of any of that information, conduct an investigation, or "name names." The Emerald team itself has noted it aims to "look beyond the previous exploits of some of our team members," and that's enough of an acknowledgment for me. I'm not a prosecutor.

    I am also not privy to Emerald's development plans, viewer roadmap, internal drama, or how they may respond to Linden Lab's Third Party Viewer Policy. If they wish to clarify their position(s), I believe there might be more effective ways to do it than in-world IM to group members. My understanding is also that the Emerald team and Linden Lab are in active discussions.

    One major Emerald feature I omitted mentioning is IM encryption; I had a whole separate section about security of user-to-user communications in Second Life, but yanked it because I wasn't able to nail down the (big) topic well enough.

  4. Thanks for the response, though you sound a little defensive (sorry if that's a mistaken perception). I didn't intend to ask you to single anyone out in public or conduct a full-scale investigation, but only to clarify a statement that a connection is "pretty clear," because while it might be clear to you, it's certainly not clear in the public eye. Without explanation, you pretty much give readers a suspicion and imply, "Trust me on this one." The citation to the Emerald blog is helpful and does support your suggestion. That is exactly the type of thing I was hoping for, so thanks for the reference.

    Regarding the other part of your response, I hope it didn't sound like I was demanding that type of expertise from you. My comment was meant to be informative of one of the very few areas of this topic that I might have a bit more background on than you have. My sense is not that the Emerald dev team think they need to publicly clarify their position; rather, when other people want more info, they come to the group, ask directly, and receive a fairly direct answer. No one is obligated to do that, but since I've heard these conversations several times over, it seemed appropriate to offer a more complete explanation of Emerald's status with LL than simply saying that they haven't signed on to LL's terms yet.

    My comments so far haven't been arguments against any of your main conclusions, Lou, but requests for elaboration and an offer of the same. You know a lot more than I do on most of the issues you bring up. I hope you keep bringing us your take on these topics.

  5. No worries, Lette—the "pretty clear" comment was not well-conceived, and you're couth to ask about it. And I wouldn't bet on any of this stuff being more obvious to me than anyone else: if there's one thing I've learned from looking into this stuff, it's that the whole SL viewer situation is rife with conflicting accounts, ad hominum attacks, and misinformation. I don't want to contribute to that.


Comments are moderated. You can use some HTML tags, such as <b>, <i>, <a>. If you'd like to contact me privately, use a blog comment and say you don't want it published.