in certain areas like sandboxes, people wish to avoid being followed by maliciously scripted objects, yet at the same time wish to communcate freely.

IMs, chat, and such. I see the solution in dividing this functionality into a small menu, where you can select each of the above listed effects individually, leaving it to the user just exactly how they wish to be detected.

And yes, I agree that the land owner's scripts should override those selections.

The second issue I see are combat areas, where this functionality would pretty much enable a form of immortality, which means it'd also need an estate option where the estate owner can disable this functionality completely.

And third, this will in turn again break another whole market of 'defense' products, as griefers in turn themselves can evade everything. Leaving discussions about the ToS aside, it'd be a heavy hit to some product creators with good intentions.

I still see the reintroduction of phased functionality as the best thing, as:

1. it still allows proper use of combat areas
2. still allows people to evade annoying followers
3. does not break existing content
4. can be circumvented by more complex scripts than single sensors, like many security systems actually do. (see edit further below for a better solution than what's currently possible)
5. Does not actually prevent another person from AR'ing you into the ground if you misuse it.
6. Does not actually allow you to enter land you're banned from

I can only repeat a previous comment in another JIRA that by the logic of 'you shouldn't use bugs but remove them, and request a new functionality that is proper', you'd also want the warppos hack to be removed, and leave it to people to request an llWarpPos() replacement in the meanwhile.

Heck, I actually wonder just why LL hasn't implemented llWarpPos() yet, seriously. They seem to accept warpPos() despite it breaking through intended boundaries. Very same thing.

My own solution to the dilemma simply would be a llDetectUsersOnLand(). If you're the land owner, you immediately get the list. There. Security systems and land protectors will give a damn about phase, while elsewhere it will still be a good way to evade malicious objects. I don't see why this wouldn't be the best solution for everybody, without breaking anything.

As for IMs and chat, I suppose those can be much more easily addressed by having that functionality combine with invisible functionality somehow. For example, if you are invisible but NOT set to busy then you receive chat/IMs as normal (but given an offline message to users), if you are invisible AND busy then the messages are ignored (unless from a friend who can always "see" you) and are queued somewhere instead.

This can all be done on the viewer-side, I'll edit the issue as the main focus is in restricting scripted items.

[edit] Your comment regarding warp-pos doesn't really apply, as llSetPrimitiveParams() never specified that an object can only be moved 10m in a single call, PRIM_POSITION is the item that the limit was applied to, so using it multiple times is technically valid.

Wording such as "Allow users to enable private mode" would probably suffice, all it needs is a clear description like:
"Users in private mode will be visible to your scripted items while on your land, but will appear invisible to other people's items"

It would be in the best interests of places affected by these problems (such as sandboxes) to enable this.

This would also be a fantastic addition to combat sims, since you'd have to use actual weapons to shoot at people, instead of just rezzing an auto-turret or some other crap.

1. when out with friends shopping in some big mall personal radar is a nice way to find them quickly, without it I wouldn't be able to see where the hell she was. Granted I could use the "show on map" feature but if that's not enabled by all my friends (which it isn't, only my partner has that turned on) I'd have to walk around searching or ask them for a tp.
2. Handy to know in a club or other social situation who is about, and what thy are doing (mouselook, sitting etc.). This is useful just for general awareness, to know if friends are near, lookout for potential threats and simply being a host.

I agree with your point about combat sim though, it would make them a lot more fun, but only if they were representing a low tech combat environment. Maybe what's needed is your suggestion but perhaps more granular in some way, like a list of functionality that can be turned off individually to allow the land owner to simulate any kind of experience they desire, from "feature sterile" right up to "full features no safeties" including only allowing scripted devices made by certain people, or the inverse and banning scripts written by certain people, say known griefer tool makers if so desired. Could even be designed with templates of feature sets, so you'd select a template and tweak from there.

This would allow for instance banning all scripts but allowing AOs to still function so you could have a very safe art gallery, without people looking like day old avatars walking around jarringly.

The Lindens already have the ability to go off sensors and avoid interacting with physical objects. We need that function to be added as a LSL command.

There can be some basic rules to when it should work.

1) You cant hide from objects owned by the land your over.
2) You cant hide from phsycial object that have damage enabled when your over damage land.

I dont think there needs to be an estate level tool to shut this off because it will not work if your unable to rez an object or unable to run script over the land. Those two are very powerfull restrictions which are often overlooked.

One assumes you must wear or sit on an object that issue this new provacy command?

Darling.

Scripted support would be interesting, but I think it is best implemented as an avatar feature, which scripts don't really edit at the moment. This way disappearing off a sensor is simple as setting "Invisible" or "Private" mode on yourself while you're in a sandbox or other area. Then if you go somewhere you trust, or want to let someone use a hug or similar item on you then you can switch it off.

Invisibility from sensors is a delicate issue of antigriefing tools vs. legit content.
Since SL is by definition a social interaction environment, I don't see this happening so broadly anytime soon.
If you are somewhere in SL, sensors should be able to pick you up. That's a basic component of how the world works.

From what I understand, there is already an SL client out there which pulls the avatar-in-sim data from the datastream of the sim itself, completely bypassing sensor necessity. Breaking llSensor would therefore serve little purpose.

An alternative might be the ability to make yourself invisible from sensors/objectdetails IF you are on your OWN land (and if you are on land set to / owned by a group you are in) (except ofcourse to other ppl who are in the same group).

The linden sandboxes are ill maintained and a waste of time to try to do anything in. The grid has plenty of resident run and moderated sandboxes now.

Not to mention that this feature would be useful as I say in properly implementing "invisible" log-ins, since you will no longer be trackable by simple online/offline scripts or other workarounds.

This sounds like the crippling of a feature to fix a problem (griefing) that is in essence a policy issue, not a technical one.

While I do approve of the ability to have a privacy mode/feature, I think that making oneself invisible from sensors should ONLY be possible on one's own land, or land owned (or set to) a group the avatar is in.

IF, however, this solution will be applied regardless, scanners should not only work on one's own land, but also on land set to/owned by a group the avatar is in.

I hadn't though of land that is only set to a group (opposed to deeded), it is however a very good point as at worst it places the burden of security/privacy onto the group. I will amend the issue if no-one raises any potential faults with this change, as it should let things like hug scripts and other social devices to work quite nicely, provided the group is confident its security measures are appropriate. My only thought here is that Linden sandboxes and other public places would have to be set to a group that doesn't have open enrolment, or to no group at all.

I do think that there need to be limitations on when it can be turned on, but more importantly, in what the individual can do while their avatar is in invisible mode. Pardon me if I seem like I'm asking a million questions, but I do want to know more specifics, or get people thinking about specifics, before an issue like this is implemented.

What would invisible mode allow the user to hide from? Obviously it would prevent an llSensor() call from returning their info, but would it also render them invisible? Would they still have a dot on the minimap? Would they appear offline on their friends list (with perhaps the option of allowing certain friends to see them)? Would they be phantom/nonphysical? Although granted, Havok4 will resolve many of the issues related to being able to push avatars around.

Secondly, what limitations would be imposed upon an avatar in invisible mode? What I mean is, if the other avatars and scripted objects are limited in their ability to interact with the invisible avatar, shouldn't there be some reciprocal limitations placed on the avatar? This would allow the mode to be used by those who wish to build in peace or have a private moment with a friend, without enabling others to grief anonymously. Here are a few possible limitations that I feel ought to be used:

1. An invisible avatar should NOT be able to emit particles, neither should any of their objects in the current simulator while they are invisible. My reason for stating this is because the best method of getting rid of particle spam (aside from turning off particles entirely) is to mute the user whose object is emitting them. So someone might perform a sensor scan to see who is around, and try muting various people to see if it stops, but they would not return the invisible avatar. Furthermore, since an invisible avatar has essentially "muted" certain aspects of the rest of the sim, it makes sense to automatically "mute" certain things from him, such as particles.

2. Objects rezzed by an avatar who is in invisble mode should be phantom and nonphysical, and setting invisible mode should turn the objects owned by an avatar in that current sim phantom and nonphysical. Obviously we don't want to prevent someone from rezzing objects in invisible mode, since we want them to be able to build, but limiting their objects to phantom and non-phys should limit the amount of griefing that they could do with these objects. This way an invisible avatar could not orbit (although Havok4 will take care of that anyways) or cage, or push others. Again, because an invisible user is choosing to wall off the rest of the sim, it makes sense that the rest of the sim should similarly be immune to his/her actions.

3. Should scripts in objects rezzed by agents in invisible mode still run? The reason I ask is because obviously someone in invisible mode could just as easily rez follower objects themselves. On the other hand, there are plenty of legitimate reasons why someone might want to use scripted objects in invisible mode (Skidz Primz, for instance, if they're building).

SecondLife is a social environment, and if we enable the ability to limit the extent to which that environment interacts with them, then users should also expect that doing so will limit the extent to which they may interact with their environment. In essence, I am saying that invisible mode should be a "two-way street."

The main thing I'm aiming to combat are items on land that is not owned by the item's owner. e.g. - litter in sandboxes, or attachments on other avatars. But bundled within this is the idea of privacy, so if you don't want to appear as online to a script, then you wont.
However, if you're over someone's land, and they have sensor based items on their land (such as security orbs etc.) then you would be visible to these, as they are there to protect the land, track visitors etc. which land-owners are well within their rights to do.

The problem being addressed here is that people can harass others using sensor-based scripts, or other scripts which can use an avatar's key to grief someone. This should be able to prevent that, without impacting the security of land (by breaking common security devices), or breaking combat/games which use sensors (which is why making a parcel option to prevent invisible mode is a must).

Thank you very much Jahar though, you're thinking carefully about it which is good, and all your points are excellent ones, so I'll try to address the 3 main ones you've outlined:

1. Since an invisible avatar should not actually be invisible this shouldn't be a big problem, you'd still be able to right-click them and look at their name, or right-click their item(s) to get a name from these. Beacons are very useful in finding the source of particle spam. After this you just block the name that way. For all intents and purposes though the "invisible" avatar is otherwise offline to you.

2. Again, while the avatar may appear offline, you'll still be able to see them, and if you get hit/orbited by one of their objects, it should still appear in bumps/hits/pushes.

3. I'd say so, but they'd have the same limitations as other scripts; if they are placed on land the avatar does not own, then they won't detect other invisible avatars.

Hope that clears some things up, it might be worth me coming back and re-wording things a bit, since "invisible" may be a misleading word, as I'm not proposing actual invisible or "ghost" avatars, or it was not my intention at least. I'm shooting for the privacy aspect of not being seen as online by scripts etc. =)

with regards to the points (helps keep things easy to follow ):

1. Your point is valid. I might still be a bit concerned about individuals who use scripted attachments to spam particles in no-build zones, inasmuch as I would hope that these attachments would still show up on beacons even on an avatar in this mode.

2. Unfortunately, there are a number of devices that claim to deliver an "anonymous" orbit or push, which will not show in the bumps/pushes/hits menu (although my experience has been that third-party devices such as Thomas Conover's "Who-Shot-Me" gadget will still report these). While these devices are mainly marketed as a method for avoiding an Abuse Report, they could, when combined with this mode, create the potential for serious mischief. Also, there is the question of whether the third-party hit detectors would detect a push from an avatar in this mode. After all, if you are invisible to other scripts, would your orbit also be invisible to these scripts? After all, the same function, llDetectedKey() is used whether it's a sensor() event or a collision_start() event.

I would hope that a collision_start() event would still return the UUID of the colliding object, and by extension, that llGetOwnerKey() would provide the owner of the object.

3. yeah, makes sense.

As I said, my main concern is that griefers are almost certainly going to turn this mode on as well, so might as well make sure that they don't gain any advantage from it.

2. I'm thinking there would be no need to have invisibility affect calls to llGetOwnerKey() or similar functions, as these don't describe the state of your avatar, merely ownership of an object. Obviously once you know the owner of an object that hit you, then it implies they are online, but it doesn't allow you to find out anything else about them, or check the avatar's online status whenever you want, provided llRequestAgentData() is suitably modified to return "offline" regardless of actual online status.

Basically this proposal is to let avatars hide from, or return "null" results to, any script call that lets you know they are online, or target them physically (i.e. - their position). Functions which just return a key for land-ownership, object ownership etc. would be unaffected, since all you can do with that is IM someone, and you can stop that easily enough by muting them.

1) The griefers WILL take advantage of the invisible system to become even more efficient griefers (especially towards less techsavvy users).
Also, rightclicking the avatar only works if you can see them. I can turn my av visually invisible already, by compressing it into a ball and putting an invisiprim around it. llSensor is a useful way to find and smoke out griefers using this trick.

2) The griefers WILL find a way around the inability to scan for avatars; even if it means going back to manually flying around and shooting your ass.
And you'll have lost a line of defense.

In the end, protection from griefers IS a policy issue. Remember the old quote about sacrificing freedom for security ?

I still support the ability to not show up on sensors on your own land, or land owned by / set to a group you're in, but not the other way around.

And ofcourse, this will break content, starting from a simple multichair variation that rezzes chairs based on the amount of avs detected in range to who knows what. And no, not ALL content is rezzed on "permissible land" (land the itemowner has rights in).

How about an "invisible mode" that will phantom your avatar ?
But in return, your av would not be able to move around, therefore it would have limited use for griefers, especially since it won't require breaking llSensor.

OR: how about the ability to go invisible from llSensor to only work on public land / sandboxes, or for it to be an option in the landsettings, like "restriction from push" is a landoption too.
In this case however, it should default to "everyone should be able to scan and detect everyone else".

EDIT:
I almost forgot:

Let's not forget the ability to modify the client to have a built-in avatar scanner, not based on sensor returns, but on data streamed to it from the simserver it is in.
This probably won't stop that ability, since the avatar is on the simserver no matter what its privacy settings are.
In other words: the griefer will still be equipped, and you'll be sh*t out of luck trying to detect him.

having it be a user setting would allow a user to bypass what a land owner wants.

estate option maybe.

viewers already have the ability to see all users in a sim, so any "invisibility" you think you will gain is security by obscurity and the feel good type that provides none.

let me add in addition, that the issue of llsensor and IM/group functionalty should not be lumped together, while your ideal of invisibility is nice, llsensor is a core lsl function that has been used for years, where IM and group online status is a very different precense issue.

i'm all for a privacy mode that deals with, being online, IM, group ect. But if i'm in a sim, I don't expect people around me not to be aware that i'm there.

However, I think what Haravikk wants is something much more specific, which is to have a method for avoiding follower objects that are sometimes used to harass and annoy. These objects use the llSensor() and llSensorRepeat() function calls to get the position of the avatar in order to follow it around the sim. They range from annoying or obscene images and shapes (cubes with pornographics images, prims designed to look like excrement) to particle spam that slows down client performance, to objects that play annoying sounds.

However, given that the problem is not specifically the llSensor() function, and given that the llSensor() function has a number of legitimate uses and is used throughout SL, perhaps there is another way to stop follower objects from being used for griefing without either "nerfing" the llSensor() function or creating an invisibility mode that could be abused by griefers.

What if an object required permission to follow (using llSensorRepeat()) an av other than its owner after a set period of time. Thus, llSensor() would not be affected, and llSensorRepeat() could track an av for some period of time, or perhaps indefinitely if it was a certain distance away or if the object itself did not move, but a moving object that was continuously using llSensorRepeat() to track and follow an av closely would only be able to do so for, say, 30 or 60 seconds, after which it would trigger an llRequestPermissions() dialog?

Of course, it should be mentioned that there are still even legitimate uses for llSensor() and llSensorRepeat() in the context of following object, just as tracking "sniper" damage bullets.

Also, as with many other proposals, the owner of the land should be exempt from this limitation, as there are legitimate reasons for temporarily "trapping" an avatar and giving them the option of teleporting back to a welcome area, or being teleported home.

My guess is that the concept I've just laid out is probably not going to work either, but at least maybe it will suggest other options.

To partially recap, and suggest a set of features:

• It should give an AV the option to completely hide from sensors, getobjectdetails, getagentinfo, getagentdata
• The landowner and their objects are not subject to this option's limiting effects. If you are over somebody's land, they should be able to get your info, period.
• Add a per-parcel setting that allows disabling of this function. Have it allowed by default (however, do not enable the client-side option by default). This will take care of people wanting to run combat sims, or wanting to disable the function on their land for any other reason
• allow owners who have this functionset enabled on their parcel get a list of all agents that have this option currently enabled and reside on their land.
• Quite possibly only allow this option for Avatars that are 10+ days old, or something similiar. instant alt accounts used by griefers over and over sadly make me think that such a small barrier'd have to be in order.

I don't see why the above featureset should be of any negative impact. People whose systems on their land rely on this function will still work, shop owners' objects can still greet people as they own the land, and mall owners, rp area admins or the like can disable the client-side option to make things work there as well. I don't see how this has a negative social impact if the land owners actually take care of things, nor do I think that a big part of SL's social life consists of sensor functionality.

p.s.

'...there are legitimate reasons for temporarily "trapping" an avatar and giving them the option of teleporting back to a welcome area, or being teleported home. '

Land owners can already do this with the right click -> freeze function on AVs that are above their land.

I don't really see the impact on personal sensors vs griefing; all the griefer has to do is put draw distance to 100m or more and fire at you from more than 96m away. There are ways to hide from targets with or without this feature being added, so I don't believe it would make any real difference to griefing. There are better tools for detecting who/what attacked you anyway. But automated objects are a much greater nuisance in many cases.

They want their original content back, not some new feature that is strictly controlled by people who don't care.

Proof of this: SVC- 1475 has 138 votes. This one only has 6.
Also, SVC- 1475 got more votes in less time.

Someone fix this before i open a jira on the effects of security orbs and grid exploring.

SVC-1475 has been closed, and that is unlikely to change, as the proposed solution to the problem it seeks to address is evidently the wrong one. Not to say that this is the right solution, but I certainly hope it stands a chance of being a good one.

As for security orbs vs exploration; it is a discussion that has been to death. I am of the opinion that it is unfortunate that there are so many poorly coded or over-zealous security devices out there, but also feel that every landowner is well within their rights to deny people access to their land, or to parts of their land as they see fit. I put my own home high up with a security device to protect it that I coded myself to be as unobtrusive as possible while keeping people out. However I have left the land below nice and empty for wanderers on foot, and left my airspace empty for flyers.
Being able to just explore is nice and all, but unfortunately it's not a right you have as a resident, as the rights of the people paying for their land have to come first. Better Linden-owned public access would be a great boon to exploring, but unfortunately that isn't here yet.

JIRA votes are purely a method for estimating the level of interest in a new proposal, or the number of people affected by a reported bug. Vote levels help LL staff determine whether an issue is important to the community at large or merely one of parochial interest. However, comparing pure cote tallies is ridiculous, severe bugs will often be fixed with only a handful of votes if it is obvious that a situation needs correcting, while other proposals that simply aren't feasible will not be resolved regardless of votes. Votes are about interest level, but they say nothing about the actual proposal's validity, feasibility, and worthiness.

As for this proposal, I am still unsure...I just want to be certain that there aren't any unintended effects of such an option, and that it is clear what functions the option will and will not affect.

I'd also be interested in hearing from some people at Linden Labs as to the feasibility of this option and the feasibility of the various permutations mentioned in the comments (ie "we could implement the option so it would do A,B,and C, but I don't think we can do D without having to do some serious recoding").

"I'd also be interested in hearing from some people at Linden Labs as to the feasibility of this option and the feasibility of the various permutations mentioned in the comments"

The options described in the issue writeup all sound doable and beneficial. I don't think we'd want to start changing the rules about objects people rez though: I haven't seen a convincing argument that those shouldn't be detectable, and it would really bloat the scope of this change.

We certainly wouldn't make avatars invisible to other viewers. Never being sure who's around would make the place positively creepy.

I say this because there are devices out there that are already marketed as causing "anonymous" orbits and pushes, and the makers of these devices have offered advice on their websites to their customers on the best methods of using inconspicuously so as to avoid ARs. Even though it is still possible to detect these attacks (although they do not show up on bumps/pushes/hits), I would still be concerned that the appearance of a method of delivering a completely anonymous attack would likely encourage people to do so. Preventing certain griefing objects from working while in this mode would be a good way to prevent problems before they even start.

Griefer with modded viewer presses launch button on his missile.
Viewer sends the coordinates of the target avatar to a server, missile does a httprequest to the same server for the vector (all in less than 1 sec) and off it goes.

Better yet: get a viewer to directly print out the av's coords in userchat, special channel; have rocket listen to it and take those coordinates.

2 possible ideas for griefer exploits bypassing the breakage of llsensors, just thought up in a few seconds.

Again, no problems with a privacy mode (god knows I can use a few minutes to dig through incoming IMs on login), but don't expect the breaking of a legimitate function like sensors to stop any semi-decently equipped griefer for more than a second (and yes, if it's broken, you'll see them flock to modded viewers with incredible speed ).

If I can come up with 2 in a few seconds, imagine what determined griefers can and will cook up with time to spare and the technical expertise to pull it off.

A summation of my pov (collated from all my posts on this issue, for easy access) :

• If you're on your own land, you can restrict any and all access already to cover yourself if you want to work in peace.
• If you're in a sandbox, you're in a public area and should not expect privacy, not in a social environment like SL.

• Generally, you should never intent to break a function in order to get some protection, it will be bypassed in a heartbeat, doing more damage to legit users than to griefers.

• If breaking sensors becomes a landsettings option, it should be turned off by default (pushrestrict is also turned off by default). Defaults should never be set to the most restrictive setting.

No, this isn't about privacy in sandboxes..it's not about priacy in terms on not being rendered on the screen at all. it's about online indicators, in-parcel location aquirement, and a huge glob of following, screaming objects filling up your scream, using sensors to stay right on top of you. And I've seen it happen outside of sandboxes often enough.

I agree tho, that the AV with this option enabled shouldn't just 'vanish' from the screen as a whole. That'd make no sense, and be quite abusable.

Also, I don't think it makes sense to go the 'but some people have modified clients' route. If that'd ever be considered, the recent removal of display of UUIDs of textures by ctrl+alt++shift+t keypress in admin mode would have never happened. Because, you know, other people might use a viewer that still shows it? :> I think modded viewers are neglectable.

I stick by my little summary of my last post on the matter.

I'm going to ask you again to please refrain from posting baseless accusations and insults in JIRA issues. The JIRA is not a competition, or some kind of duelling arena for people to spar against one another while hiding behind their keyboards, there are plenty of awful message boards for that. The JIRA is a place for constructive creation of issues so that needed features may be implemented, and bugs fixed, with discussion taking place.

Also added some notes regarding permission requests, and dialogues.

I would use that exact same example to demonstrate my point, so I find it a bit strange you seem to think it benefits yours.

Since the entire point of this issue is to become (more) immune to griefers, you should realize that griefers will NOT be the ones to use the regular client.
(This is the same as arguing that DRM on music battles piracy. It just annoys the legal buyers with restrictions, the pirates get their stuff unrestricted and free.)

Just like the UUID display should never have been removed (it's a cosmetic facade of security, a farce the size of the TSA), so should sensor functionality not be impaired. It will NOT make a sizeable dent in griefer activity, it will break content, and it will annoy the regular customers, while griefers will go on unimpeded.

The last thing we need in SL is "security theater", where LL breaks stuff and removes conventient functions in order to make people think things are more secure, while in reality nothing changes.

EDIT:
as for VWR-812 (and to an extent VWR-951):
I think that we should definitely choose between either one of those, or this (as long as it includes sensor breakage). The combination of these issues is a SERIOUS privacy problem, not to mention a griefer haven.

But that is my point. Knowledgable users will always find a way around obstacles. Yet it doesn't mean one has to make it easy for Clueless McGrieferpants. Which is exactly why the UUIDs were removed after all, despite it only being obscurity.

In the case of griefers, I'd dare to say most don't have any clue about the technical backgrounds involved, and it's that majority that's a real problem anyways. I don't see how this functionality would hurt customers more than griefers, by percentage. Remember, people on their own land will still be able to use the sensors (which mostly get used by stationary stuff anyways) fine. Combat areas still will work well due to their owners disabling the new privacy functions there. And it's not like I constantly walk around keeping an eye on my radar.

Noscript areas do alot more damage in that regard, as they even kill AOs if you aren't wearing them already on entering them, yet I don't see people screaming for their removal all over SL due to them limiting products or social abilities

Is a sensor (under this idea), being run on my "own land", able to detect an avatar within its range (with privacy on), but not on my land?

("my land" meaning all forms, incl. groupowned and set to group; for future reference "my land" will always mean all of those in my subsequent posts; just like "sensors" also means llgetobjectdetails)

I'd say yes, landsettings trump privacy settings.

Should a sensor on Will's land detect Chalice if he/she is on the parcel next door (where this mode was allowed), but well within sensor range? Would it matter if that next-door parcel were owned by Chalice or by someone else? I'm not sure whether there is a right answer to that, but it gets even more tricky when you extrapolate further:

What about an object owned by Will, sitting on his land, that uses llGetObjectDetails() instead of llSensor(). Should this object be able to return information on Chalice wherever he/she chooses to go within the same sim? Given that some sims are split up into many smaller parcels, any land owner would then be able to return information from avatars in any parcel in the sim.

Once we start getting into the questions of when someone should expect to be scanned by llSensor() and when they should not, it starts to get complicated.

Does anyone have suggestions for ways to disable follower objects without making an avatar completely undetected by sensor calls?

I think not. Since Chalice would be on property where Will doesn't really have any real rights. Therefore if Chalice is in privacy mode, and on a plot of land (lets say mine for the sake of argument) then they are under the protection of my land from all sensors outside of it or which I do not own.

"What about an object owned by Will, sitting on his land, that uses llGetObjectDetails() instead of llSensor(). Should this object be able to return information on Chalice wherever he/she chooses to go within the same sim"
Again I'd say no if they are in privacy mode, unless they are on Will's land at the time. As this function can just as easily be used to create a follower once a griefer has the key of someone they wish to harass, for example by laying a "trap" prim for the avatar to collide with, or by harvesting chat for names and looking up their keys.

One question is regarding group support, as it presents the greater technical challenge than the basic changes (land-owner-based). What if Chalice is set to the same group that owns the object on Will's land? What if Will's land is set to that group (but not owned by it)? Should Chalice be detectable to it then?

My thoughts are that privacy mode should put an avatar into the "protection" of the parcel they are currently in in most cases. Having better support for groups would be good, but gets very complex and confusing, and potentially very buggy. I believe that in the majority of cases groups shouldn't be a real issue, so long as objects owned by group, on group-owned land work as with user-owned objects on user-owned land then it should suffice for now. Groups open a whole can of worms due to the difficulty in caching/updating the data, checking roles and so-on.

The only alternative I can think of is a way of preventing sensors within objects that you've muted from being able to find you. But the fact you'd have to right-click and mute at least one object means that followers are still hassling you in some way. Plus I believe the technical side of implementing that would be a lot messier (sims would have to track who can sense you using a list of muted owners, rather than just doing a few quick checks such as; if !privacyMode && owner == landowner then sensed).

The limiter should be where the avatar is at the moment of pickup, and the landrestriction on the parcel the target is on.
Unless it is scanned by a sensor owned by landowner, or set to/deeded to group the land is set to/deeded to (of that same parcel).
Sensors on other parcels cannot gain benifits from their accessrights on the parcels they are on.

Additional thoughts:

There would probably have to be an estate override setting, that when turned on allows everyone to scan everyone else, regardless of individual parcel settings.
Idea here: defaults are always the least restrictive; overrides make things more restrictive when they're turned on.

Also: estate owners might find it annoying not to be able to scan their own estates due to parcel restrictions, and land has no "estate rights" in the sense that an object owned by an estate owner cannot bypass landsettings. (Hence, amongst others, the need for an estate override switch.)

I'm still not convinced this is a good idea; Pushrestrict had much less of an impact, since push is only one way to physically move items. Breaking sensors seems to be an all-or-nothing deal.

As for alternatives:
I can say right now using permissions to ask the target if the object is allowed to follow will most likely not work.
The reason for is is that a follower would scan, then extract the location of the target from the scanned data (lldetectedpos), then move the object to that location.
At no time is the object "following" someone, it's just moving to the location a scanned target is in.
Hence the inability to use any form of permissions for following.

This is why I've been rather ambivalent about this feature...I think it's a good idea, but I'm concerned about the specifics of its implementation. Too broad, and it risks breaking content, too specific and it just gets too complicated.

What if we went back to the drawing board and implement something more similar to how the push issue was dealt with: Simply allow parcel owners (or estate owners) the ability to turn off llSensor() and related functions in a parcel. Now we're not looking at broken content, at least not beyond the extent to which parcel restrictions on llPushObject() break content, or parcel restrictions on scripts break content. It directly puts control into the hands of parcel/estate owners, and doesn't technically break the function as it becomes an all or nothing prospect.

Just as a parcel owner can turn off the llPushObject() function while allowing all other script functions to run, so can a parcel owner turn off llSensor() without turning off all scripts.

Would this be a better option?

Would this be a better option?'

Looking at it that way, yes..yes, that'd be a better option. Leave the issue purely in the hands of the land owners.

It'd definitely need the finer-grained group/others permission setting possibility like creation, scritpts and object entry have it tho, in my opinion.

Haravikk, what do you think about that simple solution? It'd definitely be the fairest for all parties involved, and solve the issue quite well.

Sure. Any land that has anything collaborative going on, really.

A simple case:

Land owner has land deeded to group X, and has invited several friends to that group, so they can build, hang out etc.
Now, one could say 'give your friends the ability to deed objects, problem solved!', but remember, lots of sensors also reside inside HUDs, which simply can't be deeded.

Hence the land owner would:

• Enable sensors for the Group
• Leave it disabled for Others.

I hope I didn't misunderstand the question.

EDIT:

Also, definitely a parcel setting, not just an estate setting. And the public sandboxes (as those were one of the main problem areas described), should have their safezones set nosensor for everybody, if this gets done.

It needs to work like this:

• No person without permissions inside a nosensor parcel can run sensors
• No person inside the nosensor parcel can be scanned by a person without permissions, even if the scanner/scanning person is outside the parcel

NOT just

• No person without permissions inside a nosensor parcel can run sensors

Else the parcel setting is easily circumvented by a person dropping a sensor outside the parcel, and letting the followers, annoying objects or whatever get their data from it.

Chalice already answered part of this by offering that it could be set like object entry or scripts or object creation, either for everyone or for group members only. Additionally, on group-owned land, a land owner could turn off sensors for everyone, group included, but add a role within the group that would have the ability to use sensors, just like giving any other ability to a role.

For the reverse situation, where a land owner wishes to allow sensor use for everyone, and others would prefer to be invisible, I think that the land owner's preference should be respected. We can't please everyone, but I think I'd err on the side of land owners there. Keep in mind that he can still give individuals the power to return objects and to eject and ban troublemakers.

******************************************************
"
It needs to work like this:

• No person without permissions inside a nosensor parcel can run sensors
• No person inside the nosensor parcel can be scanned by a person without permissions, even if the scanner/scanning person is outside the parcel

NOT just

• No person without permissions inside a nosensor parcel can run sensors "
  ********************************************************8

This makes sense, and I think I can actually state it in a more simplified manner:

On a sensor-restricted parcel, an llSensor() function will return a no_sensor() event automatically. An llSensor() call will also not return data on avatars who are in a sensor-restricted parcel.

Note that this means that standing on a sensor_restricted parcel prevents someone from scanning you, while also preventing you from using sensors to grief others, neatly preventing abuse issues.

Making it an avatar feature is really just creating officially supported phased chairs, with most of the same issues that those caused. It also amounts to allowing one individual to alter the effects of another individual's script: if I am in private mode, I am altering how your sensor script reports information, causing it to report information different from what the function normally should. The only way a privacy mode differs is that it would be officially supported and some people could turn it off, but it would still amount to another phased chair with all the similar concerns and problems.

On the other hand, by allowing a parcel owner to restrict the llSensor() and related functions....well, it also technically "breaks" scripts, but is no different from how restricting push or turning off scripts altogether "break" scripts. And it puts the sole decision into the hands of the land owner, rather than individual users. Finally, it provides safety to everyone, not just those who chose to enter a private mode while at the same time preventing people who are immune to sensors from running sensors themselves.

I think making it solely a parcel setting affects the root problem of llSensor() being abused without bringing in a lot of tangential issues, and it does so using established methods rather than granting users a new ability to decide how someone else's script should react to them.

second, i'd like to mention that this will break -alot- of content, and this can not be brushed aside easily. Assuming LL is ok with breaking all the content, with no warning (this jira is not warning, i mean like a blog post with notification time so content creators can make changes/updates to their products).

3rd, my only real interest in this thread is to make sure we don't break combat sandboxes I help administer, in the sense that people would be able to hide themselves from llsensor (and others) against the will of the land owner. and i'm not talking about hide from sensors the land owner has, against anyone's sensors.

lastly, I think the description (of this jira) needs cleaning up/simplifying.

1) A per-avatar privacy mode, that can be turned on or off.

2) A land privacy setting, that will allow avatars on that land from not being scanned by sensors, UNLESS those sensors are on that same land and have scanning rights.

I also think that:

1) Both conditions must be met for an avatar to be rendered invisible from sensors

2) Default settings on both the avatar and the land should be to allow scanning.

The reason for linking this to a privacy mode is that I think that an avatar should still be able to be visible to sensors if he wants to, regardless of the land that avatar is on. Land set to "allow invisibility" would give an avatar the OPTION of turning on invisibility, not make him invisible by default. On the other hand, land set to "disallow invisibility" should override any privacy setting on the avatar.

Note that I'm still against any inhibiting of sensors, and that Drew has a very good point:
There will be lots of content breaking, and you can expect opposition from content creators.

I think you should only be able to go invisible on your own land. Anywhere else is an unreasonable expectation of privacy in a social environment.

@Haravikk: llsensor, for the purposes of this issue, includes llgetobjectdetails. As for dataserver events like online checking, I have no problem with being able to hide that together with your online status in your profile.

PS: my apologies to ppl "watching" this issue; I tend to edit my comments a lot

On the other hand, disabling the sensor functions purely as a parcel setting would avoid the need to create this new concept of visibility, would prevent scripters from needing to update their sensor scripts, and would permit sensor calls to function exactly the same as they do now, except on land where the sensor functions have been turned off. Just as turning off scripts on a parcel, or restricting push on a parcel, doesn't really break content, neither would restricting sensor functions on a parcel break content.

Making it purely a parcel setting is also much simpler, both in terms of coding, but also for the user: As long as you are on sensor-restricted land, you cannot be scanned. Follower objects will not work (and neither will many other griefing attacks that rely on sensors). If you are on land that is not sensor-restricted, you know that you can be scanned by scripts containing sensor functions, just as you know that if you are on land that is not push restricted, you could be pushed by scripted objects, or being on damage-enabled land means you could be killed. This also has the advantage that while you cannot scan other avatars on that land, they cannot scan you either (unless they are the owner or part of the ownership group).

There would even be a major advantage in this for the owners of shops and clubs: They could disable a single function that is required for many griefing tools to work, while still allowing scripts to function, rather than having to turn off scripts entirely.

Bear in mind that the main goal here is to make it so that a user cannot be scanned by other people's objects. The easiest and simplest way to do that is to allow a land owner to turn off the ability for objects to do that on his/her land.

I just thought of this little problem:

What if I'm on someone's land that has "nosensor" on, and I'm using one of MY items (say a follower) ?
My own items should ALWAYS be able to detect me, regardless of what parcel they, and I, are on.
For that matter, any sensor set/deeded to group should be able to detect avatars who have that same group active, regardless of landsettings.

HOWEVER: having no group set on both avatar and item DOES count has having the same group set, so that should have an additional exception.

Additionally, if I'm on nosensor land, I do want my sensors to pick up avatars that are on other parcels (which dont restrict sensors).

Only area scanners that really need to detect anything within their area are security orbs which are covered by the "same owner" rule for land, and combat areas, which are covered by the ability to turn on/off the ability to hide from sensors and other scripting calls* while on that parcel. If you want to make the change as seemless as possible then you can do so by making privacy support for parcels on by default, with it off on combat enabled plots of land. A few people who use special combat systems will need to do some tweaking, but it's otherwise all good I think.

*I hasten to re-iterate here that llSensor() is NOT the only way to detect someone using a script. Once you have someone's key then llGetObjectDetails() is just as effective (actually moreso for following a single person).

I think I'd liken this feature to anonymous proxy servers. You can use these to hide yourself from places that try to track information about you that you're not willing to give, but if you want to access a site that doesn't allow anonymous proxies, then you have to connect as normal. Same thing applies here really, sensors still get harvest information about people who are willing to let them, while people who aren't can hide, except where they aren't allowed to, or where an item gets special treatment (land-owner).

PS: FYI:
I would also like to point you to the alternate client list, where you can already dl a client that gets avatar info straight from the server; that way you can see the tech in action for yourself.
https://wiki.secondlife.com/wiki/Alternate_viewers
Check out the Able Edition there, or go to http://sl.daleglass.net/

I still see this to be a major problem if you are able to hide from objects with damage enabled. It means hundreds of scripted kill objects will fail to work. Even regular guns have bullets that rez the damage part on top of the avatar after impacting the shield. The people who make these shield breaker bullets will loose their market.

It is also a problem in roll play combat regions if one player's HUD is unable to see another player, because the other player is cheating by using privacy mode.

If this is to be implemented it needs to be enabled / disabled at the parcel level like flying. You should have control over it to preserve the integrity of scripted behaviour over your land. To preserve default behaviour land should be set for privacy disabled by default. Otherwise many people will not understand why some people cant be seen on their land, resulting in creators being flooded with support IMs.

Linden builder sandboxes should all permitt privacy, however linden combat sandboxes should not.
Linden protected land should also have this feature OFF as I have seen many groups of people use large open spaces like Bohol, Celebes, & Sargasso to play HUD based combat games. As I am sure they do in many other open public spaces to avoid the over regulation of privatly owned simulated combat areas.

Lessons from History
=================
A long time ago you could use the command llSetDamage(-100) to instantly heal yourself. It was removed because it was considered cheating. I have not voted for this issue because I have similar worries about negative side effects.

A non-combat related issue is vending machines.
=======================================

I already have a lot of trouble with people muting me by mistake when they mean to accept inventory being given to them by a vending machine as part of a sale. Then the enevatable complain about not getting the object which I can't give them while they have me muted. http://jira.secondlife.com/browse/VWR-4185

Imagen if the customer was in privacy mode while operating the vending machines. Some machines give rewards to sales people, commisions, gifts etc.

Not all vending machines are owned by the land owner because of the money exploit that lets affiliates steal money and products from creators. (Hidden JIRA issue)

The end result is that a customer in privacy mode can not be guarentted a happy shopping experience.

Darling.

The modified client issue is rather complex, as presumably one would be able to use it to return information on an avatar regardless of which method was chosen to implement these changes. Fortunately, there isn't an obvious method for passing it on to scripts, so it shouldn't create huge problems.

However, the modified clients are a major reason for advocating parcel-only settings (ie allow everyone to use sensors, allow group members, or allow owner only) rather than the two-flag (parcel and avatar) system. If we introduce this new privacy mode, it creates the possibility of someone creating a modified client that will trick the server into reporting it as being in privacy mode regardless of the parcel flags.

Note that this would not be possible in a parcel-only scheme, because the parcel itself is disallowing the llSensor,llSensorRepeat, and llGetObjectDetails functions in the individual scripts to run. A parcel-only setting would address the problem at the server itself rather than incorporating an added client variable. And of course, don't forget that the clients are open-source now, so adding any extra privacy settings at the client level will immediately become known to everyone.

Making it a parcel-only setting seems to me simpler and less prone to abuse. It would be easier to implement and would strike at the root cause (the sensor family of functions in the script itself) rather at a later outcome of the use of these functions. Finally, it has the advantage of being similar to the methods by which Linden Labs handled previous problems with script functions such as push.

Finally, let me just remind everyone that every time that information passes between client and server, it adds to lag. A two-flag system with privacy mode would mean that every time one of the sensor functions was run (and they can cause plenty of lag in and of themselves), the server would then have to query each client to see if they were in privacy mode or not. Think about what even one or two people wearing radars with llSensorRepeats set to low values would do to sim performance in this situation (on top of what they already do to sim performance, of course).

And note that this problem would occur regardless of the number of people who were in privacy mode, because the server still has to query the clients regardless (obviously it doesn't know whether they're in privacy mode until it asks). The alternative would be a situation in which the sim and clients are constantly communicating this information back and forth, which could cause even more problems.

As I said, a parcel-only setting would be far more efficient.

So it can go something like:

• Does parcel allow privacy?
• - If yes then is avatar currently in privacy mode?
• - - If yes then do not add avatar to results.

All other cases will add the avatar to the results (ignoring Linden accounts).

This can be improved further by having two flags/values:

• The first flag (A) describes whether the avatar has enabled privacy mode or not
• The second flag (B) indicates whether the avatar is currently in privacy mode or not

Thus, if an avatar enables privacy mode, flag A is set to true. The simulator then takes a look at the parcel they are on, if it does not allow privacy mode then flag B remains set to false, otherwise flag B will be true.
If the avatar moves onto another parcel, then the parcel is checked for privacy settings. If privacy mode is allowed, and flag A is true, then flag B will be true (avatar is hidden), if it is not allowed, then flag B will be false (avatar is visible whether they want to be or not).

This simplifies things to a case of:

Is flag B true?

• If yes then do not add avatar to the results

This is the more efficient way of doing it, as parcel border checks are a lot less frequent than sensors in many cases (since avatars typically stay put for the most part, only moving around occasionally). And allows quite happily for the greater freedom of a per-user setting.

Secondly, as darling mentioned, we need parcel controls to allow or prevent the use of this ability. To prevent cheating in RP sims, and such. This needs to be a REAL restriction, not just a clientside thing like the no flight. I need sensors for tracking visitors to my store.

and obviously, this should be allowed in linden owned public areas. Always working for the landowner is good too, and definitely needed.

A per avatar setting, but only if the parcel allows it.

Ok, as you describe it, it would make some sense. As long as the settings themselves are server-side (even if the option is selected in the client), then I think it could work.

The only other real difference I can come up with between parcel-only sensor restriction on the one hand or your per-parcel/per-avatar flags would be in sandboxes, where griefers might still simply target whoever isn't in privacy mode,

This is sort of like the old joke about two campers who hear a bear outside their tent, the first camper starts lacing up his shoes:

Camper 2: "What are you doing, you can't outrun the bear."
Camper 1: "I don't have to outrun the bear, I just have to outrun you."

What I mean by this is that what would really be happening is the same thing that happened before with phased chairs, griefers might simply go after those who are too new or naive to be in privacy mode. A simple per-parcel sensor restriction, on the other hand, would prevent sensors from working anywhere on the parcel at all, thus obviating the need for individual users to enter this mode.

That being said, the per-parcel/per-avatar flags would work well too. Just trying to make sure we don't overlook anything before implementing something like this.

The campers and bear story is not ralavant. Camper 1 need only tell camper 2 to put on their shoes too ,and the bear goes hungry.

@all

I am more concirned with having it forced onto me when it is not convenient. Or having people able to use it to bypass existing content that works. Such as parcel security devices that cant detect them if the neighbouring parcel is protecting them with privacy.

A parcel must be able to disable privacy mode for all visitors like the "no flying" flag, but it needs to be enforced server side!

I also think that public linden land (open space / protected land) should not permit privacy mode. The reason is that it sits next to regular parcels owned by people who can be griefed by anyone standing on the protected linden land and be unable to even detect the owner of the object colliding with them. The only linden land this should be on by default is the non-combat sandboxs. And lets face it, turning off scripts at those sandboxes would end griefing right now.

Darling.

Linden sandboxes are the main reason for implementing this mode, as I understand it. Turning off scripts entirely in those areas would probably cause more problems than it would solve, as many people build items there that also use scripts.

Still those are good examples of why a per-parcel sensor restriction might be better. Then a person who is unable to be detected would also be unable to use the sensor functions as well. This would also apply to the situation where one is being griefed from another parcel, as restricting sensors on one's own parcel would also work to stop such an attack (although obviously enabling privacy mode and then entering it would do the same, although it would require more steps).

The camper story is relevant here because neither camper can really outrun the bear, if they try to run, he will catch and eat them. Camper 1's idea is that all he has to do is outrun camper 2, and the bear will grab and eat camper 2 while camper 1 continues to run away. Similarly, griefers would probably find a way around privacy mode (just as the bear could outrun both campers), but this would wind up providing protection for those in privacy mode (camper 1) because the griefers would likely just go after anyone not in privacy mode (camper 2).

This is why I'd rather have a per-parcel setting that simply restricts sensors altogether, analogous to just shooting the damned bear, rather than giving people the option of putting on shoes and seeing who can outrun the others to avoid being eaten.

In regards to the "invisibility" factor, as Lex said, if one doesn't want to be seen or detected, then he shouldn't go in the area at the first place. I don't think one can ask for complete privacy in a public area. Such basis has no social logic in my view, other than perhaps compensate for the lack of policy enforcement by LL for its public areas... I don't really question the right of Lindens to use such privilege of not being detected by sensors and objects if they are in fact using it, but even LL's privilege could be regarded as a matter of privacy breach to residents from an ethical standpoint. In my view personal sensors are part of the inworld experience and one should be able to be invisible as such especially on public and commercial lands.

The privacy function as described above could also be abused for the purpose of spying on people while offsetting avatars from their positions... making them undetectable and nearly invisible to other non-owners, which in Soft's own arguments "would make the place positively creepy". You are basically reversing SVC-125 more than anything else. On top of this, griefers could in fact be given the possibility to act from remote parcels, and conduct their abuse to other people's land while going completely undetected if the owner's scripts are not able to detect people and objects on someone elses' land, which would be required if you want complete privacy from neighbors.

So the sensor invisibility part of is out of the question as far I am concerned. I think muting and busy mode is enough of a privacy level. If you want more privacy, I think it would make more sense to have privacy from sensors on your own land rather than on others actually.

However, the issue being contemplated here is not really a "Privacy" one but rather more of a "Security" matter.

The basis behind most proposals in the Anti-Griefer arena is more or less to have the ability to run essential scripts on most lands while having some sort of filter against those used for abuse. Clearly scripting ON or OFF are two drastic options to choose from and there needs to be a middle ground between the two. And obviously "No Push" alone is not enough either to prevent all sort of cage-guns shooting abuse.

I initially made a proposal to restrict some lsl functionality as protection tools for land owners against abuse on their land which was criticized for the hampering factors... But now it seems like hampering the results of scripts function on a per user basis is being contemplated here by Soft to my surprise... So if we are going to allow that principle, I would therefore make the case that the SVC-869 type of solution (as an owner/group land option) is far more attractive than a per-user setting and going further in protecting the general public from third party nuisance and disruptions.

The SVC-869 function could act as a global firewall with some of the additional script restrictions mentioned here, as deemed necessary after weighing impairment of functions vs. the abuse risks posed.

Also I thinks is it misleading to presume that by preventing "ALL functions that can process an avatar's key" will prevent griefing. In fact I would see the avatar being in invisible mode as the perfect target for abuse using a third party "name to key" database if I were a griefer. The functions that really needs to be considered are the ones making it possible to act upon an avatar with the key already considered available.

In SVC-869, I initially proposed restrictions on llGiveInventory, llGiveInventoryList, llRequestPermissions() and other selling restrictions which I grouped as spam and scam related in one parcel flag. Adding LlInstantMessage, llGetObjectDetails and llDetectedPos restrictions as supplemental protections in a global "Security Firewall" parcel options would the way to go in my opinion.

This entire function is totaly pointless!

I just watched someone demonstrate using one of those hacked clients from LibSL to detect the location of anyone who is logged into SL.

Not only that, they were able to map me and my friend anywere we went in SL and alter the parcel ban list for the parcels we were standing on! It didnt matter that the person remotly harassing us didnt own the land, they could still ban us!

Forget about the sandbox griefer using scripted obejcts. It's a joke complaired to what they are brewing up with LibsSL hacks.

With a little more programming the LibSL hack demonstrated to me could automaticly MAP, and BAN anyone continuesly all over second life. The victim will see nothing but constant "you have been banned" messages as they get banned from every parcel they set foot on.

Darling.

These are both major concerns, but we have to assume that these will be fixed as soon as the problem itself is known, are there JIRA issues for these problems? As they're pretty serious.

Serverside: Accepts many incoming requests/messages without any second checks.
Clientside: Opensourced Client/LibSL: Create requests/messages freely

'nuf said.

The opensourcing of the client was more than just a little rushed.

What if my friend has appeared invisible because a griefer has a follower on him, but i want to teleport to my friend using a scripted object that uses llGetObjectDetails to get the position of my friend?

Are cage guns really that much of a problem? Sit to escape and then AR the culprit.

<jest>Lindens have such a God mode that prevents them appearing on scanners and it's hugely disconcerting to be working and have a stranger appear and start talking unwarned by radars. My poor heart can't take the surprise.</jest>

As for your HUD radar, the content creators can easily build on the new system by serving their huds with a sort of simprobe container. Drop it, group-own it, and then just trigger the HUD's simscan. Probes buzz around, and the HUD gets fed. Or heck, one of those fancy radar stations.

No, the issue are malicious objects aquiring your coordinates through sensors, or even better, llGetObjectDetails, simwide. Following screaming boxes, traps that orbit on click, repeating deformers/animators, invisible click-map-spammers, harrassing tags...

And most of that stuff you don't want to sit on. Or click at all ;P

Chalice's comment summarized several of the sensor-based griefing objects in SL, which have caused a lot of problems for many individuals. The comment on the map spammer specifically made me think of the time my animator got hit with one of those, and coudn't get it to stop for an hour and a half even with repeated relogs (this was right after finishing several hours of work on a new release, so we were quite upset). Looking back on it, I doubt that she would have had this privacy mode turned on at the time, and in any case I know for a fact that the location where it happened would have turned it off. Even adding this privacy mode would likely not stop many griefing incidents if people aren't using it, whereas if everyone is using it then many legitimate functions like notecard-givers and visitor trackers might not work.

On the other hand, I have yet to hear of any legitimate use for such objects in Second Life. I understand allowing an object to open a person's map to a specific location once when clicked, it's a great function, but I don't see why it can't be limited to once per click. For some of the other screaming boxes and assorted followers whose sole purpose is harassment, those are clearly designed with the intent to violate the Terms of Service of Second Life that all users have agreed to follow. There is no reason why Linden Labs cannot simply UUID ban objects whose sole purpose is to cause grief. It is certainly easier to do so than to try to ban people who are using "throwaway" no-payment one-day-old accounts, and certainly would have less impact upon legitimate content than enabling a "privacy mode" or otherwise nerfing sensors.

After all, the idea of having people "opt-out" of being griefed is rather silly, when you stop to think about it. Nobody should feel that they have to pre-emptively enable some special mode to avoid being harassed by others. If we work on dealing with the source of the problem, then we won't have to worry about whether to have a "privacy mode."

There are a few reason why this does not work well:

1. In the case of griefer groups, they moved on to making those objects on the fly from copy/paste scripts. They can't be UUID banned.

2. In the case of more legit combat HUDs, the griefing lies at the fault of the user, not the creator.

UUID/asset blacklisting gets done when an object that's potentially harmful to sims or the grid gets into the hand of the normal public. Anywhere else it's pretty futile.

And of course, this completely skirts the fact that for those griefing devices that rely on rezzing an invisible prim around the victim, relying on him/her to unwittingly click it, the privacy mode function would be completely useless, since one would not realize the need to enable privacy mode until after being attacked and forced to relog....which with map spammers could be a half hour later.

As for organized griefer groups, I suppose they might just copy/paste scripts on the fly, but other than the five basement-dwelling teenagers who comprise the PN, I realy don't see much of an organized griefer movement in SL. Regardjess. removing existing griefing tools would at least stop the script kiddies and assorted wannabe "security" vigilantes.

One other possibility...in another JIRA Ticket, Andrew Linden mentioned wanting to have an office hours session to discuss griefing methods and what could be done to basically make them not work. That might be a better place to start, to go through the methods that people want to stop with this function, and look at ways to specifically prevent those griefing tools from working, without damaging legitimate content that might utilize the same functions.

So for instance with map spammers, that would be the easiest, since the legitimate use of the llMapDestination() function doesn't need to be called more than once per touch_start() event. That change alone would remove one such problem without destroying legitimate content such as cross-sim teleporters.

I had also placed a JIRA ticket a while back suggesting simply limiting the left-click-sit property to objects owned by that avatar. So if you rez a car, you could still left-click and automatically sit in it, because you own it. But your passenger would still have to right-click and select sit. It wouldn't break anything, at most it would mean that some objects would require you to right-click instead of left-click, but their functionality would be retained, but it would prevent much of the invisible follower items from working, since you would have to intentionally choose to sit on an object not owned by you. Unfortunately, the ticket was closed after Linden Labs decided that it would cause too many problems with existing content, but at least they went halfway with the new RC 1.20 and made it so you can't left-click-sit if you're already sitting.

I had a harmless object banned recently because I made it copy mod trans years ago and someone installed scripts in it to crash regions. When LL banned the griefer version of my prim water, all the harmless prim water got banned and deleted from in world too!

My HUD is very versitile. I used it to control many products. If the original root for the HUD was banned it would delete people's animation controls, terraformers, roll play gadgets, etc etc.

The true griefer groups have websides complete with scripts that build the objects automaticly for you. They can have their region crashing weapons up and running within 10 minutes of loggin in with an alt. Not only that, their scripts dont use any exploits at all, ensuring they can never be disabled by a JIRA fix. That is why object banning and JIRA ranting has failed to get rid of the really nasty stuff.

You need to remember that calling the map more than once can be very usefull. eg: Your own combat region could use it to bring people back to the start position if they take off their HUD. Which is a lot less greifer-like than your current system of caging someone against thier wishes.

I have a tour system using the mapper too. Someone clicks an object to begin the tour. They are sent to destination 1. when they reach destination 1's teleport station they need only walk into the teleport chamber and a map for destiantion 2 is given. If you dont understand, look up orenteering. Yet another use is my tardis which needs to be able to teleport you in and out of the interior when you walk though a door at any time, not when you click something.

Your suggestion about left-click to sit is once again short sighted. What about teleporters that are click to sit? Do you ever think about other people's content before you start suggesting ways to break things you dont like? Honestly, try sitting and thinking about stuff before posting to the JIRA, rather than treating the JIRA like a forum debate with some kind of score board.

Darling.

You just described the functionality of a good chunk of modern 'combat' huds, ironically.

As for the comment about most griefers not using objects made on the fly..I think the only object I've seen that's been persistant, is the freebie cagegun/cagecane that every damn newbie gets at the freebie places. I can't count the times I've seen that black cylindric cage rez around people.

Any other griefer attacks like the screamers, sim-wide mass attacks etc I've seen so far, even if the UUID wasn't blacklisted for afew days or weeks, got replaced by new version or variants a mere day after blacklisting actually happened. Often enough I only see a specific attack used once, even, by nondescript griefers. UUID blacklisting is happening, it's working, but it won't get us further than we are right now.

With regards to the click-sitting issue: I did think about teleporters that are click to sit. Under my proposed ticket, they would not be altered one bit for their owner. For other users, their functionality would not be altered at all, they would merely have to right-click and select the "sit" option from the pie menu (and note that it can even be changed to say "TELEPORT" as is done with many systems). I do not think that having to right-click and then select an action is particularly more onerous than being able to left-click, especially given that it would only apply to objects owned by others. All that it does is create a situation in which one cannot unwittingly sit on an object owned by another individual, as one would have to knowingly choose to do so. This one minor change would eliminate a method by which many griefing tools operate, without altering the function of any legitimate content one bit.

As for the mapping functions, presumably there is some sort of second event that calls the next iteration of the llMapDestination() functions, yes? Obviously there must be some method used to make sure that they receive the second map at the right time, rather than being spammed by an unlimited amount. All that I am saying is that perhaps it should be limited to once per event, or perhaps some sort of throttle on how many times it can be called in a short time span. Or perhaps require a permission to be enabled to send a map more than once per click, thus one could click once and get a map without any problems, which is how the majority of instances work (ie "click here for this location"). For situations in which one would be receiving multiple maps, a blue dialog comes up saying "Tardis, an object owned by Darling Brody, would like permission to send you Map Destinations: Yes No". If necessary, I suppose permission could be automatic for the object's owner, which would again prevent a lot of problems.

I suppose I'm just a bit confused here. First there's a JIRA ticket demanding the return of sit-offset "phased" vehicles, claiming that they're urgently needed to avoid griefing attacks. Then there's this ticket, asking for an official, supported privacy mode, which is again mentioned as being necessary to avoid griefing attacks. In both tickets, the sorts of griefing attacks used are mentioned.

So when I suggest that perhaps we do something to stop these griefing attacks....I'm told that these attacks are only "bad" if "bad people" use them, and that I'm supposedly trying to destroy content.

(I also completely fail to see how map spammers and forced relogs are legitimate functions under any circumstances. Given that they constitute a form of Denial of Service attack, they may in fact be illegal under US Law).

I'm not saying that a privacy mode, or a parcel-settings option to disable scripts, wouldn't be a bad idea, but it would be tricky to implement correctly, and it would take some time for it to be developed, tested, and implemented across the grid. And even if we were to do so, I'm not sure that it would really do much to stop griefing attacks anyways. On the other hand, the rollout of Havok4 and its limits on avatar speed has had a noticeable reduction in orbiting and other griefing attacks of that nature. My point is that disabling the griefing attacks themselves is probably a more effective method, and in the long run probably would be less likely to break content than adding in new features like privacy mode.

@Jahar Aabye

Your like a starving dog with a bone! The Click-Sit has been fixed in the RC viewer. Did you read it that time, or do I need to say it again?

There is no need for you to ever use the click-sit example again as a reason to break something usefull. 90% of the time a teleporter is NOT used by it's owner and a click-sit is the most convenient way for people to use teleporters. The simple fact is that people are used to using the left-click on their computer and the right-click-pie-menu is confusing. That is why the click-sit was added in the first place!

Your dislike of the click-sit weapon is irralavant to the millions of people who use click-sit teleporters every day. Do you want all these people to be inconvenienced because you think an obscure weapon type they will probably never see in-world is reason enough to take away the simplicity of being able to click a sign and be teleported to the location?

You are incorrect about the mapping function. There is no second event. You need to get yourself one of my Stargate DHD's and see how you can walk though the stargate and be given the MAP page without ever having touched the stargate!

Your suggestions about adding a permission will not work because you cant go adding something that will break existing content. You can not expect every creator who ever used the map command to rebuild his products and then send them out to all their past customers. This is the main reason breaking content it bad, because it swamps creators in complaints about broken items and can drive them out of the market and out of SL. Remember, without creators SL is just a bunch of people standing around talking.

Adding a throttle is a possibility, however it will only result in objects being scripted to operate below the throttle's limit. Of course a low limit will break content again when you have a busy location with lots of people using a map teleporter.

Your confusion about why people dont like your suggestions to break so-called griefer weapons is the result of your single minded thought patterns. You see one problem and set out to solve it without looking at the big picture. I have scripted just about every type of object there is in SL (except for sex toys), so I feel I have a firm understnading of how a change will impact on different products. Your problem comes from your limited experience scripting mostly weapons. You think like a gun scripter, and that is fine so long as you dont push your opinion about changing a product you have never made onto the people who do make the product. When you tell someone how to make their own product, they become upset with you. When you suggest changes that will break their products and cause a customer backlash, they get VERY upset with you. Most products do not have a customer database or an automated upgrade system. So breaking something the way you often suggest can be enough to destroy someone's business. (as I mentioned above)

This JIRA is about privacy, when, and if you should be able to avoid the sensors of another person. And how that might impact on all products. I gave it a NO vote in it's current form because it will block far to many usefulland legacy products. The land security orb that started all this could be broken if the land owner sets their parcel incorrectly, resulting in lots of customer support requests. People will loose the ability to log what is going on around them. And most importantly it will give the dreaded griefer the ability to hide from unsuspecting victims with no way to locate who or where the person is who caused the trouble. While the victims will have to live with reduced function of their items when they go into privacy mode.

I would support a privacy function, but not in the suggested format as it would break too much content. Even the basic HUGGER would fail. Your friend would have to come out of privacy mode to hug you, at which point they turn up on the dreaded griefers radar and get zaped!

Darling Brody

It really was just so inconvenient to have to right-click one something, I mean, I hadn't even realized that there was another mouse button there on the other side of the mousewheel. Now I will never be able to sit on anything again in SL, for fear that I might have to right-click if I want to sit on something else, and hurt my wrist even more.

Seriously, though, between this comment and your comment in SVC-2153, you really need to cut it with the personal attacks. It's getting old and it makes you look petty. I'm not even going to respond to your comment, much as I would like to, because correcting you isn't worth letting JIRA get bogged down with more vitriol and pointless personal arguments. If you had even bothered to read what I'd said here, you would have noticed that I had some reservations about this proposal, and had been discussing other methods for implementing the goals outlined here.

It's a free world in SL and in RL. SL is about freedom from constraints that are imposed by the real world. If the real world allows stealth technology, why not in SL?

Besides, SL is a game, isn't it? As such, using radar and stealth are just part of the cat-and-mouse game to see who can outsmart the other. To say that your radar is absolute, and leave nothing undetectable is like saying that you are the cop, and you and only you can use the radar, and anyone using a radar detector or stealth to defeat the cop's radar as a countermeasure is a crime. Isn't that an one-sided view?

Let freedom rein...

I think that the problem is that you are looking at the end-products, radars and such, rather than the functions behind them. The actual functions, llSensor() and llSensorRepeat(), are defined by Linden Labs own documentation as returning certain information on any avatars (if AGENT is the specified type) that are within the scan range. llGetObjectDetails() will return information on the UUID specified if within the current region.

So to that extent, it's not about "rights" but about how these functions are designed and documented by Linden Labs. There is nothing in the official LSL Guide regarding any situation in which an avatar would not be detected by these functions in these situations. Because of this, individuals scripted objects in good-faith understanding that this is how they would operate, so any implementation of a privacy mode has to deal with concerns from these creators that it could potentially break their content. I'm not saying that this is a complete impediment to implementing this, just explaining why it's a lot more complicated than a "rights" issue.

However, on the subject of "rights", one of the core "rights" in SL is the right of land owners to have control over their land. This makes the question of implementing this feature difficult as well, because in addition to saying that land owners must be able to choose whether to allow this mode on their land, there is also the issue that sensors owned by the land owner or land ownership group ought to still be able to detect individuals who are in privacy mode. This gets more complicated in situations in which a region might be split into multiple parcels with different owners, with the question of what happens when an avatar in one region that has privacy mode enabled does something to harass the owner of an adjacent parcel.

All of this is mentioned above, of course, but I mention it again to highlight that the issue here is not really about "rights" or "privacy" but about much more complex issues such as land owner rights.

Finally, there is no right to use "stealth" in Second Life. This was covered in SVC-1475, where it was pointed out by Soft Linden that that ticket was misnamed because avatars had never possessed a right to avoid being detected by sensor functions. Now, that being said, it is the specific concern that individuals are using these functions to harass other users in violation of the ToS and CS that is prompting this ticket, which actually seeks to create new avatar abilities...or "rights" if you want to think of it that way. It is better to focus specifically on those documented issues rather than appealing to an undefined and non-specific "right".

(oh, and believe it or not, at least one state in the USA does ban radar detectors, and their possession and use in a car is illegal:
http://en.wikipedia.org/wiki/Radar_detector )

To give Linden due credits, Linden does allow PRIVACY MODE to let users to "HIDE" their online status from stalkers. That is being STEALTH to unwanted things happen to you. Now, of course, there are plenty of ways to get around to find out your online status, but at least Linden does ALLOW someone to be "stealth" and "hide" it from you if I don't want to be seen (theoretically but not practically). But at least Linden GAVE US that option. So there is precedence that Linden do take privacy issue seriously. So allowing an avatar not to be detected by llSensor() is not any different.

It's also a DEFENSE issue vs. OFFENSE issue. It's not much different from saying using weapons are allowed, but shields are not! Privacy mode is allowing someone to be shielded from llSensor() attacks. What kind of game is it if shield is not allowed? Of course, I know there are plenty of places in the world that banned radar detectors, that's precisely my point, we come to SL to get away from RL constraints and be free.

Lastly, to give you are real situation where this applies so many times in SL, not just in those pesky follower bots situation, but also in stalking. My neighbor has stalked me by installing in the infamous PDS device and set it at attack mode and broadcast attack messages via llDialog() repeatedly every 5 sec when I come home, or when my customers visit my shop, and flood it with spam warnings and said that I have been ejected from my own land even though it did not because I am not over his land. This effectively drives out all my customers, drive out my business because he has more rights to his business over my rights to exist.

The argument that stealth has no rights to exist in SL is equivalent to say that PDS has no rights to exist. Linden already allows parcel owner to ban people and eject people from their own land, why do they allow PDS to duplicate what Linden already has provided? Besides PDS is effectively a griefing device, period. They should be banned.

Of course, this is ToS issue and abuse of my neighbor, but will Linden do anything about it? Yes, they will, but it will take them a 100 years. I understand that there are other 50,000 users online simultaneously, and they don't have resources to deal with them all.

That is precisely the point. If Linden allows me to set avatars within my own parcel in privacy mode, then Linden will not need to spend one minute of their time dealing with abuse reports of these griefers, and spend more time on some productive things to make this place more enjoyable and fun. The pesky neighbor stalkers and those pesky follower bots will become a moot point. End of story.

Remember those days when you can map anyone anytime anywhere in SL? How come Linden disabled mapping an avatar without your consent? Because it's a privacy issue and stalking problems. No one was complaining then when Linden disabled that, except for the stalkers.

Why is the use of llSensor() to map someone any different? Why are people complaining when I don't want to be mapped by llSensor() without my consent? What's the difference? In this case, it's even worse, because you can script it to stalk someone automatically which is much peskier than mapping someone using the Map, which requires a real person to do the clicking on the map.

Phantom object is another example of allowing stealth to collision. Just because you can push and collide, it doesn't mean all objects are collideabe or pushable. Phantom objects are stealth and invisble to colliders. Doesn't Linden provide this option in-world? Why are people not complaining there are stealth objects around?

By the same token, just because you can scan with llSensor(), it doesn't mean all avatars are identifable without their consent, in just the same way as just because you have a map, it doesn't mean you can map any avatar you want.

Why are there transparent objects? Aren't they invisible and stealth? Why aren't people complaining that you can see them?

The list is almost endless:

Why does Linden allow landowners to turn off script? Just because you can create scripts, it doesn't mean you can execute the script anywhere you want without the consent of the owner. Why people don't complain about that too because it "breaks their content", right? It never says in the documentation that you can execute any script you want.

Why does Linden allow landowners to turn off create? Just because you can create objects, it doesn't mean you can create anywhere you want. There are limits.

llSensor() is a privilege. It is not a right. Privilege has limits and boundaries.

I may even go as far as turning off llSensor() function entirely in the owner's land, because this would eliminate the abuse of copy bots that scan the entire parcel for things to steal.

*******************************************************************************************

Actually yes, the definition of llSensor() is that it will return information on all (up to 16) avatars (if AGENT is the type specified) within the scan radius. This is the expected outcome of the function as documented by Linden Labs. Now, I understand that you may not like this outcome, but you cannot simply ignore the fact that it is the expected outcome of the function. What is being asked here is to change that, but it is important not to put the cart before the horse. That is what I am trying to tell you.

****************************************************************************
"Why does Linden allow landowners to turn off script? Just because you can create scripts, it doesn't mean you can execute the script anywhere you want without the consent of the owner. Why people don't complain about that too because it "breaks their content", right? It never says in the documentation that you can execute any script you want."
******************************************************************************

Yes, this is why I suggested that this be implemented simply by allowing a land owner to turn off the three sensor functions (llSensor(),llSensorRepeat(), and llGetObjectDetails()) on their land.

However, llSensor() is not a priveledge. It is incorrect to state this and it is incorrect to state that it has limits and boundaries beyond those documented by Linden Labs. I understand that you want there to be boundaries. What I am saying is that these boundaries do not yet exist, and I do not think that it is helpful to pretend that they do. I do not think that this helps us determine the best method for implementing restrictions on the use of sensors.

Also, and let me make sure that this is clear, none of the sensor functions work outside of the simulator where the object containing the script is located. This is a major difference between the old mapping issue and the current sensor issues. llSensor and llSensorRepeat are even limited to 96.0m, which is well within most people's draw distances. What I mean by this is that in general, someone can only scan you with a sensor if they can see you. It is also important to understand that the only information that the sensor scan is returning is your position and your key. Your key is generally public, and your position isn't a huge secret to someone who is within 96m. llGetObjectDetails() is a bit different, while it can work throughout an entire region, it is not a general sweep, but must be targeted towards an individual avatar.

I am saying this not to argue with you, but to try to clarify some of the issues here. While I think that this idea is generally a good one, I am worried about how it might be implemented, and I think that it will be tricky to make sure that it is implemented in a manner that accomplishes the main goals without breaking content and without allowing it to be used to hide griefing.

A major reason why this ticket was created was not out of concern for privacy...just about anything you do in SL can be seen by others. There really is very little "privacy" in SecondLife. This ticket was created specifically to prevent certain scripted objects from being able to use the sensor functions to follow avatars and harass people. It's not so much for avoiding being seen on radar (and wouldn't affect the client-side radar in the Dale Glass client), but for preventing an object from being able to follow you and harass you. It is important to look at what we want a "privacy mode" to do before we can look at how the "privacy mode" should be implemented. In my experience with public policy in Real Life, the biggest mistake that people make is trying to solve the wrong problem (in fact, I'd say at least 75% of public policy errors are of this nature). Rather than focusing on radars or "privacy", it is important to focus on the script functions and the griefing activities that need to be prevented.

All other agent related functions, including the ability to sense the presence of an agent (without specific location', may remain intact and functional as-is. Obviously, some way for parcel/sim owners to allow/disallow such functionality would be necessary in order to maintain the feasibility of combat/RPG areas.

I must also remind that the proffered solutions will NOT prevent the use of cage guns or similar tools, where directionally targeted objects using collision detection are used. Perhaps a "non-physical mode" anti-griefing approach is more rational overall.

If there is a rational, or need for additional "privacy" based functionality, it should be a separate issue. Clouding this issue by trying to tack on privacy related changes, will cause this issue to remain open longer, or be again closed without further resolution.

Finally, my (personal) position, is that none of these changes are necessary anyway. There will always be ways to grief, no matter how much is done to prevent it (and at what other cost to the system as a whole.) I will not get into the semantics of my opinion, since they are based on my perception of behavior and willingness in others.

Since those who would disagree with my position are unlikely to see any other way, I simply advise any of you with your hearts set on this matter, to seek a one step approach as the larger matter is far too overwhelming for a single discussion or path of resolution.

[quote from Niaht Nakamichi ]
The only resolution necessary to close this ticket as "fixed" for it original intended purpose is to allow a user to prevent scripts from obtaining a coordinate location of the agent when an avatar user activates said "anti-griefing" function..
[/quote]

so you are suggestion that llDetectedPos() will return ZERO_VECTOR but llDetectedKey() will return an avatar key? (ditto for the other llDetected functions)

That is really going to mess up existing content. If the scripts gets an agents key, it will assume the position is valid too, because that is how it has always been. That means scripts for things like land security devices that detect the agent key will get a location of 0,0,0. With the exception of the person who owns the land at 0,0,0 the script will incorrectly think the detected avatar is NOT over the area being protected, and take no action.

Changing how a function operates from the long established documentation is going to break content.

I do not agree with changing a function in such a way that will break content that has been correctly scripted within the documented behaviour of the function.

The simple fact is there are more non-griefer uses of llSensor than there are griefer uses. So why break 99% of objects just to stop the 1% you dont like?

If SL continues to cripple it's scripting language every time someone hystericaly yells griefer there will be no scripted contents at all. No creater will want to make a product that gets broken a month later, only to have angry customers demanding refunds.

Griefers will always be in secondlife, just like there will always be jerks in real life. We dont ban cars in real life because some jerk wants to drive home drunk for the bar, instead we try to catch the jerks and put them in jail. My advice is to Abuse Report the jerks, and don't breaking existing content.

Darling.

Also, Darling, the proposed changes, as noted, only restrict the behaviour of certain items, namely those that expect to be able to detect people over any plot of land. Security devices on owner's land will be fine since these need to be set-up as such anyway in order to use llEjectFromLand() and llTeleportAgentHome().

For other items like attachments that use sensors, privacy mode will apply. This is the main reason I opted for an agent-level feature as well as land-options to control it, as if you find you can't use emote-attachments (hug/kiss etc., these all use sensors) then you can simply disable privacy mode entirely, or for the individual you want to emote with.

Ultimately I think the proposed feature-set is still the one I favour; the land-owner has ultimate control, but the privacy mode is up to the individual, so if you find that it adversely effects something then you can switch it off temporarily. Or, preferably, you would be able to disable the effects of privacy mode for people on your friends list, though I'm unsure of the complexity of this case. This would then cover the bulk of use-cases for portable sensors, while preventing people from using them to detect you against your wishes, for potentially malicious reasons, such as automated griefing tools in sandboxes.

If it is tied to the land then it is no more or less effective than turning off scripts. Land owners already have the power to disable objects far more effectivly using that. There is also the problem of public land, if it is off by default it will break legitimate products that were scripted with the expectation of being able to detect people. I've seen a loverly script for use in a car that uses a tight sensor beam to detect people in the path of the car and put on the breaks before you run them down. Basicly It turns the car non-physcal to stop it! I have been pushing for all the cars to include it to avoid running over people in sandboxes. oh the irony!

If it is not tied to the land then you just let the griefers hide from all the handy huds out there that keep a log of who did what where and when. Not to mention the ability to have your hud warn you when someone you dont trust is in the area! (ie. hear alarm, sit down!)

I'm sorry I just dont see the value.

Now if someone wants to suggest shutting down and prosecuting a particulare website devoted to crashing, smashing, breaking, and griefing SL, i'll vote for that!

Darling.

And to mention again, that the proposed solution doesn't resolve objects using collision detection.. and.. just to be somewhat complete.. what about llVolumeDetect..

I also don't like the idea that someone could turn off their visibility, preventing me from being able to see that they are around. I prefer to be aware of my environment, and who else I'm sharing it with.

Any "privacy mode" that is implemented should prevent sensors from being able to detect an avatar's position and use that to harass them, but it should not prevent an individual's objects from being detected when they collide with something else.

But perhaps I need to ask more specifically which side of the collision question we're discussing, as there are actually two separare issues:

Should an object owned by an individual in "privacy mode" trigger collisions on other scripted objects (including avatar attachments) when it collides with them?

Should scripted objects trigger collision events when they collide with an individual who is in "privacy mode"?

The first question deserves an obvious "YES". Being in privacy mode should not enable one to have complete anonymity when they wish ti interact with their environment, and definitely should not provide an opportunity for anonymous griefing.

As for the second, it's hard to say.

Jahar Aabye has defined this functions aim, and it's flaw in a single statment.

Clearly we want to permit valid uses of sensors to avoid breaking content while blocking invalid uses as Jahar Aabye has suggested. BUT how do we know the difference between a valid and invalid use of llDetectedPos in the sensor event?

So far we have seen people attempting to define a "bad sensor" with suggestions based on Client Side privacy modes linked to Land Settings and a whole bunch of conditions that need to be applied to the long documented output of llSensor. For every suggestion there has been a counter complaint about something that could be broken.

The problem here is we are trying to GUESS what the scripted object MIGHT do with the sensor information based on somthing like the objects location, or our own personal experience with undesirable content. The trouble is there are some 14 million people using secondlife and we would be arrogant to think our experiences are wide enough to determine when and where people should be able to use sensors.

This JIRA issue has highlighted just how hard it is to distinguish the difference between good and bad uses of the sensor. This is because it is not the sensor that is bad, it's the rest of the script.

Darling

It is no different from the case in which llPushObject() was restricted thus "breaking" all items that use push to move things around. Now I can't go around grabbing or throwing anyone I please. I'll agree that push is a much more extreme case as it's potential for abuse is arguably greater in many respects, but with sensors it is possible to do similarly disruptive things in other, less easily restricted ways (e.g. - pushing someone with prims in a sandbox).

I don't know whether having a "privacy mode" is a good idea or not, quite frankly. However, I feel that if it were to be implemented, there are certain features that it should have, and certain features that it should not have, and that given the serious issues involved, such as the potential to break content and the potential that such a mode could be used to facilitating anonymous griefing, it is important that there be some very serious discussion of what specifically this proposed mode ought to do, what functions it ought to affect.

The one thing that I will say that I am dead-set against is any sort of fuzzy, ill-defined "privacy" concept that leads to a hasty, ill-conceived implementation. I want to make sure that everything that such a mode would do is clearly documented before its implementation is considered. I think that this concept does have some merit, and I'd rather participate in helping to shape it than simply oppose it. That being said, I might still decide to oppose this proposal depending on the exact implementation.

one thing I do think it needs is constraint. One possible constraint might be to limit it to land owned by Governor Linden, perhaps? This might take care of issues relating to public sandboxes, without impacting land owners. That way we avoid the issue of what happens if I turn the mode on in my land and my neighbor turns it off, or vice versa.

Yes? No?

The alternative that I would prefer, but cannot come up with a realistic proposal for, is a way to make yourself invisible to particular objects or object owners. So you could just right-click and choose "Block" or have it part of Mute or something and the object would become unable to detect you in that simulator (to prevent massive databases of stuff). But this has the same privacy/spying issues as this proposal here, as you could just "Block" a user who you want to spy-on. The idea being that this alternative is an empowerment of users to stop issues as they occur, rather than having the potential to break things before they even get a chance to detect you. But it's wrought with much the same problems, and doesn't combat the issue that objects in sandboxes can harass you and disrupt your work, while if you're in "privacy mode" you can at least know that NOTHING will disturb you.

It's a very tricky issue I agree.

Regarding adjacent land-ownership, I still don't see that we have any implicit right to detect people on someone else's land, only on our own. Yes it makes eaves-dropping easier, but it's already very easy to do without being detected; if land nearby has badly-set permissions then you can easily use objects to spy, so that's an already existing problem and more specifically targeted by SVC-241 and related issues. This can be addressed by having privacy-mode allowed by default, since I suspect that the people who need to disable it are more likely to be in a minority as most stores and homes would be unaffected and indeed could benefit from having it on. So long as the change is publicised so that combat sims etc. know when they need to be on to switch the feature off then it shouldn't cause much disruption.

While that might work for a sandbox, it will be hell for a abandoned parcels or protected land within a mainland region. A griefer can sit on that land and be invisible to sensors while launching their weapons.

If you turn off sensors you let the bad people hide from you too. It dosnt matter where you are, or what condition you put on the privacy function, there will be times and places where griefers can sit on one parcel and attack people in the next parcel. We already have no-script sandboxes that take care of scripted weapons. If scripted weapons in sandboxes are the main problem, ask for more sandboxes to become no-script. Then noone who pays for land will be inconvienenced by broken content.

I was involved in testing the changes Michael Linden made to Rausch the other month. At one point the entire region was no script for a day. Myself and a couple other people quickly re-scripted the POPGUN so it would not only fire, but it would kill,and even play the SPLAY sound from the bullet when it hits you too.
Other people shooting their expensive guns found the best they could do was get a bullet to REZ, which then fall to their feet because there is a bug in havok4 that ignores the verlocity parametor on rez over no script land.

My point, a privacy mode will only CHANGE the type of weapons used, not prevent weapons from working. If this jira leads to a privacy mode you can expect several weeks of lower griefing when you can rejoice in your victory over the evil griefers. ...and then the weapons market will catch up and it will be business as useral. Just like havok4 was going to prevent orbits, and did, for almost a week!

Darling.

Haravikk, I think this issue should be closed by now, the solutions above does not provide with any viable solution.
Any such implementation would in fact kill the effectiveness of all security devices we have in place at PSG.
We deal with griefers on daily basis and we are making great progress with preventive tools.

Making invisibility will not only make my role as a sandbox moderator hell, it would also hamper the ability to track and provide accurate inworld metrics of all kinds, which is a necessity to measuring performance in many ways.
This is unconscionable.

if you are the sandbox owner, or the sandbox manager, you're either the land owner himself, or at least in the owner's administrative group. The suggested functionality still allows such people full usage of the detection/sensor/details on everybody on the land, no matter if the targets have privacy enabled, so you needn't worry in that regard.

You're correct of course, we need to add some teeth to this, perhaps if we add an instant permaban to any account who creates scripts and objects designed specifically to defeat this proposed change, there would at least be some recourse.

Follow that up with a complete removal of all objects created by that account. All objects owned or otherwise by the account.

I'm talking about actually banning the creator, not the attacker. My thinking goes something like this, creators of this type of script have one object in mind, i.e. to benefit financially from grief.

This is not the way Second Life should operate.

Linden Labs should not be encouraging the creation of objects which have griefing purposes.

Perhaps this type of action would instill a sense of community into weapons scripters, and lead to a better experience for all, instead of a better experience for weapons users.

This Jira looks like a good place to start.

If memory serves me correctly, you were the one who made and sold the texture-spammer weapon in the Weapons Testing sandbox 12 months ago.

Why dont you get a secondlife of your own instead of shaddowing my every move? Is your life so empty that you can only find joy is harassing other people?

–

What do you think the odds are that someone will visit every single JIRA you have posted and downgrade them all to the "not important" priority? Even the really old ones and the ones that already have a linden assigned to fixing them.

Check out what Whispering Hush has been up to :-

http://jira.secondlife.com/browse/SVC-1462
http://jira.secondlife.com/browse/VWR-4185
http://jira.secondlife.com/browse/SVC-2114
http://jira.secondlife.com/browse/SVC-2336
http://jira.secondlife.com/browse/SVC-2336
http://jira.secondlife.com/browse/SVC-1533

This is another example of Product Griefing by another weapons maker.

–
Darling Brody

Would I instead hold the population hostage, and force them into buying defensive weapons?

I am about ending the arms race, limiting abuse, and getting on with second life, you're about lining your pockets.

Please surf in to this link Darling, so that you have a clear understanding of your position within Second Life.

http://www.thefreedictionary.com/pissant

Thank you.

Back on topic, after a talk with a friend yesterday I decided to pull my vote from the issue.
There is just too much content in SL that relies on correct, unhindered sensor behavior. Any kind of implementation of this short from absolute perfect would mess up too many creations. And there just won't be a perfect implementation, sorry.

Additionally, from the time of my last comment here til now, the GTeam seem to have improved their methods and response time quite a bit. Their current performance is quite satisfactory, kudos to them.
So if you are an estate/land owner, just ban offending persons from your sim, and no matter if you are or not, file ARs to solve the individual matter at hand.

For that matter, as written, this would b0rk every danceball or sexbed on group-owned land for anybody with Privacy Mode enabled. (Some rework of the proposal might fix those problems, but simply can't fix chims or huggers.)

If this proposal is to get further consideration, I'd really recommend just forgetting about the griefer/anti-griefer/combat crap for a while and consider carefully all the other stuff that will be inexplicably crippled when an agent activates this mode. Then consider how the hell anyone could document all that, such that non-scripter residents can hope to understand the implications of using it.

You're joking when you wrote "How does one go about explaining to customers that nobody in "Privacy Mode" can use their dance chimeras or huggers? " right?

Do you lack the ability to type a sentence in open chat?

Do you find it difficult to explain how to do things?

@soft linden

How difficult exactly would it be to water down God mode to fit this purpose? I'm thinking that hacking that code would be a good place to start work.

Sorry - no dice here.

You would be breaking anything that is not owned by a resident or on a parcel owned by the resident who intends to place out their security systems, vendors and other systems on a parcel that they would not have had to purchase in the event that this was never brought up.

You are also operating under the assumption that the average resident would actually understand what they are disabling when they activate this mode - most would not only fail to understand but they would also forget they even have this turned on - I know I would!

The current system tools, options and resident created content with this idea in mind work just fine thanks - If you are really that annoyed by such things - you really need to find a different calling and grow a spine. I have no problem with using Busy mode and telling the few friends and non-friends that continue to IM me afterward to buzz off and IM me later. Anyone that takes an attitude to someone actually being Busy is not worth the time anyway.

Tell ya what: Rename this travesty so it shows up in the UI as "Crazy-ass Paranoia Mode" and you've got my vote.

Currently a sensor will return the first 16 instances of whatever type is being scanned for, in this case AGENT. Under normal operation, this means that if I perform a sensor scan and there are 30 people within 96m (which is not unheard of in some crowded sims), the sensor() event will (thankfully) return only the first 16.

Now, suppose that many of these people were in "privacy mode" for whatever reason. Now my sensor function is scanning and parsing for the nearest 16 avatars who are not in privacy mode. This may not sound like a lot of extra instructions per second, but remember now that in the sensor() event will usually have some sort of code in it specifying what to do with the information. A radar, for instance, might then collect the names, keys, and coordinates and send them via linked messages to other prims or other scripts within the prim, possibly compiling them into one or more lists as well. And because of how the sensor() event works, usually this requires using some sort of loop, often a for loop along the lines of:

sensor(integer num_detected)

//possibly more stuff here once all data has been compiled

Ok, now why am I going through all of this? Because if you look at this, many radars wind up pulling quite a few IPS here, running the code inside the for loop once for each avatar detected. Now, either the simulator is going to have to take the first 16 avs detected, parse them for privacy mode, and then delete ones in privacy mode, add any others within range to make up the total, and reshuffle...in and of itself rather onerous for each llSensor() or llSensorRepeat() call (which can be quite often for some radars, unfortunately)....

OR....and this is where it gets frightening....rather than parsing every llSensor() call for each script, the sim could just wait until the sensor event and then hide the data for the "privacy mode" avatars, replacing them with others in range. This has the advantage of not requiring devoting as much overhead for each llSensor() call from every script just in case there are "privacy mode" avatars in reach like above, BUT, it means that in these select cases, the simulator is going to have to go through the for loop more than the maximum 16 times. For these cases, radars will start pulling far more instructions per second because the for loop will continue running its functions through each time until it reaches 16 non-private avatars. As I said, in certain situations in crowded sims, there is the potential for that to be a decent number.

The result, in addition to increased loads on the simulators, will be a greater number of stack/heap collisions as scripts that had perfectly fine memory allocation now find themselves having to parse far more data.

Just a thought.

sensor(integer num_detected)

// do stuff with lists here, possibly involving llList2* functions, etc

Now, imagine what adding in 5 extra iterations does for sim IPS if this is a fairly fast llSensorRepeat(). And imagine what 5 extra iterations add to script memory with three lists involved.

A branch on match would take no extra IPS at all. It's server side C, not server side LSL.

https://wiki.secondlife.com/wiki/PJIRA#Caveats

"The Second Life Community Standards apply to all areas of Second Life, including the Second Life Public Issue Tracker. Any Resident who disregards these guidelines may be banned from future use of the issue tracker.

Examples of specific behavior or actions which may result in removal from the Issue Tracker:

• Using the Issue Tracker to promote your business, cause, blog, website or anything not directly related to the issue at hand.

• Flaming - The act of posting a message that is intended to incite anger or directly attack a person or persons is called "Flaming" and it not appropriate for the Issue Tracker. Please keep to the facts of the issue at hand. Posts that disregard this may be deleted.

• Private Discussions - Blogging your personal opinions or off-topic rants. Pjira is about finding solutions to issues. We love productive feedback. Please stick to the technical details of the matter at hand.

• Editing Wars - Repeated changes to a resolution, priority or classification of an issue within Pjira.

Personal attacks or inappropriate posting with result in a written warning and can lead to banning. You are each responsible for you own posts - regardless of how or what someone else posts. Keep all posts to the issue at hand.

Like when all the pictures of Michaelangelo from TMNT start flying towards you, your av starts dancing, your window fills up with explicit chat, your computer starts grinding to a halt, and something starts following you around as you try to leave... it would be lovely to be able to click a button, stop all the bad scripts & all the bad chat, then turn off your particles & carry on working while you wait for them to get booted.

I realise it could be used by the wrong sort of people in a bad way, but like most things, the possible solution could be the simplest one... Release the mode like the person who started this said, but make it only available to residents with payment info on file, or premium customers. That way if anyone uses it in violation of the ToS, then they can easily be traced in the real world, and real legal action can be taken (if required).

'Coz it seems to me that the only reason bad folk do what they do in SL is in the inherent anonymity provided by it (or any other virtual world for that matter). Anyone can start a new SL account from an anonymous web-based email address that can't be traced except by serious police/FBI type folk, who have far better things to do that find the man who's ripped off a few hundred linden dollars worths of stuff & started selling it in his own name. When linden labs have your payment info, they have your real name & address. If they have that, they can take action.

Take away the anonymity by making them easily tracked, and they'll be less inclined to break the rules. At least I reckon so anyway. And I also reckon anyone who would complain obviously has something to hide, I mean, if they were squeaky clean, there wouldn't be a problem, right? After all, isn't the thing we all want most; more squeaky clean honest folk, being nice & buying things and not some teenager with 50 separate accounts running around causing havoc, just because he can - and freely?

I'll shut up & go away now...

I think that until someone can come up with a feasible method for implementing this feature that addresses the many issues raised above, this ticket is basically dead.

The original issue SVC-125 that led to this discussion was instigated by Psyke Phaeton maker of the Psyke's Defense Systems(R).
Late in the comments you will find Psyke adding the following which indicates he was not aware at time of instigating his JIRA ticket on llSensor / llSensorRepeat that it would have the consequence of removing the use of this call to avoid follow attacks.

<QUOTE>"Both sides of the debate want protection from trouble makers. Both sides want the same thing. The problem is that the old solution for non-private land, conflicts with the solution for private land.
PDS specialises in protecting private land and uses the scripting method llSensors() http://wiki.secondlife.com/wiki/LlSensorRepeat to do this. The problem with this, prior to the fix of issue SVC-125, was that llSitTarget() http://wiki.secondlife.com/wiki/LlSitTarget could be used to avoid the llSensor() giving griefers the ability to access land they should otherwise not be able to. PDS has a responsibility to it's customers to make sure this problem is resolved.
This problem became increasingly apparent and caused Psyke Phaeton to raise the issue in the JIRA in March 2007. At the time the issue was called "Unknown scripting method allows evasion of llSensor". It was not until October 2007 that the method used was made known to Psyke. At this point the title of the issue was renamed to "llSitTarget allows evasion of being detected by llSensor" and people in "Psyke's Scripts" group who used PDS security orbs were made aware of the problem so they could vote to have the issue fixed if they wished.
It was not realised at this point that people were also using llSitTarget() to avoid griefers who were using llSensor() based scripts to annoy and attack them."</QUOTE>

Darling Brody offered a scripted solution to upgrade security sensors to detect 'phased' avatars.
But issue SVC-125 was deemed a bug i.e. not expected behavior so it was 'fixed' before the ramifications were thought through.
As it was the ONLY method to avoid follow attacks without leaving the area and required no new LSL functions or bloat as described in this Privacy Mode request it should be reinstated in the code until a (better) solution is found.

If the only reason to change it is because it is not an expected function then we are applying anti-evolutionary flat-earth thinking to the problem.

WarpPos, megaprims, lipsync are examples of 'bugs' or 'exploits'. We use them in ways that were unintended (so don't bother explaining to me warpPos bypasses jumps of 10m - that's not my point - my point is, we're exploiting these to our benefit every day).

When will we wake up and say "Hey, that was indeed unexpected behaviour - how can I use that to my advantage?"
Or do we wake up and say "Hmmm, I have anal retention and I did not expect that outcome - kill the heretic and it's creator!"

OK, so I may be over reacting but here we have a clearly useful function of llSensor (documented or not).
We also have a script for sensing phased avatars.
If Psyke had spoken to Darling before filing SVC-125 chances are, he'd have a better product and we'd all be sitting on our phased chairs ignoring griefers, not filing AR reports against follow attackers (coz we couldn't care less if they can't target us) and letting LL get on with improving SL.

So, YES - if you want to be pedantic, black & white or just plain anal, 'phasing' relied on a bug.
Should that bug be crushed like a garden variety cockroach?
Probably not.

How else did we lose the scales and gills, gain opposing thumbs and start to build emulations of our own world if not for 'unexpected behavior' from existing physical rules (read code)?

LL has handed the keys to the griefers and taken away our ability to protect ourselves.

Maybe instead of trying to work out what we can and can't sense, it would be easier to make targeting an Avatar a permission request.
You can sense them all you want but if you target them, they can choose to be a target or not.

I only make this suggestion because I can see 80 votes 'fixed' (and I use the term loosely) SVC-125 but there are obviously many more who would like to have maintained the status quo.

Therefore I don't stand a chance of having SCV-125 reinstated as it brings us back to the circular, insular argument "It's a bug!"
Even though it broke nothing and a security orb could be upgraded to deal with phased objects/avatars (being the original reason for the ticket).

Mark Twain is always good for an evolution quote:
"Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover."

Better yet: "I was seldom able to see an opportunity until it had ceased to be one"

Finally may I suggest to LL that ANY forthcoming issue that potentially breaks existing content be given a longer hearing time in JIRA and have all sides given reasonable notice.
Psyke's own admission he did not know this would affect legitimate uses of the llSensor call would ring alarm bells for me at Club Linden.

An irrational fear of bugs (just coz they're bugs) is a phobia.
Most RL bugs are of some use to us whether we care for them or not.
They've been with us for thousands of years and we have only discovered their true function in maybe the last 100 years.
I can hear the ball-bearing rattling the RAID can now!

Both types will look it over, try to figure out what's going on, maybe figure out why it's doing what it's doing.

The first type will report it via JIRA to let others know about it and to see if it is something that needs to be fixed.

The second type will keep it secret and put it into their own products, even though they know (or ought to know) that buggy code is likely to be fixed by LL at some point, thus they wind up knowingly selling products to their customers that will cease to function at some point in the near future.

(Also, I know this ain't gonna fly, but I move that the next person who calls WarpPos a bug should have their JIRA priveledges revoked. I am only half-kidding).

Rather than rehash all of the arguments from SVC-125 (and SVC-1475), I would suggest that those interested please go back and re-read those tickets before commenting here again. I believe that it was made very clear by several individuals as well as by employees of Linden Labs that the behavior fixed in SVC-125 was clearly an unexpected malfunction in how llSensor() is supposed to operate according to documentation. Restoring things to how they were prior to SVC-125 would be, in the words of Soft Linden, "...penaliz[ing] scripters who used correct coding."

There was already a ticket asking Linden Labs to re-break llSensor() and restore sit-offset "phased" chairs: SVC-1475. If you would please take a moment to read that ticket, you will see the reasons listed by Linden Labs employees as to why they would not be reverting the fixes in SVC-125.

However, you do make one good point, in that it is important that LL take care in implementing fixes that might break existing content. For instance, this particular ticket could, depending on how it was implemented, potentially break content that relies on llSensor().

And finally, the "evolutionary" discussion in your post (I use the word in quotes because it bears little resemblance to what actual evolutionary biologists would tell you) is very misleading. SL is in many ways an artificial construct, and while it may evolve to some extent, it is important to remember that Linden Labs does exercise a good deal of control over content and service, and that things like the Linden Scripting Language are most definitely artificial constructs.

(oh, and not all evolution is good evolution....just ask your local neighborhood cancer cells).

Your response is insulting to myself, to Linden Labs, and to other users of the JIRA.

"What if an object required permission to follow (using llSensorRepeat()) an av other than its owner after a set period of time. Thus, llSensor() would not be affected, and llSensorRepeat() could track an av for some period of time, or perhaps indefinitely if it was a certain distance away or if the object itself did not move, but a moving object that was continuously using llSensorRepeat() to track and follow an av closely would only be able to do so for, say, 30 or 60 seconds, after which it would trigger an llRequestPermissions() dialog?

Of course, it should be mentioned that there are still even legitimate uses for llSensor() and llSensorRepeat() in the context of following object, just as tracking "sniper" damage bullets.

Also, as with many other proposals, the owner of the land should be exempt from this limitation, as there are legitimate reasons for temporarily "trapping" an avatar and giving them the option of teleporting back to a welcome area, or being teleported home.

My guess is that the concept I've just laid out is probably not going to work either, but at least maybe it will suggest other options."

We can't add the permissions for each and every llSensor() or llGetObjectDetails() call, since this would pretty much break every radar and security orb in SL. Short-term use of these functions clearly can't require permissions. However, follower objects require re-acquiring the coordinates of the target using either llSensorRepeat() or repeated calls to llSensor(). It might be possible to add in the permissions requirement if these functions are used repeatedly to target a specific avatar for greater than a certain amount of time.

Again, however, remember that many legitimate weapons may also be using these functions. While adding a good time delay may prevent them from being broken (at least in the case of sniper bullets), it cannot be completely guaranteed. There is much potential to break any number of items if permissions were required for the llSensor() llSensorRepeat() and llGetObjectDetails() functions unless they were well-crafted, which is why I mentioned way back in March that it would be unlikely to be feasible, and I eventually dropped the idea in favor of land-based permissions like everyone else.

However, here's an interesting idea:

What if muting someone prevented objects owned by them from being able to return your information via the three sensor functions? Or perhaps it would only prevent it where you were specifically targeted by said functions but not when llSensor() or llSensorRepeat() were used with no avatar specified.

It could also apply only to objects and not to attachments, so it would not impact radars. And of course, the limitation would not apply to the land-owner, who would still be able to have his items sense you over land he/she owned.

llTarget(vector position, float range) does not specify an avatar, therefore it is difficult to understand how permission would be requested. Would it request permission from avatars within range of position? This would be rather odd. Furthermore, llTarget doesn't actually cause the object to do anything in and of itself, it simply sets a target and tells the script to trigger an at_target() event when the object is within range of the position, as well as triggering a not_at_target() event while not in range.

While this function is useful as an alternative to repeated calls to llGetPos(), it doesn't actually do much useful in terms of followers and such. Its only real use would be if it were scripted to do something when it arrives at the person. The problem is that it would still require either repeated calls to llSensor() or an llSensorRepeat() and THEN require repeatedly calling llTargetRemove() and then re-calling llTarget() in the sensor() event with the target's coordinates. And of course using llMoveToTarget() or some form of WarpPos to move the script to the target coordinates.

All that llTarget() does is set up the ability to have an event triggered when you reach that target. I'm not sure that requiring permissions for llTarget() would solve the problem, even if there were some way to request permissions for a function that does not, in and of itself, specify an avatar.

If not impact a number of specialized simulators throughout the grid. Such as combat sims, corporate sims with greeters, even newbie intro areas with interactive tutorials (if by some mistake they activate the client feature). In a number of cases it is completely undesirable to have this function at all anywhere on the estate.

While in a nubmer of cases the On Owners Land applies, this is not always the case and it is disired to be off for everyone (such as in a combat sim, be it Linden Damage or DCS).

*****

This is a feature request, therefore the "effects version number x" stuff is not ralavant. When your asking for a new feature you do not have to tell LL that te feature dosnt exist in ever single server version they have put out...

For the record I am apposed to any feature that would prevent sensors from working. This would break every single product on the market designed to eject griefers from your land. Many security devices re-ban people from the land who are on neighbouring parcles to stop them sneeking on between sensor sweeps, so even a parcel level version of this would create security issues.

This whole issue started because someone who makes a security device didnt like the phased vehicle protection method which partially evaded sensors. Once the phased vehicle protection was "fixed" by linden labs this jira turned up to try a back door re-instatment of sensor evasion.

Regarding your comments; the feature isn't intended to break security devices, and shouldn't, as it wouldn't hide people from devices you've placed on your land. It's intended to stop attachments, or items rezzed on others' land from being able to lock onto avatars and annoy them.

For the case of "scan hopping"; a security device can get around this by adding an ejected user to the parcel-ban list temporarily. My home-scanner, which I made myself, does this for a full 24 hours or so. If the offender is then seen again (and the device's cache still contains their name), then they get banned for even longer and longer periods till they eventually give up, it also uses llGetObjectDetails() between its regular sensor-sweeps to detect recent offenders within much shorter time-periods without causing any undue lag.