Tentacolor

Deliverate Your Holiday Gifts and Invitations

Jacek Antonelli — Sun, 07 Dec 2008 00:55:22 +0000

It’s that time of year again — time to hand out the “Season’s Greetings” cards, gifts, and party invitations! But who has the time to open up profile window after profile window, sending items to one person at a time… drag… drop… drag… drop. I dunno about you, but my drag-and-dropper would fall off before I got halfway through my friends list. >_<

Why not spare yourself the hassle this year — use a Deliverator to send out your gifts and invitations for you! Just give it the item to deliver, fill the notecard with the names of everyone you want to deliver to, and off it goes! It does the boring part, so you can just curl up by the prim fireplace and enjoy the holiday season!

The Deliverator is available at Cuddlefish Junction for just L$500. And it’s transferable, so you can let a friend borrow it, and save them from the tedium, too!

Femme Noir

Jacek Antonelli — Tue, 25 Nov 2008 17:41:00 +0000

Some recent posts by Botgirl Questi inspired me to get out my Femme Noir outfit: all-black skin and eyes, fullbright white hair (with signature rainbow strands, naturally) and wings.

Serving simple HTML by LSL script

Jacek Antonelli — Mon, 24 Nov 2008 20:22:19 +0000

I’ve written an LSL script which “serves” custom-generated HTML via a neat trick I discovered. But don’t bust out the champagne just yet — this method is extremely limited, so I don’t expect this to revolutionize HUDs or anything like that. Still, it’s a fun curiosity.

The trick is this: If you use text of the form “data:text/html,[html code here]” as the web URL, Firefox (and maybe other browsers?) will render the HTML code as a web page. For example, visit data:text/html,

Oh hai!

, and Firefox will render the words “Oh hai!”. It’s not accessing a web page, and it’s not loading a local HTML file, it’s loading the HTML code from the pseudo-URL.

The same trick works in SL as well, by setting the parcel media URL to the “data:text/html” string. You can use an LSL script to generate the HTML code and set the parcel URL, or even set the URL for an individual avatar. The result is that your LSL script acts as a very simple web server!

However, as I mentioned, there are some serious limitations: SL won’t let you set the web URL to a string longer than 254 letters! That means you have to cram all the HTML code into that tiny string, which severely limits the complexity of the HTML you can display.

Another problem is that the method may not work for other web engines besides Firefox / Mozilla. Linden Lab is (or was recently) working on switching to WebKit, the engine used by Safari, for rendering HTML. That’s good news, since WebKit is some great software, but this little trick might stop working when they switch. So, I wouldn’t rely on it.

So, I don’t expect this method to be more than a silly toy for programmers to play around with. But it is that! And on the plus side, there are signs that we might get proper HTTP server functionality in LSL sometime in the future, which would be a great boon to many scripting industries in SL.

You can get a full-perm copy of the object and script in SL at my sandbox or copy the following code (below the fold, if you’re viewing this on my blog front page) into an LSL script in your own object (in which case you should apply the “*Default Media Texture” to your prim from the Library, or you won’t see anything).

// VERY SIMPLE HTML SERVER // by Jacek Antonelli, 2008-11-24. // // Description: When an avatar touches the object, it sets the // avatar's media URL to a custom-generated HTML string, // effectively serving HTML from an LSL script. // // However, this method is limited by the maximum allowed // URL length of 254 characters. Thus it's only possible to // serve very simple HTML with this method. // // This script has been released to the PUBLIC DOMAIN // by its author. default { touch_start( integer n ) { string html = \ ""+ "

"+ "Your name is "+ llDetectedName(0)+".
"+ "Your position is "+ (string)llDetectedPos(0)+ ".
"+ "This HTML is generated by the LSL script.
"+ "Have a nice day. :)"+ "

"; llParcelMediaCommandList( [PARCEL_MEDIA_COMMAND_TEXTURE, "8b5fec65-8d8d-9dc5-cda8-8fdf2716e361", PARCEL_MEDIA_COMMAND_URL, "data:text/html,"+html, PARCEL_MEDIA_COMMAND_TYPE, "text/html", PARCEL_MEDIA_COMMAND_SIZE, 600, 300, PARCEL_MEDIA_COMMAND_AGENT, llDetectedKey(0), PARCEL_MEDIA_COMMAND_PLAY ]); } }

Imprudence Viewer release candidate is here, baby

Jacek Antonelli — Sun, 16 Nov 2008 05:07:05 +0000

From the Imprudence Blog

It has been an intense two and a half months since we first announced the Imprudence project. There has been laughter, there has been joy, there has been boredom and frustration, stress and near burn-out, and a medley of other emotions thrown in there as well.

But today it’s all worth it, because today the first release candidate of the Imprudence Viewer is ready!

Read the rest for more information, plus sexy download links!

Happy Days, Old Viewers

Jacek Antonelli — Mon, 03 Nov 2008 04:49:01 +0000

Tired of those beautiful, photo-realistic sunsets? That new-fangled Windlight rendering engine slow your compy to a crawl? Want to relive the good old days, back when voice chat was new and strange, and Linden Lab even bothered to pretend to communicate with its customers?

Well now you can!

… Actually, you’ve been able to do so for a long, long time — ever since the Día de Liberación back in summer 2007. One of the benefits of “message liberation” was that you wouldn’t need to download a new SL viewer just because they made some server changes; old viewers would continue to work with new sims.

And in fact, that has held true, even to today. The only thing stopping you from using a 1.18-series (pre-Windlight) viewer is that annoying “You must download the latest version to continue” message, which is easily bypassed with a trick I’ll describe below.

But what of that mandatory security update in early October? Or the security update and protocol switch from UDP to HTTPS less than two weeks before that? Wouldn’t those issues prevent old viewers from connecting?

Apparently not. As of this writing, even 1.19 and 1.18 viewers (but not 1.17 or other older, “unliberated” viewers) can connect to SL with nary a hitch, though they’re probably still susceptible to the security issues mentioned above. As usual, the purportedly required updates are, in fact, not.

So, what is this trick, this secret knowledge needed to bypass the download prompt and log in with older viewers? Change the channel. It’s an old trick, though there was some concern that it wouldn’t work anymore since the change to HTTPS. Fortunately, those concerns have not come to pass, and the SL servers seem perfectly happy to use UDP with older viewers.

Changing the channel is easy. The viewer application takes a parameter, “–channel CHANNEL”, which sets the channel to use. The process for giving that parameter varies between operating systems. The processes are described on the SL wiki, but I’ve included a brief overview below.

Windows: Create a shortcut to the older SecondLife.exe. Open up the shortcut’s properties (right click > Properties) and edit the shortcut path. ~~After SecondLife.exe but before the closing quotation mark~~ After the closing quotation mark, add: --channel Happydays
Mac: Open up the terminal and run these two commands (adjust the first path if your Second Life app isn’t in Applications):
```
cd "/Applications/Second Life.app/"
echo "--channel Happydays" >> Contents/Resources/arguments.txt
```
(Mac users, leave a comment if the above solution didn’t work for you. I don’t have a Mac handy to test it!)
Linux: Run the viewer as: secondlife --channel Happydays

You should now be able to log in to SL with your retro viewer version. Enjoy, good night, and good luck!

P.S. Don’t have the installer for the old viewer laying around? No worries, they’re still available for download. Mad props to McCabe Maxsted for putting that wiki page together!

The Plug with a Hole in It

Jacek Antonelli — Sun, 19 Oct 2008 01:34:24 +0000

Gwyneth Llewelyn recently offered a proposal to try to plug “the analogue hole” that makes content theft inevitable. Her proposal drew a lot of criticism, particularly from open source developers, and she has since withdrawn it.

I’m glad to read that she has; I was among those with objections to the proposal. But I’m disappointed by her reaction to the criticism she received:

The current community of developers — and by that I mean non-LL developers — is absolutely not interested in implementing any sort of content protection schemes.

… Their argument is that ultimately any measures taken to implement “trusted clients” that connect to LL’s grid will always be defeated since it’s too easy to create a “fake” trusted client. And that the trouble to go the way of trusted clients will, well, “stifle development” by making it harder, and, ultimately, the gain is poor compared to the hassle of going through a certification procedure.

I won’t fight that argument, since it’s discussing ideologies, not really security. Either the development is made by security-conscious developers, or by people who prefer that content ought to be copied anyway (since you’ll never be able to protect it), and they claim that the focus should be on making development easier, not worrying about how easy content is copied or not.

… “Technicalities” are just a way to cover their ideology: ultimately, they’re strong believers that content (and that includes development efforts to make Second Life better) ought to be free.

Despite what Gwyn suggests, one can object to a specific content protection scheme without being an ideological extremist who believes that everything should be free. Yes, there are individuals who take that viewpoint. Many of them are quite vocal, and some are rather arrogant and obnoxious. (I am of the opinion that this latter kind ought to be swatted hard over the head with a rolled-up newspaper. Repeatedly.)

But to imply that anyone opposing her proposal must be some kind of anticommercial tekkie-hippie is fallacious and juvenile, and just as dismissive as the rudest comments she received. I must admit that I expected better from Gwyn.

Now then, let me explain my opposition and criticism of the proposal. (This is not criticism of Gwyn as a person, nor of any of her other ideas besides this particular proposal.)

While I do appreciate and respect the choice to make one’s own efforts open and free, I do not believe everything should be forced to be free, and I did not oppose the proposal based on my views on that topic. I opposed it because I see three major flaws in the proposed system, two of them purely security-related:

the certificates could be easily forged, which defeats the purpose of having them at all
an effective certification system would put an extraordinary burden on developers
the system does not address the most commonly exploited methods of content theft

I’ll expand on these points so that there can be no confusion about why I objected and still object to such a system. (I’ll give fair warning, though, that this is a rather long and probably dull post by most standards.)

Firstly, as others have said: where there is a certificate, there is a way to forge a certificate. Even a certificate embedded in the executable binary code can be extracted, and an uncertified client created which fools the server into believing it is a certified one.

And the target for such certificate extraction would not be the open source developers with their little custom viewers, it would be Linden Lab’s own released clients. Why? Because even after LL has found out that someone extracted the certificate to one of their official releases, they could not do anything about it.

Would they block all viewers using that certificate? Doing so would block all users who are using LL’s own viewer! Users would be forced to download a new version every day as LL struggled to keep ahead of the malicious users extracting the new certificates. (Plus, they would have to use a different method of embedding certificate for every release, since the old methods would have been figured out.)

Unless LL is willing to try to keep that up, the certificate program would cease to be effective at distinguishing authorized viewers from unauthorized ones.

Secondly, let me explain the burden of such a certification process on open source developers. It is not a matter of developers complaining, “Waah, it would take me 10 more minutes to implement my code! I’m going to go cry in a corner now.” A certification process as Gwyn described would, if effective, put a near-total damper on many of the most important areas of development of the viewer code.

Suppose that you are trying to fix a memory leak, like Nicholaz used to do. In order to test whether you have fixed it, you would need to run the viewer and travel around SL to make it load lots of content into memory. However, because of this certification program, you must have a certificate embedded in your viewer in order to see such content, and thus to test the fix. (I am assuming here the embedded certificate scenario, because keeping the certificate as a separate file would render the system extraordinarily easy to spoof.)

Every time you recompiled your code, you would have to send your source code and compiled viewer off to whatever company does the certification and wait for them to look it over and embed the certificate in it and send it back. Such a process would take at least several days at the start (after all, they have to inspect your source code to make sure you haven’t added something nasty!). That’s several days of waiting between the time you write the code, and the time you can check whether it worked. If you find out that it didn’t work, you will have to wait another several days for them to certify your next attempt.

Now, I said it would take several days at the start. If the company could not keep up with the number of developers requesting certification for their little test versions, then the delay would grow longer and longer. You would soon be waiting a week, two weeks, a month for them to process the certified binary — if you (or they) hadn’t given up completely by then.

A month between testing bug fixes? I can barely even recall my approach to the problem after two days! No developer or other creative person would volunteer to work in such a stifling environment.

Now, I admit, not every bug fix would require a certified viewer to test with. But many of the worst, most disliked kinds of bugs would. I don’t presume to speak on Nicholaz’s behalf, but I doubt his work would have been possible if such a certification process had been required.

Fortunately, though, the weakness of the system means that many developers would soon begin to use forged certificates to circumvent the system and continue their testing work. Unfortunately, such circumvention would, more likely than not, be illegal in the United States due to the DMCA, and in any other countries with similar legislation. Some developers would be willing to take that risk for the sake of improving the viewer, but many not.

Finally, even if we set aside the other issues, the proposal does not address the most common methods of content theft. Even if the process stopped uncertified viewers from being able to see the protected content, the certified viewers still have gaping holes in them.

I will set aside the issue of GL ripping, something that cannot possibly be addressed by Linden Lab, and instead focus on the insecurity of the cache and the data packets that are sent by the sim.

The viewer as it is now does not employ any real encryption of either the cache or (I assume, though I may be wrong) the data going to and from the server. Textures are easily extracted from the cache; prim shapes are (I hear) also cached, and thus can be extracted. Even if they were not cached, textures, prim shapes, avatar shapes, animations, and more could be extracted from the data packets being sent by the sim to your computer.

That is the current state of affairs. Well, what if Linden Lab did start to encrypt data packets and the cache? In such a case, the viewer must have programmed into it the decryption method and key (or else a method of receiving or generating the key). But because the viewer code is being released as open source, Linden Lab would face the difficult choice of whether to release or to withold that piece of code. Either choice would have significant consequences.

If Linden Lab chose to release the code for the decryption and keying methods, the encryption scheme is defeated. By studying the code, a reasonably proficient content thief could figure out how to decrypt the cache and incoming data packets, and thus gain access to the protected content, even while running a certified viewer. For a while, the barrier to content theft would be somewhat higher than it is now, but eventually some malicious user would release a tool to copy content without needing to understand the concepts behind it. We would then be back to the state we are in today, but with an ineffective encryption scheme added on top.

On the other hand, if Linden Lab chose to withold the decryption code, open source viewers would be locked out. Or at least, they would not have access to the protected content. So in that respect, yes, a combination of certifying only LL’s viewers, encrypting the cache and data packets, and keeping the viewer partially closed source might be effective at protecting content, for a while. I’m not a cryptography expert, so I can’t even begin to guess how long it would take to break the encryption. Perhaps long enough that LL could change encryption keys and certificates (and force everyone to upgrade) before the old ones are found out.

But doing so would impose the burdens on developers I described earlier. And worse, as Gwyn so rightly points out, it would offend and alienate most of them — even the ones who aren’t obsessed with freeing everything. I’d expect it to light a fire under OpenSim, too, as developers shifted their focuses to more open, less burdensome systems.

Would Linden Lab be willing to undo the Dia de Liberation, cripple open source development, and turn some of their most effective supporters into resources for the competition, in exchange for the appearance of strong content protection?

Maybe. I hope not, but it’s hard to say anymore.

So is the situation hopeless? Can content theft be stopped only by sacrificing open source development? Can content theft even be stopped?

Certainly, it’s not possible to completely stop 100% of content theft. Gwyn recognizes that, as does just about anybody familiar with the problem. The idea is, instead, to raise the barrier for content theft; to make it more difficult.

But even that is a matter of debate. If you raise the barrier, eventually someone will figure out how to get over it, and they or someone else will create a tool to let other people get over it, even people who have no idea how the tool works or what it’s circumventing. You can raise the barrier again and again, but that only buys you time. And often, that temporary gain in protection comes at the cost of a permanent loss elsewhere — creating extra hassles for users, stifling development, etc.

Can content theft be prevented? Probably not. I wish it could; I’d love to have a punchy ending here, to reveal that if you do X, Y, and Z, all content theft will be stopped. But it doesn’t work that way.

More likely, the key to dealing with content theft is not prevention, but rather detection and enforcement, neither of which are being carried out in a reliable, objective, or effective manner.

Naturally, fixing them is easier said than done. But that’s how it is.

The Deliverator

Jacek Antonelli — Tue, 14 Oct 2008 01:22:38 +0000

I’m happy (and rather relieved) to announce that after power-coding day and night for the past week, I’ve released a handy new device: the Deliverator. I’m sure you’ll find that it is the easiest and most convenient way to deliver a gift, notecard, or other item to a long list of your friends or customers!

It’s available now at Cuddlefish Junction for L$500 (or L$4500 for a copyable version).

What is this marvelous contraption?

The Deliverator is a scripted object that will help you deliver an item to lots of people with very little fuss.

Easy, guided set-up. Give it the item, give it the names, and off it goes.
No keys required. Names are enough for the Deliverator to do its job. No need to look up everybody’s UUIDs or make them touch some silly prim.
Low maintenance. Start it running and get on with your life. The Deliverator will IM you when it’s done, and let you know if there’s anything you should be aware of.
Reliable. In the unlikely event that the Deliverator can’t find somebody on your list, it will remember their name and tell you at the end, so you can be sure no one gets left out.
Unlimited delivery. The Deliverator can be used as many times as you want, and it can deliver to as many people as you can fit in a notecard.

What’s to stop someone from spamming us with it?

Me and my shut-off switch of cold steel justice, that’s what.

If I have solid grounds to believe you’re using the Deliverator for nefarious purposes like spamming or harrassment, you may find your Deliverator suddenly stops Deliverating.

See the “Abuse of the Service” section below for more about that.

What can I deliver with this thing?

Any inventory item that you can copy and transfer. Objects, notecards, clothes, whatever.

Unfortunately, you cannot send multiple items at once, except by packaging them in a box or notecard and sending that. This is because of a quirk in the LSL function which prevents delivering multiple items to people in other sims.

If/when Linden Lab ever addresses this issue, I can release a new version of the Deliverator to support multiple item transfer.

Which perms should I get?

The Deliverator is sold with your choice of either no-copy/transfer or copy/no-transfer object permissions. Both are identical except for the permissions.

Most people will want to buy it as no-copy, because it’s more affordable that way! Plus it’s transferable, so you can let a friend borrow it, etc.

But if you plan on delivering stuff to a lot of people, you may want to buy a copyable Deliverator so that you can rez more than one, to split up the workload and speed things up. (HOWEVER: see the “Abuse of the Service” section below for guidelines on how many you are permitted to run simultaneously.)

Discounts for Worthy Causes

The Deliverator is available for free or at a discount to educational institutions, help groups, charities, and other such “worthy causes”.

To apply for a discount, send Jacek Antonelli a notecard named “Deliverator - [Your Organization Name]” with a brief description of your organization and its work.

Abuse of the Service

Using the Deliverator in any of the following manners is forbidden:

Running an excessively large number of Deliverators simultaneously for long durations (e.g. more than 20 for over an hour). This can negatively impact other people’s ability to use the service.
Spamming one or more Residents with unsolicited and unwanted items.
Any use that is deemed malicious, disrespectful to other Residents, or a violation of the Second Life Terms of Service and/or Community Standards.

Depending on the type, severity, and frequency of the abuse, you may receive a warning, a temporary suspension of your access to the service, or a permanent revocation of your access to the service.

Just don’t be a huge jerk, and you’ll be fine.

A New SL Viewer from LL? Don’t Jump to Conclusions

Jacek Antonelli — Tue, 30 Sep 2008 00:55:29 +0000

Dusan Writer offers a sensational bit of news:

Mark Kingdon announced that an outside design firm is hard at work on a new, user-friendly viewer for Second Life.

I’ve read Kingdon’s post, and I’m afraid Dusan misread it and jumped to the entirely wrong conclusion. Here’s what Kingdon actually wrote (emphasis mine):

Shortly after I started, we kicked off a project to reinvent what we call the “first hour experience” (our web experience, the viewer, and the way we acclimate and acculturate users inworld) for new users. We’ve made great progress and will be working with an award-winning interactive design firm to help us complete the reinvention and bring it to life. Yes, we are creating a viewer that is new user friendly! Stay tuned for updates.

That reads pretty clearly to me: they are working on a viewer that is friendly to new users, not a new viewer that is friendly to users. I suppose you could read some meaning into “reinvention” and “creating”, but I don’t see any indication that he means anything other than the renovations already in progress to make the existing viewer more friendly to new users.

Improving new users experience has been a recurring theme at Resident Experience (Rx) office hours, and is clearly one of LL’s primary obsessions. And as it happens, Linden Lab contracted Vectorform, an award-winning interactive design firm, for what is known as the Landmarks & Navigation project. This is no great secret. Vectorform attended the Rx office hours on April 17 & 24 to gather information, and then presented the L&N project concept on May 29. There were also emails to the SLDev mailing list in April and May, around the same time as the office hours. The L&N project has been underway since then, and is now nearing completion (as much has been said at Rx office hours in recent weeks).

So, sorry to burst any bubbles, but unless LL contracted another award-winning interactive design firm to work in secret on a whole new viewer, and the timing of that project just happened to coincide exactly with the timing of the Landmarks & Navigation project… well, I’ll let you jump to your own conclusion.

Tip: Replace the SL typing sound with crickets

Jacek Antonelli — Fri, 26 Sep 2008 17:00:07 +0000

Here’s an updated version of an oldie but a goodie. Back in January 2007, I found out how to disable (on your computer only) the SL typing sound — the loud, annoying click-clack-clack sound that plays whenever you or anyone around you starts typing something into chat.

It has been nice and peaceful since then. But tonight, while testing the latest build of Imprudence, I heard it for the first time in 21 months (since my regular SL settings weren’t loaded). Blech! What a racket. I went to disable it, but then I thought of something better: I could replace it with a nicer sound. That way I’d still have an audible indicator of when someone was typing (something I realize I had been missing).

After rummaging around in my inventory a bit to find an appropriate sound, I settled on a freebie cricket chirp sound. It was full perm, so I grabbed the asset UUID: b3831ff2-a197-62df-34f7-a83be592c1da

So, I enabled the Advanced menu (Ctrl+Alt+D, or Cmd+Alt+D for you Mac-types), opened up Advanced > Debug Settings, typed in UISndTyping, then pasted in b3831ff2-a197-62df-34f7-a83be592c1da in the box at the bottom, replacing the UUID that was there. Close up Debug Settings and… voila! Now instead of clacking on a keyboard, everybody chirps like a cricket when they start typing!

Of course, if crickets aren’t your thing, you can use any sound at all, as long as you have the UUID for it. You can get that by right clicking on it and selecting Copy Asset UUID — but only if you have full permissions on the item.

So, enjoy your crickets etc.! If you find a free sound that you like even better than crickets, leave a comment with the UUID or link to where it can be downloaded so I can try it out. (No illegal rips, please!)

Tools, Avatars, and the Self

Jacek Antonelli — Mon, 22 Sep 2008 03:33:59 +0000

Tateru Nino poses an intriguing question about why disabled users often become quite attached and identify with their avatars, more so than able-bodied people do:

To many such physically impaired users, the body is no more nor less a tool than an online avatar, and the latter (despite lag, occasional inventory loss, network problems and all the other hurly-burly of a virtual environment) is the more reliable, expressive and liberating, allowing more ability to contribute, work, play and socialize.

Why then, do the able-bodied among us tend to see so much more distinction between our bodies in the physical world and our digital representations? Is that distinction merely an artificial one, a handicap brought about by our able-bodied perspective?

I suspect it’s a matter of the strength of the connection between thought, action, results, and feedback.

For a perfectly able-bodied person, the mind directs the body smoothly, precisely, and effortlessly. Thought easily translates into action, and the feedback — sensory input confirming the results — reinforces the mind-body connection. As a result, your body starts to feel like part of your “self”, rather than an external thing.

But for an able-bodied person using an awkward tool or interface, the translation from thought to action is not nearly so effortless, the feedback is not as rewarding, and thus the connection is not as strong. As a result, the person feels less in control, and more conscious of manipulating an unwilling external object.

I certainly can’t speak for any disabled person, but I’ve heard motor impairment described in similar terms. It requires a great deal of conscious effort to merely take a step or pick up a coffee mug. The body seems more like an unwilling object that must be forced to act, and less like an intimate tool for enacting the mind’s will.

On the other hand, someone with motor impairments that, say, make it difficult to walk, may find a Second Life avatar controlled through the computer responds more easily to their will than the body does, and the feedback to be more rewarding than that provided by the body. They are in control, and the avatar obeys with minimum effort; it takes only a keystroke to make the avatar walk, run, or even fly. Depending on the severity of the motor impairment, the avatar may feel like an equal — or better — tool for enacting the person’s will than their physical body is.

So, my hypothesis is thus: the relative quality of control over the body versus the avatar determines the attachment and sense of self with respect to each. If you feel much more in control of your body than you do your avatar, you will feel a much stronger attachment to your body. Likewise, if you feel more in control of your avatar, you will feel more attached to it.

If my hypothesis is correct, then we should be able to observe some corollaries:

People who are very physically fit and in control of their bodies (e.g. gymnasts) should tend to be less avatar-identified than those who are less fit.
People who are skilled at using computer interfaces should tend to be more avatar-identified than those who struggle with computers.
People who can control Second Life through a mind-computer interface (e.g. an Emotiv headset) should tend to be more avatar-identified than people who use the keyboard and mouse.
If Second Life became easier to use, people should tend to identify more strongly with their avatars than they currently do.

Although I’ve been thinking about this in terms of users with motor impairments and other physical disabilities, it occurs to me that it also should apply to any other sort of debilitation. So, let me generalize my hypothesis: the relative enablement of one’s will by the physical self versus the avatar determines the attachment and sense of self with respect to each.

If that is true, then the following should also be true, as well as the things listed above:

People who have physical difficulty hearing or speaking, and thus find communication by chat more enabling, should tend to be more avatar-identified than those who can easily hear and speak.
Among people who find speaking and listening easier than typing, those who use voice chat should tend to be more avatar-identified than those who do not use voice chat.
People who have have difficulty socializing in person (due to shyness, social anxiety, etc.) should tend to be more avatar-identified than those who socialize effortlessly.

This is an extension of the observation that people who are skilled with a particular tool (e.g. hammer, tennis racket, pencil, computer) become emotionally attached to that type of tool. And further, that if they use the same instance of the tool (e.g. the same pencil) for a long time and get positive feedback from using that tool, they begin to feel the tool as part of themselves, an extension of their body, rather than a separate tool.

I’m sure there are additional factors specific to avatars that enhance the emotional attachment to the avatar. Two in particular that come to mind: the expression of our personalities through customization of the avatar, and the fact that the avatar is the primary means through which we interact with the virtual world as a whole.

Those factors enhance and facilitate the attachment and sense of self, but it’s the sense of enablement and positive feedback from the tool (the Second Life viewer) that provide the foundation for it.

That would explain why having a positive experience when first using Second Life is so important to getting “hooked” and why Second Life often appeals so strongly to the shy and the disabled. It would also suggest that Linden Lab’s focus on new user experience is not so stupid, and that making the user interface easier and more enabling would go a long way towards emotional attachment, and thus user retention.

What do you think? Am I on to something, or is this just a bunch of confirmation-biased psychobabble bullshit?