Stop the Peeping Toms / Camera Limitation

Reason one: freedom to move. Moving my camera + sitting is my way to move, not moving my avatar.

Reason two: splitting/joining parcels in a whole sim from the sky.

Reason three: lassoing/changing properties for a whole parcel/sim from the sky.

Reason four: editing a far object or script from my seat.

Reason five: tracking a griefer in my sim.

More on demand.

These 2 have happened already, with the German "Child Porn" expose, and the John Edwards fiasco on FoxNews.

Jeff, you're not really giving reasons why it is "a bad idea to give people the option to have privacy at the expense of camera freedom". All your reasons are merely downsides stemming from a bad choice of implementation, that's all.

You would still have total freedom to move, either physically or by camera, except where people have expressly demanded privacy.

You can't claim that your "freedom to move" overrides someone's "freedom from intrusion" --- that would be like claiming that your freedom to kill overrides someone else's freedom to remain alive. The rule of symmetry says that your personal freedom can extend only up to the point where it starts to destroy the equal freedom of others. That's the essential balance. Any "freedom" that goes further isn't actually freedom, but coercion by one side against the freedom of another.

You would still be able to do those two. The properties of a parcel or sim are not dependent on the properties of subparcels or plots within it, and under the "simply don't send the objects" implementation you wouldn't even need any special handling for whole-area actions --- the protected areas are simply not visible to you at all.

You would still have total freedom to move for editing purposes, either physically or by camera, except where people have expressly demanded privacy.

I assume that this refers to the issue of griefers sealing themselves off within a privacy cloak.

That can be handled in a number of ways, the two simplest candidates being (i) private areas are marked as being "off sim", so that there is no possibility of direct griefing, and (ii) the entire privacy area is marked by an always-visible standard placeholder that is tagged with its owner's name and carries the same responsibility as the corresponding avatar at that same position.

Either of these solutions removes any griefing complications.

Morg.

we're talking about the camera not avatars walking around


we're talking about the camera not avatars walking around


we're talking about the camera not avatars walking around


we're talking about the camera not avatars walking around

the only valid points are the secret revolutionary new product and someone watching your TV. but wait! i just remembered that people cann't watch your TV if they're not on your parcel. so you're down to one point, and while it's a good one, no one has come up with a good solution short of buy a sim.

I agree with Jeff and Sarah for reasons to not limit the camera. Too many good reasons. It's not what can see that's the problem....it's what can be seen. SL, give us private versions of our homes like other games do.

Morgaine Dinova debunked Jeff's reasons.

All this over people not wanting their 9 prim virtual p-nises, or veginas being virtually seen by someone who probably could care less, other than to think whoever's wearing it is r-tarded

my vote: HELL NO, IM A PERVE!

I was talking about privacy as a whole, which is essentially what this thread requests and because a large number of people were talking about it being a ridiculous thing to want.
The issue is that camera retrictions wouldn't help, as there are too many ways around it, and it would just make things more difficult for builders without solving the problem.

99.9% of TVs out there let you do picture slideshows too. And it's perfectly easy to be on someone's land and watch their TV without going within range of their access-list barrier or security scanner, since access restrictions on go up 90m and a security scanner that covers the whole land would be horrifying. All you'd have to do is hover over any restrictions in place and use your camera to look in, WHICH IS PRECISELY THE ISSUE. Still perfectly valid.
And the issue of a home being a home is valid too, I made my home for ME and my friends ONLY, I don't want other people to look inside let alone BE inside it, it's mine, not theirs.

Um, so the idea of not streaming content to the client isn't a good idea that wouldn't require a sim? If the client program doesn't RECEIVE the content then it can't SEE the content, EVER. That's what the 3D zones proposal offers, and other (less flexible) systems use:
https://jira.secondlife.com/browse/SVC-99 (3D Zones)

You put up a box that only people allowed in the box can see the contents of. Everyone outside the box sees nothing (except maybe an indication that it's there so they can avoid it).

While there are many possible ways to achieve the desired privacy, I think we need to take into account that many thousands of good ideas suggested over the years (let alone a bazillion less good ones) all foundered on the same rocks: LL has limited dev manpower.

This is highly relevant here, because any effective privacy has to be implemented server-side, so any contribution from the community can't really help much at all.

With that in mind, here is a possible design that requires almost no dev time to implement. I'll be the first to admit that from a user's perspective it looks incredibly primitive, but that's the whole idea: simple design, quite trivial to implement. But here is the bonus prize: it would be scriptable, and therefore the community could turn it into a powerful user-friendly facility.

The idea is simplicity itself: just provide two "privacy flags" per object, Owner Privacy and Group Privacy, plus a Privacy Group selector field that is active only when Group Privacy is enabled. Access to these 3 fields should be ***through LSL only***.

In addition, the avatar also has these 3 fields. Attachments inherit the values of these fields from their wearer. Linked prims inherit the values of these fields from their root prim.

The semantics of this are as follows. For each client, objects without any enabled privacy flags are streamed down as at present. Objects with Owner Privacy set are matched against your identity, and only streamed to you if you are their owner. Objects with Group Privacy set are matched against your currently active group identity, and only streamed to you if your currently active group matches the Privacy Group selector field for the object.

And that's it.

I expect that it would take LL devs several days to think about the ramifications of this, and then an hour to modify the code appropriately, ready for testing. The reason for my suggestion of ***LSL only*** is specifically so that no UI modifications are required, as that would require much more work. Man days cost money.

What use is an LSL-only solution to the majority of users? Very little, but SL is full of clever scripters, and very soon we would have scripts and HUDs etc that would allow us to select exactly those objects contained within a given area and no other, and to turn privacy for that selected set of objects on and off with a single click when required.

And it would be the most secure form of *visual* privacy, since what is not sent to a client can never be seen by it. It does not address chat nor voice privacy of course, but visual privacy would be a damn good start.

Morg.

Issue:
Collision detection is done server side. What happens if you create a barrier set to owner-private? Is it automatically phantom? No one else can see it, therefore they should be able to walk through it, yes?

That's actually essentially how the 3d Zones idea would likely work =)
Each object has a few extra flags server-side, which are set/unset when they collide with (or otherwise enter/exit) zones. These flags then determine if they get sent to a client outside that zone, or if their chat can be heard outside the zone and so-on. Zone checking is easily done since a person/object can only be in a single zone, so it's just a comparison of zone ID numbers
Ultimately it's a few flags and if-statements building on-top of the existing collision detection (but dumbed down since it doesn't need to look perfect).

As with yours, the really most difficult parts are adding an interface to control it (though still, it's just prims basically), and making sure it's tested properly on the beta grid before it hits. Could be done nicely with a 'Zone labrytnh' where you have to make it through a maze avoiding access-restricted zones, and without being able to see what lies on the other side of walls (because of culling zones)

I dunno, even the simplest solutions aren't actually a far cry from some of the more complicated ones. And we've had many simple ideas floating around for ages, e.g let people CHOOSE the height of the restriction area on their parcel with a limit of now more than 60m between them. You can then add culling to anything in that area for blocked users. Even that while simple hasn't been implemented in the two years-ish I've been here.
The issue doesn't seem to be that LL can't develop it, simply that they won't, even though a lot of people want and frequently request it! The reason they're short on manpower is because they have teams of people working on things that while nice ultimately don't really add anything to the game. I mean even now, flexi-prims are everywhere, but I don't see that they've really added anything much, I was happy with my solid prim tail, the new flexi one is nice, but I'd rather have performance and privacy. The new skies look wonderful, but I'd rather have performance and privacy. etc. etc.

Collision detection is usually done client-side, with validation of the collision event through client-server interaction. Or at least that's how it SHOULD be done, as it is in normal MMOG and FPS games, for a very good reason.

Pure server-side collision handling would never scale and would have terrible performance. Usually in interactive games, the client does collision path intersections at the same time as speculative positioning on movement, because servers+network are just too slow to support fine-grain positional updates.

Of course, I have no idea how LL actually does do it in SL, but since they are generally very sane and clever in their implementation (the static grid excepted, hehe ), I expect this to be done sensibly as well.

With regard to your question though, my scheme doesn't touch bounding boxes at all, so they would work exactly as now. In other words, the bounding box of an object changes as the dimensions of the object change, whether you see the object or not. Since objects are not downloaded if you don't have permission to see them because of privacy, this clearly implies that the bounding boxes still have to be transferrable separately. There's simply nothing to see inside them, though, if you're barred.

My guess is that LL does the calculation of bounding volumes from the prim parameters on the server, because doing it on the client would be open to abuse. Which means that they should be able to transfer the bounding boxes separately without difficulty, even if they don't at the moment.

Morg.

I think that your scheme is much more ambitious than mine, and it certainly covers more ground since mine doesn't deal with sounds, voice, or chat privacy.

However, your scheme pays a far, far larger price in dev time --- we're easily talking 20-50 times larger, I would estimate, because UIs issues are very hairy. Maybe 100 times. You have new prims, a new editor mode, a new visibility mode for those prims, new constraints on those prim dimensions, and new download and caching types.

In contrast, I have no new objects at all, no editor, no new features nor any other changes whatsoever in the GUI, no new constraints for the client to check, and no new downloads nor caching types (unless the bounding boxes are not currently separate objects, in which case they'd have to be factored out from the prims).

The only simple part of your scheme (the zone matching) is equivalent to my matching of the privacy field values.

This isn't intended to suggest that your scheme isn't good --- quite the opposite, it's better than mine, and has far better coverage of the privacy issue. However, the cost is large.

I'm just mindful that visual-only privacy is far, far better than no privacy at all, and if you propose a costly scheme, the chances are large that it simply won't be entertained.

It's also worth adding that, because the juicy bits from a paparazzi point of view are all visual, my scheme would probably provide 99% of the protection needed to handle the really vicious side of the snooping business.

Morg.

I mean a good solution in that most people just want to buy some main land, throw a house down, flip a switch and have some privacy which is not going to happen. all the schemes i've seen so far would either be easy to bypass client side or use to much resources server side. the best solution i've heard was i belive in a nother thread someone was talking about instances in WoW or EQ, which are basically little virtual sims spawned just for your house and aren't connected to the main world.

If we're looking for something LL can do really quickly and easily, I would propose that a parcel flagged private would automatically exhibit red ban tapes for unauthorised avatars (as well as the proposed non-download of parcel data to client of course). It's not ideal but at least it gets round the complex algorithms of what to do about avatars flying through private space and being a possible distraction to the private activities taking place within.

leliel, my design would do exactly what you describe, and would burden LL with the absolute minimum of dev effort. LL would need to add only 3 fields to the object class, implement one single LSL function to manipulate them, and put a conditional download block in the server streaming code. That's it.

(Bounding boxes seem to require no extra work at all, because when you enter a laggy zone, you are rapidly constrained by bounding boxes long before you see the objects inside them. So, my guess is that bounding boxes are already separate objects as required.)

And then it would be down to scripters to provide exactly what you asked for: eg. flip one switch, and all objects and group members in your plot would become private, it could be as simple as that.

One would certainly expect privacy management gadgets to provide a standard mode of "Private Land" as you suggested, since it would be a common requirement. Of course, other modes would be possible and popular too, like "Private Avatar and Attachments", "Private House", "Private Room of Secrets", etc. Scripting is versatile.

And far from creating a load on the server, this would of course reduce the load, since objects would not get downloaded to people who are not in the privacy group.

Morg.

Muhahaha PWND

I voted 'Hell no! I like peeping! I'm a perv!', too
but in fact i dont waste my time with 'peeping'.
because there is nothing really hot to see in SL.

I think there is one other reason for privacy. Most ladies start their days wondering what to wear and really do not want to be seen while they try different outfits in varying combinations.

I am a guy who has not changed shirts for at least six months, but I do thing we should respect the 40 % of residents who claim to be fem.

Most of the discussion, especially by Morgaine, has concentrated on hiding prims. Whilst I can see that protecting that wonderful innovative idea in a prim is important, we really need to look beyond that at the avatars, both what they are wearing (baked/baking) and what animations they are running.

LL seem to have a non-technical policy that avatars should never be able to hide themselves, so this would need further discussions. My guess is that this is a social decision. Maybe show the green dots on the minimap but don't show the av's themselves. That needs to be thought through a little. We could do away with ban lines altogether, making SL a much nicer place to move around in, and for maximum privacy, hiding and non-hiding av's should not be able to see each other. Iow, we are moving towards private instances of our hidden areas.

Would this also mean that our hidden av's could not see the romantic beach next to their parcel, or the sunset? Not so simple, is it!

As someone has already pointed out, the sim only knows about bounding boxes (both av's and nonphantom prims have fixed sized bounding boxes) and feeds them into the physics engine to check for interactions between prims and av's. So now we need a physics engine for the sim as well as a physics engine for each of the private areas in the sim. Anything less would lessen the realism of the immersive experience. We would probably need havok 9 for that.

So we really need to discuss exactly how we want this to work, without worrying too much about the technicalities, and this is going to result in some major social changes. If 90% of the sim is set to private, it might be a very very bare sim.

Anyhow, midnight is approaching, and I must be off to bed.

Happy pontificating!

Ed

You are right. I give you reasons why it would be a bad idea to constrain camera freedom. What is a good idea is to give people the option to have privacy without restricting camera freedom. The "don't send objects" is one.
I refer to griefers taking advantage over me from the fact that I have 600mS ping time while they have 150.

That's merely an implementation detail. The goal isn't to hide prims, but to give players privacy. It achieves that. And it's not really about hiding prims anyway, but about reducing the objects that are downloaded, including the objects that make up avatars, by marking their host containers (prims and avatars) etc.

Using object-hiding to achieve player privacy stems from trying to find a design that requires extremely low investment of dev resources by LL. It's not the goal, it's an enabling technology for the goal.

Being a systems developer, I tend to think in terms of what program-level changes would be required to achieve a particular function, rather than just think of the function alone from the user's perspective. Too many suggestions are conjured up out of thin air without realizing how much dev effort will be required to implement them, and that results in good ideas being effectively "impossible" in practice ... LL simply doesn't have the resources to do the work.

My approach would at least have the benefit of absolutely minimal dev effort, while still achieving very flexible visual privacy, no server loading (actually a decrease), and no new restrictions on physical access nor on camera navigation, which would remain as now.

Morg.

My point had one to do with griefing. If those "invisible, but tangible" boxes existed in public land (or really any land that doesn't have auto-return less than about 10 minutes) NO ONE can see them, but everyone bumbs into them. No one can find out who put them there because (being non-downloaded) they can't be clicked on.

That. Is. Bad.

Easily solved, Draco.

Make the privacy bits disappear 5 minutes after their owner or enabled group leaves the sim. Or hey, make them disappear instantly. How long to retain privacy status is just a matter of policy. I'm providing only the mechanism for it in my design, free of policy decisions.

Discussions over policy can go on forever. Life is just too short ...

Morg.

Addendum: I should mention implementation, since this privacy design flies or dies depending on the effort needed to develop it. Well it's easy in this case. Eg. for the "instant release" case, when the sim finds objects to block based on privacy rules, it simply adds them to a blocked list for disallowed clients, as well as to the download queue for permitted clients. Then, every time that someone enters or leaves the sim (which has a very low duty cycle), it checks the blocked list and releases the privacy bits if the owner or group members are no longer around. Very simple. I would seek scalability by organizing the blocked list by owner and privacy group, but that's just optimization.

I can't believe I'm going to respond to that stupidity, but here goes.
Same griefer does the same thing, but gasp, this time he wanders around blind like the rest of them, or doesn't do anything at all.

Now they bits don't disappear and he gets to watch the fun!

Any danger of using reason rather than invective?

In this case, you simply haven't understood the design goals nor implementation. Blind wanderers will continue to wander blindly. If you want a feature implemented that deals with blind wanderers, go and suggest it. We're discussing something entirely different here.

And by the way, blind wandering is hardly the epitome of griefing. In any case, this proposal is not related to griefing in any way, and does not make griefing any better or any worse. In fact, it is highly likely to reduce griefing, because griefers seem to gain their pleasure from people's reactions. When they can't see the people, the gratification is probably reduced.

Morg.

I'm talking about "blind wandering" because people can't see objects that are in their way.

Got it?