1400 Second Life Recorded Keys

Personally, I've always been under the impression that publishing someone's UUID key without consent should be a TOS/CS violation, up there with publishing private chat logs without consent.

This sort of non-disclosure is one of the forms of privacy that residents should be allowed, in my opinion.




- How does one get this sort of list?

While the post starter actually yoinked someone else's list URL, most people obtain these by running scanners for agents in high-traffic areas. These include:

- Sandboxes
- Clubs
- Near the WA
- Events

I'm of the belief that personal keys can and should be held privately, since they allow us scripters to run many beneficial scripts. llDialog (pop-up dialog), money (anything dealing with money), llListen (chat-based scripts), and vehicles are all perfect examples.

Also, since they're so easy to obtain manually, the argument "get your own damned key" comes to mind.

I will also note that obtaining a list of this volume is very, very hard to do. It requires time, patience, and a great deal of technical knowledge.





- How can I protect myself?

A person cannot "protect" themselves from this form of key collection, a subject of extreme debate when you realize this is also the lynchpin of ban scripts.

In brief, the argument might be made that certain limitations or changes could be made to better protect residents, for and against using key collection.





- What Can Someone with my Key Do?

They may run any script that requires an agent key. Here is a fair list of what functions that means - a couple of them aren't real functions, so look carefully.

The pros to key collection itself, at the script level, far outweigh the problems. However, the publication of compiled key archives to individuals is another matter entirely.




This form of "open" or even private publication allows several venus for misuse. Among them:

- Spam email (offline IM)
- Spam IM
- Spam inventory items

... all of which could be automated from these lists.




It doesn't take a rocket scientist to realize that this could be a bad thing. However, in the spirit of fairness these things do have legitimate uses:

- The ability to streamline signup for sites like currency traders or object sellers in-world
- Beneficial scripts, such as News Groups and Content Rings
- Ease-of-Use for certain functions

... however, I feel these things should be concensual. That's the missing link in things like this.




At any rate, that's my 2 Lindens on this matter.



Edit, for Cristiano: By virtue of the Lindens doing it does not always make it right, or for that matter, right in "the public mind." It's actually a valid question what this form of communication would do.

I would say it's absolutely fine, so long as residents can turn off unsolicited scripts in preferences. Some criteria for that would be:

- The object/IM/email is sent by script
- The script is not housed in the same sim, or a sim the agent is still connected to directly

I feel that would facilitate more valid use, if implemented.

Key lists have been around since beta - the current largest database of them has some 30,000 keys in it I believe - and it is not the only in existence. Where is the spam, the horrible objects being sent out, people innundated?

You mentioned money functions - the only financial thing that can be done with your key is to pay you - hardly nefarious. Every person who has ever clicked on something or bought something has given up their key for that transaction.

The Lindens recognize the need for this to allow for external sites to interact with SL and conduct commerce. Having a customer go to an ATM to link their account is inconvenient, and a barrier to use. Your post just added more FUD to the hysteria around keys.

This last one caught my attention. I've been waiting for llName2Key() for the express purpose of adding a "deliver as gift" to my vendors. No one receiving a gift would have interacted with that script, wrecking that as useful to me. (This is also why I want script-writable notecards - for gift cards delivered with the items(s) via llGiveInventoryList().)

Now, I can see wanting to offer better control over this. Muting should be by key instead of name to help combat chat and IM spam. llGiveInventory and llGiveInventoryList maybe should not be allowed more than one run per target-key per source-task per 20 seconds.

And any yutz who starts any of the work-arounds that come to mind for these: welcome to banzville.

I don't know why everybody is so worried. Putting somebody's key on the list is basically the same as putting their SL name on the list. It's just a list of players. Or, rather, a list of avatars.

Unless, that is, I'm utterly mistaken about the nature of keys.

Oh! Oh! Can I send you random crap? You'd have to look at it though.

Many of these archives are privately held. Furthermore, unsolicited spam is a TOS violation already, though I'm not sure how often these things are cracked down on.

I would say we don't see them largely because we don't have the userbase that uses this sort of thing. Yet. With the rise of "blanket marketting" tactics, there's plenty we've not seen yet.

If anything, threads like this are what start that sort of crap.*



True - if my post was worded to the effect "people can steal from you," I apologize - that was not the intent.

Rather, the "nefarious ends" are largely related to spam - and certain functions like llGiveInventory do work cross-sim or when a user is offline. These have a broad range of applications, both good and bad.



You're certainly welcome to your opinion, Cristiano. While there will probably be little "real impact" of releasing something like this, I find it better to discuss the issue with what I feel is a more "balanced" take.

Of course, you're absolutely right that a lot of people will read the drama from that directly. Be that as it may, it's information - as close to what I feel is a neutral opinion as possible.

I think things like this should be allowed eventually - so long as people have adequate protection from "the little assholes that ruin it for everyone else." Since that's systemically not that hard to do with some client filters, I don't see a huge problem.

But for now? I'll happily keep my UUID to just a few lists I know of, thanks.

This is valid, Jillian. I agree, and I'll yoink that third one off the list on my earlier post.

Unfortunately, this is incorrect. Key values are a bit different, as they allow people to automate the process of sending/receiving data from certain avatars in LSL.

You can see my responses to that earlier in this thread.

Jeffrey,

There is another misstatement in your earlier post. Keys cannot be used to spam email. llEmail does not take a key. If you receive emails while offline, it is from the use of IMs, which you can send with a key.

Fair enough. While the information in earlier post is technically correct, that one may give the wrong impression - since I believe offline IM-to-email can be shut off or easily worked around.

To be fair, email can be sent to and from objects with a key, but since we're talking avatars... yeah. That routes through IM.

I'll hammer that one as well, for now.

Reminds me of halloween last year. When a large volume of people receieved the Spittoonie Magic Wand. I reported Jack Digeridoo for the spam. He was never punished.

A) This is a very useful list

B) This is very easy to get (no, it doesn't require what Jeffrey is talking about

C) LL should just publish this list themselves.

If LL published the list we would know how many users there are in SL.

I understand what your saying and I asked to have it took off just to make it clear I do not want it used. Never hurts to ask.

True, but getting the list is pretty easy.

And besides, they could just include inactive accounts which would bloat it significantly.

Well blaze, if you want your key published so much, why not put it in your signature and get over with it?

Do whatever you want with your key. Leave my key out of this.

1. This doesn't require much technical knowledge at all... run a sensor every minute or whatever, store the avatar name/key pairs in a variable, once its more than, say, 3800 byes, email it. Parse on other end, insert into database. Pretty damn basic for anyone who's written code. I have to do similar stuff to have people link their avatars in SLBoutique.com.

2. There's really no harm being done here, however... I'm opposed to the sale of public information. Rathe is a good guy, but this is one spot where we don't see eye to eye. There have been tons of these threads over the years.

3. Jeffrey, the Lindens have certain things in place to prevent abuse. llGiveInventory and llInstantMessage both have a 3 second delay (IIRC). The reason spam is effective is because although the response is typically 1 in 1000, they can send out millions and millions of emails within hours. This is simply not a big enough target population to be effective for spamming/scams, and SL has a higher technical knowledge in general than the typical Internet, making the percentage likely to submit to spam even lower.

4. I believe Philip's take on this is the same as with other LSL functions which might be able to be abused... make a policy against it, not cripple it. As Cris notes, this ability has been around forever... yet, I've never gotten spammed or offered inventory I don't want by a script. I have, however, gotten TONS of spam from people putting every card they have in a folder and IMing everyone every time they have an event (3 times a day) and immediately leaving the conference... not to mention being manually passed, many times, invites to stuff from people I've met maybe once. This is far closer to spam than anything a script has ever done to me in SL!

5. I think Adam's call is right. A look up query service is the way to go... not a list... c'mon Lindens, just give us llName2Key already! That will end all this insanity.

Just my two cents.

-Flip

While I don't doubt the value of this, I have conjectured that this is an O(n) database query and therefore would be implemented as a dataserver event and probably an artificially delayed one at that. Any guesses to the contrary?

Yup, that sounds about right.

Still, DataServer event or not it would be handy.

*Information horded due to silly laws that prevent the sharing of common sense*

What is n???

assuming we only want AV names -> keys they should be able to do it in logrimic time to the number of users (assuming the login table uses the AV names as some type of index.. if not I think I have a way of speeding up logins..)

if we want to find the UUIDs of any object in the sim.. then yes n like scanner events.

If we want the UUID of any object in the world.. n = some astronomical number... and I can imagine the assets server's opinion on a query for "Object"....

Heh heh ..

Although, from the responses to some of my scripts, I'd argue this is still a cut above what most Second Lifers are capable of with LSL. No offense to those that don't know it.

It might not seem like a lot to us, but considering the most popular scripts in Second Life are "bling" and "poseballs," I'm going to go with this sort of key collection being limited to the technical minority or people with "access" to existing lists.


This is fair.


Tough call, actually. While the SL population does have "a higher technical knowledge" than the internet, I still feel the average is at the "modify a poseball to play my animation" level.

I will also point to the usage of "calling cards" to do this sort of blanket advertising already (as you mention below). If anyone here with more than 20 calling cards has not received a broadcast "to see their event IM me for a TP," I salute you.

I bring this up because Calling Cards/Friends have an "Off" switch, or did last I checked. Key-level broadcasts do not, and one must remember that it's a 3-second delay per script buffer. I think you see where I'm going with that statement.

Regardless, something like this happening, in the short term, is such a low risk for the reasons already mentioned that the "drama" was never really warranted over it. For the long haul, though, certain controls like client-filtering of these requests would be good for a proactive fix.


I will note that systemic solutions are almost always the way to go, so long as you can distill the "good" uses from the "bad" ones. I feel that is the case here, as with many other "features" of Second Life already.

Ahaha. Clearly jeffrey missed a key post.

I'm not seeing your point, blaze. I'm speaking generally to the issue here, and all I see between the post I quoted and my last one is conjecture.

Unless I'm seriously mistaken on how keys are formed to begin with.

PS: "This" refers to "this level of spam," not "this level of lists being open."