Anti griefing proposal - Verified Scripters

Look Matt. It's really very simple. Those with the skill and the desire can hack anything. It often takes a team to do the really tough stuff. I've been part of such teams, for example, the team that cracked the mod-12 based "taper system" behind the way spellcasting worked in Asheron's Call 1.

My gripe is that Libsecondlife hands work that would otherwise take hours and days and weeks of effort on a silver platter to the less capable and less dedicated. What are commonly referred to as the "script kiddie" variety of griefer.

Should the libsecondlife so-called "team" exist? (BTW where is the list of these "team" members?) Sure, why not. Should LindenLab keep their finger on the pulse what that "team" is doing? Sure, why not. However, should all those tools and bytecode maps and whatnot be available to the general public? That's where I beg to differ. It makes it too easy for the script kiddie types to get a leg up and start messing around.

<opening tyrade more or less deleted>

You know? From the way you interact, I have no reason to believe you're NOT a 31337 MMOh4x0r. So, you know, congratulations, due ph34r, and all the best. And let's ease off on the patronizing tone there, ok cupcake? I may not have a 12th level Elven Wizard who needs to cast Mordenkaiden's Magical Something Or Other at *LEVEL FOURTEEN* strength, but I've been around these 'computer' things a while, myself. Also, I went to high school with a guy from Hackers. We were on the tennis team together, and he pwned there, too. Pwned me, anyway, but my backhand was weak, and I digress.

Damn it! Know what I just realized? Ah well, I was never that into Indiana Jones, anyway.

But libsecondlife ALSO makes it easier to develop useful tools that would otherwise require massive reinvention of abstract wheels, if they ever happened at all. 'Tools to make Tools' and other "Heroes of the Computer Revolution" catch-phrases. As for your list of the 'team' members, I think Joe McCarthy has it. You should email him or hit up his Myspace page.

I think it's just a little premature for people to start bashing libsecondlife when it's not actually been shown to be responsible for anything at all. (Well, there was the "God Mode" thing, but that's hardly a grid attack, and lots of people found it very useful indeed. I'm sure it caused less overall bother than some of the items out there which are explicitly designed for griefing.) It seems as if LL have been pretty careful with client security really.

As for the original point: yes to some method of tying a script to the person who's to blame that's better than "creator" - which basically means nothing in terms of tracking down a culprit, just like object creator means nothing in that context either. It may of course be that LL already have such a tool. I don't see the connection to restricting unverified accounts though.

As Kelly Linden stated, bytecodes cannot be modified on existing code already on the server, only on code on the client that hasn't been saved. So as previously stated, this has no impact on the proposal at hand, the scripter id would be checked and added on the server.

There are several objections raised that people don't want to have to give up their anonymity to be able to do some things in SL. I can only say that you have to do that to buy land, and being able to crash SL is a much bigger deal.

Not being an expert on verifying people's ids, I'm not sure what acceptable methods are, however this can't be the only business that needs such things. You need a credit card to rent most cars or stay in most hotels even if you pay in cash for much the same reason.

Unfortunately, things are going to have to change if SL is to continue, there are malfactors out there, so keeping everything the same won't work. This proposal is designed to remove anonymity only from the set of people who are given potentially dangerous privileges, not from everyone.

Proposals to eliminate all unverified accounts are a superset of this proposal's restrictions, and would require the end of all anonymous accounts.

I guess I'm okay with restricting a *small* subset of script functionality to trusted accounts. Much like I'm okay with laws against selling fireworks to visibly intoxicated customers. Anonymity can be a powerful drug for those not postconventional enough to handle it to the benefit of all.

I think if I'm honest with myself, I'm especially okay with it given that I've been around since 2004, have a clean slate, am in America with billing info in a friendly format, and feel reasonably confident that becoming 'Trusted' presents a fairly low bar. I have to acknowlege that not everyone's in that boat, so of course there's some understandable worry that LL will set the bar too high for some perfectly legit users. It all comes down to LL not screwing too many (potential) customers.

I figure, if LL trusts you with the means of bringing a few thousand processors/cores to their knees, then perhaps it is a fair trade for you to cough up verifiable contact info. By extension, you're placing your trust in LL to protect the privacy of that contact info. I mean, it isn't like LL's customer account info was hacked recently. *cough*

This post is getting too long.

Hi,

Can I answer any of your questions about libsecondlife? You seem to have quite a few concerns.

Since the whole idea was to track the who released , not created, the malicious code using only verified accounts would give LL that ability.

Yes, but since i was responding to the concept that removal of unverified accounts altogether (instead of this suggested way) 'would achieve the same effect', this was comment regarding theoretical situation where there is no longer unverified accounts, but the verifieds are in the very same state we have at the moment...

There are a couple of Feature Suggestion threads similar to this suggestion, created in light of the most recent issues:
/13/ef/141904/1.html
and
/13/6b/141917/1.html

My business in SL is built from nothing. I have a friend who allowed me to rent land, use their SLexchange account in order to get my things out there. I do not like using any sort of credit card, prepaid or non. I enjoy being part of a community where not being in debt is not a thoughtcrime. I am one of those who doesn't have payment info. I didn't see brought up here that many griefers can just use mommy's/daddy's credit card and start over again. It is not hard. The problem is both at the source and at the end. No matter what security measures are implemented there will always be those who bend the rules, continue to defy all morality of any society they are placed in. It is human nature. This is why Linden allows estate owners to ban those without payment info. It puts power in your hands, so you don't have to wait for them to come to your "call in the cache". I do understand your frustration, perhaps you own a business(I didn't look you up) and are frustrated by these grid attacks. I am as well, but the modern age we live in, it happens. Not trying to start a flame, just my two cents.

Thanks for the links Haravikk.

What I'm trying to do is an extension of these by attempting to tie scripters to scripts. The issue I see is that currently, a verified scripter can write a script, put it in an object, then have an unverified alt run it and crash the grid. AFAIK there is no way to trace back who actually wrote the script at that point, so the original scripter has his laugh and just creates another alt. If their ID were in the script they would do this exactly once, then have to come up with a whole new verifiable identity as well as deal with any legal action LL took before they could try again since they would be traceable.

By having a way to get back to the original scripter, you avoid the problem of not allowing free accounts use or transfer of objects containing the "dangerous" instructions. Anyone can do anything with any object except compile and save a script containing the "dangerous" instructions. They can even do most scripting, they just can't do things like rez, give inventory, maybe push, etc. with their scripts.

The embedded ID also allows LL to very quickly identify scripts by the same person and disable them. The current scheme of identifying objects by behaviour, owner name, etc. are really not very effective and take a long time to execute.

Checking to make sure LSL byte code is valid would be time consuming, it would be equivalent to recompiling it (it would use the same code as the LSL compiler just with the keywords modified). It would be a non-issue for LL, to write the key of the uploader into the script bytecode at the server side, though validating the script woud be time consming.

SL was not designed with security in mind, so adding security has been a challenge for LL.

LSL is a sand-boxed interpreted byte code language (the interpreted part is what makes it slow). Assuming the sandboxing is done properly, it can do no more then it was designed to do.

Requiring scripters (who want access to high level functions) to have a Verified account is a good idea.

---------------------

Most uses for LibSL have been as a proxy, to proform a man-in-the-middle attack on the client running on the local machine; not on an arbitrary remote client. What LibSL allows is for the user to inject commands (i do not mean like LSL commands), these commands could be anything from an upload to a rez object command. The issue with LibSL, is that it doesn't play by the rules that the client does, it can abuse the protocall. As a result LL has had to add security for commands at the server level, instead of just client side. LL really should have had the security at the server side all along.

At this point LibSL is a non-issue when it comes to the recent attacks on the grid. LibSL has no bearing on Verified Scripters.

As to the theft of content, there are many generic tools available that could be used to steal content. You can steal content with a hex editor. LL's responce in the past has been, Why should we try to secure what cannot be secured? When it comes to assets (images, objects, sounds, etc) SL is no different then the internet; you can always download or capture the content. The only "solution" is Trusted Computing (a system designed where the user is NOT trusted); and even then it won't be 100% secure, there is alwas a hole (and that is all that will be said on TC as that's another rant).

This wouldn't require that the byte code be tested in any way to assure validity.

When the script was saved, the server would just have to scan the code looking for controlled instructions. It would be more like a modification of the interpreter so it could find instruction boundaries.

Alternatively (and what I would prefer) would be to lock out all bytecode hacks by having the LL compiler append a secure checksum or encrypt the compiled file. I still feel that allowing modifications to the bytecodes is an inherently dangerous loophole begging for exploitation.

In anycase, bytecode hacks are going away soon anyway. LL has said they will be going back to server side compilation, and eventually (Real Soon Now) Mono will kill anything like this.