Privacy Mode (Make yourself invisible to scripts)

http://jira.secondlife.com/browse/SVC-1462

Please surf in to the link above and read the comments, and then vote to make your SL experience better.

Basically, it's a way to make you less able to be griefed or attacked.

Of course the usual griefer tool sellers are whining, but they do make an interesting addition to the sane comments made by others.

Whisper~

I dunno. This probably needs to come with a big warning window that has to be explicitly clicked each time the mode is activated, because some very unexpected results will occur, and people will get really confused. For example, as the proposal is worded, this mode will pretty much make shopping impossible because many vendors will quit working, not being owned by the owner of the parcel on which they (or the purchasing agent) stand. (Probably 90% of such land is group-owned, and god help us if vendors start getting Deeded to group!) Same for anti-bot camp pads (this will confuse the heck out of newbies), danceballs on group-owned land... that's just off the top of my head. I'm not sure that it's important that people in privacy mode are able to shop, camp, dance, etc., but it's gonna cause a lot of confusion unless there's a very prominent warning about how unexpected things will just stop working in this mode.

(I can imagine a "patch" to the jira that would get around some of this, if "set to group" can augment the ownership requirements. It's weird though: can't think why this particular jira author didn't do that in the original proposal.)

I don't support the "right to counterattack", finding it the wrong way to deal with the situation, so I generally do not agree with the weapons sellers who, say, argued for keeping orbiting or similar exploits.
That said, I don't see that in this jira. I see somebody raising the valid point, "Are you sure this wouldn't actually help griefers more than anybody else?", and then the issue going on to be horribly over-engineered to a point where nobody would have a clue as to how it actually worked in-world.

I think the current visibility solution is fine. Yes, you can hide from people on your friends list, which I find stupid anyway. Just de-friend them. Done. If you have to hide from your "friends", then I guess you don't really consider them friends anymore.

As for griefing, I don't really see the problem. I can send you an IM, and if it doesn't tell me "User is not online -- message stored for later delivery" or whatever, then you are online. *shrug*

I classify it in the same category of issue as people who worry about someone getting their avatar key. *shrug*

If someone is griefing you, mute them, AR them, and don't give them any reason to get any enjoyment out of harassing you. When it ceases to be "fun", they will get bored and go away.

Yeah, it makes perfect sense to remove all the tools from this DEVELOPMENT PLATFORM because a few people abuse them.

Agreed Jillian. This idea is presented as a means to prevent griefing, and buried deep in the comments, we find that it is in reality just another "I demand my privacy at the expense of your functionality" rant.

You may as well remove the sensor function completely. Which of course leads to why stop there, lets just remove all scripts. Why be able to do anything.

Bad idea of the year.

Way back when, I suggested (and put on that silly voting thing) the ability to make a few hundred meters above a parcel into a "privacy pocket". The area would be controlled by an access/ban list like parcels are now, with the addition that any avatar or object within that private area would not be described to clients outside of it. In effect making it totally invisible to anyone outside the "privacy pocket". Real SL privacy. Plus it would reduce some simulator bandwidth load. And no tools would need to be broken. The idea was accepted by LL but never implemented.

If you want real privacy, push for something like that. Don't remove tools and turn SL into nothing more than a resource hungry chat room.

Woh, maybe you misread the proposal, or maybe I did (surfs in again)....

It will do the following:
- Make you invisible to sensors, unless you are the owner, or on the owner's land (so security scripts can still see you).


- Make you always return an offline status to llGetAgentData() calls, unless you are the owner, or on the owner's land (though why it'd matter is beyond me).


- Make you always return null values to llGetObjectDetails() calls using your avatar key, unless you're on the owner's land.


- Make you always return false, or an error to calls to llGetAgentInfo() unless the script is owned by you, or you are on the owner's land.


- Causes you to ignore attempts to get permissions from you (e.g to animate you), unless you are the object owner, or on the owner's land, or sitting on the object (in which case permissions are automatically given as normal).


- Causes you to ignore dialogues from objects, unless you are the object owner, or on the owner's land, or sitting on the object (in which case permissions are automatically given as normal).

mmmm, nope. Seems that all bases have been covered to me. Gives privacy from all but the land owners. What exactly is wrong with that?

If (and when) the system is misused by a griefer to hide from sensors, then what exactly is different from the current situation, where a griefer simply leaves it's particle emitter/prim bomb and LEAVES THE AREA TO GRIEF SOME OTHER SPOT?

This proposal at least gives residents some protection against follower objects and other malicious objects.

Please feel free to point out how it takes away your right to enjoy your parcel of land.

In fact, the only argument I can see which is valid, is that this proposal will "break existing content". Well, I don't want that content. I'm pretty sure that 98% of regular Second Life users DONT WANT THAT CONTENT EITHER.

We don't care about visitor counters. We don't care about rented shops, we don't care about your weapons sales because we are not here to buy or use weapons. We don't give a toss about your cool hacks, your orbiters, your avatar deformers, or your followers.

We want a way to opt out or your crap, and we want it now.

Well, M'dear, let me tell you what:

Your proposal would break my CCC and Cubey Terra's TCS as well as several other opt-in combat scripts. (These sensor based scripts were made so that they could be used anywhere in SL without flicking physical prims about that could disturb other residents.)

Your proposal would break my gift-delivery system, which checks if the intended recipient is online (to avoid SL's nasty habit of truncating offline anythings.)

Your proposal would break hug/kiss attachments.

Your proposal would destroy every vendor that uses dialogs that sit in SL malls.

That's a damn high price to pay because you and your posse can't or won't use the tools _already_ _available_ to neutralize _all_ the sorts of greifing your trying to stop.

If you "don't care" about any of that, there are hundreds of other social programs out there that you can go play in, many with a 3D avatar you can run dance animations on and make "vvVvHOWWWLLLLvVvv".

While I do not have statistics on the rest, I am fairly sure that more than 2% of the SL users care about shops. -Not that you can't run a (rented) shop without a sensor; the blanket statement just baffles me a bit.

But on the topic of throwing out percentages, I think that the main issue here is that way, way more than 98% (to use that magic number) of the uses of the mentioned commands are quite legit, and used for things which enhance the overall experience, and crippling that to get rid of less than 2% misuse seems like gunning for the wrong target.
A couple of twisted tori can bring a sim to its knees. Should we also introduce an estate/parcel toggle for disabling the "twist" option in the edit dialog?
Frankly, I see no rational reason for singling out one LSL command, and declaring it the root of all evil. As has been pointed out several times, if one thing is restricted, griefers will just move on to use something else. You can then campaign to restrict that as well, leaving a wake of crippled features as we move along every single thing which can somehow be misused.
I don't think anybody are denying that some measure of control is a good idea (like, say, the "Restrict push" option), but it seems to me that most feel this is going too far. -Irrespective of the rather shrill cry of "I know what 98% of the users want".

But to take two steps back; what is this Jira feature request actually trying to accomplish? If I read it correctly, a way to avoid that anybody (or anything) can interact with you, presumably to be able to build in peace (since pretty much any sort of socializing or shopping requires interaction). If that is the actual objective, singling out a few LSL commands seems like a bizarre and ineffective way of going about it, and something like the "private zones" Jillian suggests seems like a better idea, enabling you to effectively temporarily "detach" yourself from the main grid.

Forgive me "my dear", but those things are broken already by parcel settings which disallow object entry and scripts. In fact, the only place those things will work with any reliability is over a single parcel with the the correct settings, and in fact, anyone wishing to use either will most certainly ensure that they are not in the suggested privacy mode.

Gift certificates. I have a whole collection of those UNUSED both in RL, and SL. Oh you vendor checks the online status of someone? So lets see, in "privacy mode" they appear offline. What exactly is your issue?

It's not about you. It's about the consumer. Might I suggest you take advantage of progressive thinking and learn that when someone says "DO NOT CALL", you DO NOT CALL?

Movelock breaks hug/kiss attachments and many other attachments and yet it's a standard script that I am willing to bet you would willingly turn off to accept a hug, only to turn back on again post hug.

As for SL malls and the vendors that sit in them displaying Business In A Box wares, great. I hope they all break, more power to the talented with a 512 of their own and a premium account.

I believe I've bought some of your stuff, I'll check when I'm inworld, I seem to recall a helecopter, but i own several from several different creators.

Now, do you have any real concerns?

QFT



As far as I can see it will break zero content that the user would actually care about. SL is not about scripters and Shop owners. It's that simple.

Being someone who regularly shops and spends in the order of 10 20 thousand lindens every month on top of tier, I can offer my personal insight into the mind of a good little consumer. I also script.

I want you to imagine for a minute that your email was able to be delayed or deleted by others using the same mail server that you do.

Imagine that you were ok with this, because there are only 20 people on the same server, and you know them all, and trust them not to.

Imagine that over time, that population grows to 9 million people, and you know that people are delaying your mail, and deleting your mail, but "that's the way it's always been" so that's the way it's going to stay, and there's no other mail server around that does deliver your mail the way you like it *most of the time*, but when things go *&^%, mail gets lost. It's important to you to find a fix.

SL is no longer a small community of like minded people. Things must change. While this Jira proposal is not a perfect solution, lets try to make a constructive effort to improve it to the point that it will be, and not dismiss out of hand what appears to me and others, to be a workable solution.

Excuse me? My CCC scripts work just dandy fine and are in no way affected by object entry settings.

Anyone wishing to cheat would use your 'privacy mode', however.

I note you don't address that the tools are already in place to handle your concerns.

I also note you didn't address any of the other problems your proposal would cause.

Sure it is, as well as their customers. SL is a development platform. The core problem with your proposal is that it scuttles tools - that weakens SL's usefulness as a platform.

It would be a FAR better idea to offer easier access to the current anti-greifing tools. As in the RC client, clicking on a name in the chat history pops up the chatter's profile - it would not be much more trouble to add a quick option to mute objects in a similar fashion, and it would also not be too big a deal to add a second level of "mute" that would cause avatars or objects to become non-existant from your point of view.

That would have far less of an impact on the platform and still make those pesky little 13 year olds a non-issue.

I'm really not sure it's even possible to understand what the proposal *is*, now, with many conflicting amendments being floated in the comments, including by the jira author. It seems as if there's currently proposed two authorities over the detectability of an agent: the agent itself, and the land on which the agent stands. If no special land authority is exercised, then the agent can make itself undetectable to everything not owned by the landowner and on the parcel where the agent stands. If I read correctly the trend in the more recent comments, the land could also be set to permit anybody and anything on that land to detect all agents on that land--working the same as pre-jira, within that parcel.

So, with that amendment, it seems like combat systems should still work within single combat sims that turned off the proposed feature (as long as the sims aren't divided into parcels, I guess), but would break anything that crossed sim (or parcel) boundaries. Well, even that could be worked-around with some laggy cross-border comms scripting, maybe. (But I barely know what a combat system even is, so this may be wishful thinking.)

What worries me is that attention to the jira has been quite narrowly focused on the functions of griefer/anti-griefer/combat sensors. But the proposal's effects go *way* beyond that, and what I perceive as the big breakage has nothing to do with any of that. And really, it's not so much that the breakage is going to be so severe, as that such unexpected things will break in such weird and inexplicable ways.

Remember, it's not just llSensor that this affects. And believe me, it's not just "weapons" scripts that use llSensor, llGetAgentInfo, llRequestAgentData, llGetObjectDetails, llRequestPermissions, etc., for agents with which they're trying to interact. Just a stupid example from one of my silly hacks: a visitor couldn't even shower at my place "in privacy" unless I deed the shower to the landowning group (or, if the comment-amendments hold, unless that group sets the parcel to be exempt from "privacy". They also couldn't use my danceball.

Come to think of it, all dance chimeras would be immediately and quite irreparably obsolete.

The fact that the "non-weapons" b0rkage wreaked by this jira is so untreated in the comments is just scary, and enough to make me extremely skeptical.

I would like to question your assumption that you speak for the majority of users. From the tone of this thread it apperars that you do not.

Why would they cheat if they are willingly playing a game with a friend? Do you you cheat? A cheat in fun perhaps? Maybe. In my personal experience one does not gain from cheating in those situations.

The tools are out of date and designed for a SL of 2004. We have come far from there.

The problem you and I have, is that you are seeing SL from the perspective of a Vendor from 2004, I am seeing SL from the perspective of a consumer from 2008.

You want my lindens, and I want to give them to you, but I don't want that transaction to mean that someone else can give someone Lindens and use an object to make my SL experience any less than it is now.

Nor do I want some clever halfwit to be able to do it for free.

You must make up your own mind about that

ALL Vendors not on a home parcel (this includes all avatar, animation, accessory, clothing etc vendors) would be broken by this proposal and force some of the best designers out of Second Life. In addition all Second Life Exchange and other similar systems would be broken.

Drop the attitude of superiority (you are no better than anyone else), drop the false perception that you speak for anyone but yourself.

Go back to the drawing board for this one ... apparently no one thought this proposal through.

Jira that and I'll vote for it.

It's interesting, I've been in SL for over 2 years now and I can count the number of times I've been affected by griefers on 1 hand. The same can be said for most of my friends as well. So it's rather ironic that people like the OP have such trouble with griefers that they try to have perfectly legit scripting functions nerfed and then lash out at those trying to explain why it's not a good idea. Yeah, ironic...

I might draw your attention to the Jira proposal to defeat the sit target offset changes which effectively made your avatar invisible to llSensor() while it was within sensor range.

Despite an overwhelming majority in the positive (revert the change and let existing content continue to hide avatars) the change was carried.

This made it possible for llSensor() to work as written in the description. Just an example of an outcome that went against the popular vote.

Yes, it carried because it was a bug. And the content that was broken was content built to take advantage of that bug.

This will carry for a slightly different reason.

Those who choose to enable this new feature, will be effectively saying no to your objects, and your scripts. I.E. Nothing will be broken. It's posed as a choice. The choice not to be annoyed be it by a vendor, an animation request, or a griefers script. If done well, it will be easy to enable, and to disable.

There need be no drama. No "ZOMG MY STUFF IS BROKEN NOW".

Those that want to use such a feature should be free (as consumers) to enable it. Free as in DO NOT CALL.

If this is a proposed new mode, just like busy mode currently is, then I don't see why others are arguing like the intent is to permenantly disable those functions... talking about vendors and combat systems and broken content... it would be a TOGGLE, yes? So you turn it off before you do something, just like turning busy mode off before you take delivery of something while shopping

Exactly.

But it's going to be an awfully difficult choice, I think, and extremely unintuitive for most users to understand the implications of choosing the "privacy" mode. I really think that 90% of users will keep this disabled all the time once they begin to understand what it prevents them from doing; of the 10% who might use it they'd leave it off 90% of the time; and 90% of land will override the setting anyway.

Even if somebody can figure out how to explain to a user all the strange stuff that won't work in this mode, and all the strange *ways* stuff won't work... even then, it's really hard to see how it's gonna be worth the considerable effort to implement this, for the very small share of user-hours it would have any utility.