Dale Innis

I can't get past the picture of Bill Gates standing at an Apple Genius Bar... O.o

The controversial code in Emerald wasn't actually a "back door" in any usual sense of that word. It didn't allow the developers special access to anything, didn't steal passwords, etc. There was code in Emerald itself that would sometimes include the pathname of the Emerald executable in uploaded data (and since the path name sometimes would include the username, that might violate privacy), and there was code on the Emerald splash-screen HTML page (not in the viewer code itself) that would for no good reason load lots of data from some 'rival' website. Childish at best, but still not really a "back door".

Nitpickingly,
Dale Innis

Are you sure it's banned by identity? I thought they'd just banned the IP of the specific open shared server/proxy...

The "Linden Lab guns for service-based Second Life viewers" headline, I think, wildly overstates what's actually happened here. The Lab shut down exactly one publicly-accessible server for exactly one viewer. AjaxLife itself isn't prohibited, only (at most) multi-user AjaxLife servers. One could speculate that, until they have time to address the issue systematically, they'll have similar objections to other multi-person proxies / servers. But if you host your own server (gesturing at Amazon EC2), you can still use AjaxLife to connect to SL from your mobile today, afaik...

It doesn't actually require an unbeatable way to detect what viewer is in use to be effective. It won't be 100% effective, but it will make it harder to distribute or publicize a rogue viewer, and people will be deterred to some extent by knowing that they are doing wrong, and are likely to get caught eventually. As opposed to right now, where someone can make and advertize a viewer that has, say, built-in griefing and content-stealing tools, and there's nothing anyone can directly point to and say "it says here that you can be banned for that!". I think it's a good thing in general, although as you quite rightly point out it'll always be possible to get around it in any specific case.

Businesses definitely require end-to-end encryption in some circumstances. (Lotus Notes, for instance, offers end-to-end encryption of email; it's one of its big selling points for the enterprise.) This doesn't apply to "open to the world" social media like Twitter, of course. But IM in virtual worlds is one-to-one, not open to the world, and end-to-end encryption there would be useful in various real business applications. I know of at least two efforts, within major enterprises, to build end-to-end IM (and chat!) encryption into virtual world clients.

A colleague points out :) that it can be useful even within the firewall; if the CEO and CTO are IMing in an internal Nebraska instance, it may well be the case that the sysadmin who's running the server isn't authorized to listen in.

Despite persistent rumors, I know of no evidence that the current problems with estate bans have anything to do with 3rd-party viewers. If you read the relevant JIRA (SVC-4632) you'll see that it's been experienced with the standard LL viewer. It is almost certainly some server-side bug. (If a 3rd party viewer *was* able to get around estate bans, that would also be a server-side bug; all a viewer can do is say "please TP my user here to region,x,y,z": it's the server's job to say "no can do, they are banned from there".)

lol @ "a term in education circles for one-way, or top-down lunchtime lectures without audience participation". Is that true?

Around here (IT industry research lab, NE USA), it "brown bag" means something held around lunch time, generally informal and sometimes outside the usual topic areas, usually with lots of discussion. I expect that that's somewhat closer to what the Lab meant, although your meaning is funnier (and/or sadder).

If I show up in every thread in which you appear, you must have been awfully quiet lately. :) I don't think I've had the pleasure of your vehemence for several weeks now.

Businesses need end-to-end encrypted communication channels for many real use-cases. If a channel doesn't offer end-to-end encryption, they will move to some other channel. Having end-to-end encryption available within a virtual world means that businesses have one less reason to use channels outside the virtual world. So a virtual world has a good reason to provide that function. I'm still puzzled that the Lab seems to be claiming it's contrary to the ToS; I wonder what they mean by that.

Saying that third-party viewers are associated with misbehavior is about like saying that virtual worlds are associated with misbehavior. True, but not supporting the conclusions you would like to draw from it.

The encrypted-IM part (which I hope will quietly be removed from the criteria) aside, though, I think it's a very good thing that the Lab is publishing requirements for third-party viewers. In the JIRA discussion about whether or not it's possible to ban certain viewers, I said that the most important thing the Lab can do is say what things a viewer should and shouldn't allow, and communicate that message clearly. They can't do a 100% job of keeping people from logging in with a naughty viewer, but they can do a very good job of making it hard to produce and publicize one.

Really the only thing I can think of that a viewer should definitely not do is allow saving copies of stuff that the viewer has to have to do its job, but the perms don't permit you to otherwise copy. Anything else "malicious" that a viewer can do should be made impossible at the server side. I can think of a few fuzzy cases (griefing tools built into the viewer that ran right along the edge of what it's feasible to prevent server-side, say), but in general security should be server-side wherever possible. (When was the last time you saw a website that tried to control which browser you use to access it?0

These aren't fake edge cases, these are real edge cases that have come up in actual business uses of virtual worlds. Businesses do use Twitter and gmail all the time, but they do not use them for communications that require encryption-grade privacy. For that, they use channels that provide end-to-end encryption.

We know from experience that what happens when you forbid encryption on a channel is:

() you may catch a few additional clueless criminals

() the non-clueless criminals either encrypt anyway, or switch to a different channel, and

() your staff abuses their access to the unencrypted traffic to stalk ex-spouses, steal private information, and so on.

"IF it persisted in allowing an encrypted part of the Internet, sooner or later, RL authorities will come calling to stop this."

No. Encryption is used all over the Internet, in email and IM and IP phones and general file and data transmission. Various RL authorities wish it were not true, and have made some small attempts to (for instance) get backdoors into some of the more popular encryption schemes, but that's as far as it goes. The "encrypted part of the Internet" is the whole thing: any channel can carry encrypted traffic if the people at the endpoints want it to.