Stop the Peeping Toms / Camera Limitation

This thread is probably moot now that LL has officially sanctioned peeping and informing Tom's.

Rest assured that many proposers on these forums are very well acquainted with what goes on under the hood in such systems. For some of us it's our day job.

Unless you have some inside knowledge, we don't know that.

A general Earth-based physics engine would be expected to handle negative heights just fine, because altitude is referenced to sea level on Earth. Plenty of normal land locations are below sea level, even without dropping below the surface of the oceans, so a general purpose physics engine that failed below zero height would be a flawed one.

That said, games and 3D worlds do not necessarily use general purpose physics engines of course ... but we just don't know here, in the case of SL.

Still, you make a valid point that it MAY not work at depth, and if so then redesigning the engine with better maths would put the proposal waaaaaaay out of reach on cost. So, this is very relevant. But see below.

Indeed. There can be nothing simpler than a region tagged as private to its owner, the objects of which are never downloaded to any other client. However, unless you enjoy a lonely existence, you would have to extend this to the members of your active group at least, at which point it becomes very similar to my proposal.

What you've just described is identical to Haravikk's proposal using bounding boxes to delimit privacy. And since the contents have to be marked as private in order not to get streamed to others, it's identical to my object-marking idea at the server end, with the added complication of the bounding box.

Argent's idea is far superior.

The only *potential* problem you highlighted with Argent's proposal was that physics might not work at depth. That then is the only part of his design that may need to be improved.

Well that's simple: since only the owner can get to the basement directly (as it's done through an LSL call) and everyone else is teleported in, there is no need for physical continuity between the outside world and the world inside the basement. Consequently, the only change needed is to remap height within the basement on rezzing, ie. add 1000m or whatever to height queries. If we assume that object properties like position are returned using methods, then this might well require just a one-line change in the code.

Also, there is no need whatsoever to create additional bounding boxes --- let the basement be exactly the same shape as your plot. Anything that rezzes within it (determined by trivial depth check) is automatically marked as private to that basement, which includes avatars. The corresponding objects are then downloaded only to clients whose avatars are marked with the same basement ID. Easy.

Morg.

True enough, Brenda.

But these discussions are also very valuable input for designers thinking about Third Life.

After all, if LL alienates enough residents, all that achieves is to create more fertile ground for competitors.

Morg.

Anyone should be able to access your privacy box. Up to the owner to protect access. No access lists, just owner protection. Once in the privacy area, anyone should be streamed the objects'av's from that area. No ACL overhead, just by av position!

The sim would hold an array or a linked list and stream that to anyone who is in the bb. It should not be necessary to stream anything else to that client since they would be only interested in what goes on in their bb. No other programming changes required. We all agree that this is necessary for any proposal to work.


My proposal is different because I would put the responsibility of protecting access to the bb to the parcel owner. He/she needs to put a structure around it to stop access. That structure would need to be in normal space. It would be in the owner's interest to protect the bb. Lack of protection should be ARable! Therefore, less programming.

There are a variety of ways to go through walls and doors. Security orb would take care of that.



You are describing an instance of a physics engine just for that underground privacy parcel.

Once someone is somewhere they can create LM's and then that parcel is no longer inaccessable. They will always be able to tp back into that area.


LL may well like a proposal which takes the heat out of the current arguments. The current problems are all publicity driven. Nothing to report = no bad publicity!

The physics engine is still a very basic Havok 1, customised to SL. Havok 2, 3, or 4 may well make all this much simpler.

First: "anyone can access your box" violates the privacy rule.
Second: objects CAN NOT (by inherint nature of the way they work) prevent the camera from moving inside.
Third: objects CAN NOT (same as above) prevent the client from downloading information on the other/in- side of that object.



Fourth: if there are ways of passing through an object that violates the provision of your proposal
Fifth: Security orbs should be FEWER not MORE with each security/privacy proposal.



The parcel basement idea accounted for this. And there are still landing points that over-ride final destination.
First: only an object or person already in the basement (or an object up top) could move the avatar down.
Second: ANY landing point set on the surface will over-ride the landmark destination.

I am merely moving the access responsibility from LL to the parcel owner.

No problem with the cameras of clients whose av's are outside the bb. They will not see anything since the bb contents have not been streamed to them.


I think that every reasonable proposal so far has put that responsiblity on the sim. Mine is no different to the others in that regard.

All objects in the bb should be visible to anyone in the bb and to no-one outside the bb, including the parcel owner. The security orb should take care of residents who slide themselves in while sitting on things or who attain sufficient velocity to fly through the wall. The invisible inner walls could be phantom with sensors to activate security.

Nothing wrong with a security orb that covers your own parcel only and is tuned to the limits of your bb.




I stand corrected.

Just to clarify, by "bb" you mean "bounding box" and by that you mean the physics interpreted volume of a single prim, yes? At 10x10x10 meters?

Sorry, by bb I meant bounding box, but unlikely to be 10 x 10, and unlikely to be as defined by others. I just use it as another way to describe the private area.

The whole key to my proposal is to require the minimum of LL programming to make this work. Anything that is possible to be done by residents under existing conditions should be done by residents. Also, my proposal has absolutely no effect on the operation of the physics engine, only on the way prims and av's are streamed to clients.

Say you have a 512 parcel, worst case minimum sized (I know you can get smaller, but 512 is what many people have first time round), then your dimensions are usually 16 x 32. You would carve out a new parcel of 8 x 24 for your bb, leaving a boundary 4 m wide all round your bb. You would put the outside of your visible dwelling in this boundary all around your bb and properly protect access through it with a security orb. Then you would put one or two rooms totalling just under 8 x 24 ( could be two rooms 8 x 12) inside your bb and they would be invisible to anyone outside your bb. The whole thing could be two storey, but then you'd probably run out of prims in a 512.

Since lsl does not know anything about your bb, your security orb could be anywhere inside or outside your bb.

What would motivate the parcel owner to provide that protective corridor? Simple, without that there would be no controlled access. That should also be ARable since residents will hit the prims in the bb and not know what they hit. In a way similar to moving in a sim before everything has rezzed. The sim knows you can't move somewhere, you just can't see it. The larger the main parcel, the smaller the effect of the corridor would be on the bb size.

The parcel owner would need to define a lower and upper height level for that inner parcel to define the bb.

On reflection, there would also be no need to restrict these bb's to a particular height range. The visible protective walls would just be parts of dwellings as they are now.

There are probably a heap of aspects to this I have not thought about, so I am very happy to leave it to others to pull apart. That is what discussions are for. It is just possible that we might get some of our liberties back if more things can be done in private.

I've said nothing about typing as in "say", but I would assume that those in the bb would communicate using im's.

I edited my last post to include an answer to Draco's point 4.

Although a large number of variants have been discussed here and in other threads, it is possible to partition the ideas-space of design approaches for stronger privacy into three basic types:

1) Inner Bounding Box.

2) Parcel Basement.

3) Object Marking.

Here's a short description of the salient feature of each approach that makes it distinct from the other two. Any actual design may draw elements from more than one approach of course, but in every case that adds to the dev workload, because each of these approaches can work entirely standalone as well.

(I'll add links to the relevant articles when BBcode is back, or it gets unreadable.)

==============================================

1) INNER BOUNDING BOX. [Haravikk Mistral]

The Inner Bounding Box approach entails the creation of one or more bounding boxes within a parcel space, and uses that bounding box as a volume marker to enable privacy on all objects and communications contained or taking place within it.

This approach is very simple and lightweight at the download end, because objects so marked simply do not get downloaded to a client whose avatar is not within the same bounding box: it requires only a bounding box identity match. However, the server needs to detect entry to and exit from each such bounding box and identify the objects residing permanently within them, and that is much more involved. Also, there is a very substantial UI component to this proposal, since the bounding box is inherently a manually user-controlled feature.

The word "INNER" here is used to distinguish between whole-parcel bounding boxes and smaller ones carved out within the total parcel space. An inner bounding box requires special construction, indentification and access handling, whereas a whole-parcel approach dispenses completely with all of that, and uses the existing parcel identification and detection instead. While from a user's perspetive there seems to be some similarity, from a developer's perspective there is little or none.

2) PARCEL BASEMENT. [Argent Stonecutter]

The Parcel Basement idea belongs to the general category of Instanced Zones, common in many MMOGs, and indeed "instances" have been mentioned in the forums many times in the context of SL. What makes Argent's proposal excellent is that it provides an actual design for instancing rather than just a feature suggestion, and because it is extraordinarily lightweight.

The essence of the idea is to achieve instance isolation using an existing impenetrable barrier: 1000m of bedrock. Because the ground is impenetrable to any significant extent, all of the methods by which invasion of private space could be achieved are blocked. The world above ground is unaffected so corner cases are virtually eliminated, making for easy testing and safe release.

It should be noted that none of the above-ground proposals enjoys a similar safety: the continuity between public and private spaces in other suggestions virtually guarantees the existence of problematic corner cases.

In terms of implementation, the Parcel Basements design requires no UI changes at all since the basement is the exact same size and shape of its land above, but moved downwards and of limited height. Objects within a basement never get downloaded to the client of an avatar who isn't in the basement, so the only marking required for download objects is with their basement ID, to ensure that two adjacent basements from two adjacent parcels cannot possibly see each other.

This is very lightweight, both for design/implementation and also operationally. It scales perfectly too, because only entry/exit by teleport triggers new privacy-related checking, and nothing else on the sim is ever involved.

Argent's clean design may need to be muddied slightly if the physics engine or other parts of SL code are found to misbehave at negative heights, but this should be quite simple to achieve because of the discontinuity and total isolation between basements and the regular world, as this separation makes height remapping safe. It truly is instancing.

3) OBJECT MARKING. [Morgaine Dinova]

The key aspect of the Object Marking idea is that there is no bounding box nor basement nor any other volumetric concept in the design or implementation.

Privacy is marked on download objects, either Owner Private or Group Private, and such objects simply do not get downloaded to a client if the client avatar's identity or active group does not match either of the relevant integer values. This makes it very lightweight operationally. However, it provides visual privacy only.

The marking of download objects is by inheritance from their parent prims and avatars (eg. a texture object being placed in the download queue is marked private if it is used by a prim that is private), so that from a user's perspective the control is by setting the privacy fields of root prims and avatars --- everything else obtains its privacy markings by inheritance from those.

There is no UI component to this proposal, since setting the privacy fields is done by an LSL command (possibly two, depending how avatars are handled). While this reduces LL's design/implementation workload hugely, it does mean that no effective privacy mechanism would exist for non-programmers until privacy control gadgets appear on the SL market. Of course, the first such gadget, trivially marking only yourself, specific prims, or every object you own in your vicinity, will appear within 2 minutes of the LSL commands becoming available.

The Object Marking scheme examines the list of current private owners and groups (not the list of marked objects) whenever the owner or a member of a privacy group enters or leaves the sim, in order to implement privacy retention policy. This is a low duty cycle activity with no significant server loading, and it scales well because no other parties or objects are involved.

This approach does share with the Inner Bounding Box method the issue of continuity with the public world and hence also the problem of corner cases, since the bounding boxes of prims and avatars are still downloaded to all clients. It may therefore be an advantage to extend the marking to the bounding boxes as well, and thus remove the private items from the publicly detectable world entirely.

==============================================

The above doesn't seek to explain the full details of these proposals (see the original articles for that).

What I've tried to do is to highlight the essential properties that make them quite distinct from each other, particularly at implementation level. All other proposals made so far have been founded on one of these three basic models.

Morg.

The biggest problem I have with your proposal is it's incapacity to scale, followed by the inability to upgrade to a better form of privacy while removing this one. After that, there is the inability to report griefing with "private" objects. It can't be selected (it's not downloaded) by the AR window (or anything else) while still obstructing movement or bogging the physics engine. Even if the objects are un-privacied automatically by the sim when their owner leaves, that cuases two problems: 1) the griefer just wouldn't leave and 2) the people who want privacy when they are around. Not to mention 2b) just because the conents of a house isn't downloaded doesn't stop someone from being inside the house, which is where most people get annoyed.

It scales perfectly, Draco18s: O(N) with group membership population, O(1) with marked object population, and independent of any other scalar parameter related to sim or resident population growth.

And like all privacy proposals so far, the fact that it culls objects from download to other clients creates a collosal gain for server and clients alike, even if just a single download is blocked. This makes questions of scalability somewhat moot since every scheme is almost guaranteed to be a win if it achieves a cull.

But Object Marking is not the model that would get my vote now anyway, I hope that's clear.

Of the three approaches, I support Parcel Basements as by far the most effective one, requiring the least development, enjoying a "natural" model that should appeal to most users (it's easy for people to identify with "basement", and having very little opportunity for corner cases.

The other issues which you mention stem from lack of isolation between public and private areas or objects. Argent's instancing eliminates that entire issue, which places it streets ahead.

Morg.

never mind what i said befor. i vote for parcel basements as it's the best proposal in both technical and social aspects.

I second that. This way those of us who never come out of our basements in RL can do so in SL

and now i will list all the ways in which parcel basements are better then other proposals

it is better then marked objects because people wouldn't have to huddle in their invisible houses living in fear of the thugs walking the streats with private cage guns.

it is better then private parcels because it wouldn't turn the main land in to a giant empty field of grass save the spining banner ads

it is better then private bonding boxes because people's houses wouldn't have a void space in the midle where scotty beamed up their sex room.

it is better then some magic elevation where everything is invisible just because, physics engine be damned!

more to follow...

No it isn't, as parcel basements will cause people to just move all their stuff in their basements, leaving little or nothing above.


3D Zones would at least allow the users to leave the outside of their home and only hide the interior, sure the inside of the house will appear empty, but it allows you to have a residential area where you can see all the houses etc, but the people inside get to remain private. You can have privacy without ruining the idea of a seamless environment.

I also still maintain that 3D zones wouldn't actually require a phenominal amount of dev time. Most of the actual stuff is already around in one form or another bar chat blocking and server-side object occlussion (not sending them), which aren't big things and are needed by any good privacy solution. Things like access controls already exist for parcels, and simply need to be done in exactly the same way but for a zone instead, can even use the same access list, though separate ones would be awesome.
The interface is a handful of options, an extra tab on the edit window or something.
If I was familiar with the code etc and it wasn't too badly laid out then I reckon the coding side could be done in a day or two. The biggest part is in testing to make sure it all works as expected and to fine-tune the UI to make sure it's as easy to use as possible so everyone can benefit.

and how exactly would parcel basements prevent people from having their house above ground and their dungeon below ground? it doesn't matter what proposal we settle on because paranoid people will just mark all of their stuff private so nun of them win in this regard.

That's what I've been saying!

Ah, you seem not to realize what makes people build pretty things ... it's to make an individual statement, and less overtly to have other people appreciate their artistry and originality. And of course as a focus for business. If it wasn't so, they'd build them and put them back into inventory.

While some of the more utilitarian devices might well be moved down to the basement, you can pretty much guarantee that any prized buildings and attractions will remain above ground. Hiding them would entirely defeat the purpose of display.

Morg.

You've left out ed44's proposal.

Even though he uses the term inner bb, his is still aligned with a parcel even though that parcel is carved out from the middle of a larger parcel. That makes it quite different

from https://jira.secondlife.com/browse/SVC-205
by Gigs Taggart


At least a concrete proposal that at least gets looked at by the Lindens.

Nope. If he uses anything other than the whole parcel area for privacy, then he's introducing an inner bounding volume. That makes his scheme conceptually identical to Haravikk's.

If you define an inner privacy zone then you can no longer use only the existing parcel entry/exit/containment detection mechanism. It's a black and white distinction from the point of view of implementation.

Morg.

That defines nothing but a bounding box in the sky. And because the private zone has physical continuity with the public world, it suffers all the same problematic scenarios as bounding boxes on the ground do, as highlighted by several contributers here.

I would call that a feature suggestion, not a design proposal, as it says nothing at all about implementation and doesn't examine any technical issues nor consider its development requirements.

Feature suggestions that don't detail how they would be implemented are the bane of SL. Things don't just happen by magic. In this case though, it's just another bounding box suggestion, differing in no important detail from those already proposed.

Morg.

But he is! Parcel sizes are multiples of 4 x 4 M blocks. If you have a 512 (16 x 32), then you can parcel off an independent 8 x 24 in the middle of it. Tha would utilise the existing parcel entry/exit/containment detection mechanism. You can sell it, or you can set different parcel properties to the surrounding areas. I frequently change my boundaries so I can set different parcel properties. Eg, I allow other residents to terraform parts of my land.

Because everything is invisible on the inner parcel, you need the outer parcel to control the access and stop residents from bumping into prims that are not displayed there. This is particularly important if the bb is on ground level and to minimise the social implications.

On the other hand, Gigs Taggart's proposal puts the bb way up above 650 m so he does not care if folk fly into his prims. Above 650 would be a designated hazard area all over sl.

Bot Gig's and Ed44's proposals require minimal physics changes.

The key here is to present the proposal in such a way as to catch the interest of a Linden developer. They generally don't read the forums, but some may read the jira to see what jobs are interesting enough to tackle next. The dev will put his/her own slant on the problem and come up with some solution that hopefully will make us all happy.

We can help by adding votes to these jira suggestions. If no-one votes for any privacy suggestions, then the Linden Devs will not think there is enough interest in privacy.

There is a general privacy jira entry that you may care to vote for:
https://jira.secondlife.com/browse/SVC-241

Thanks for mentioning it! A lot of good proposals (many perfectly fine for privacy needs) are linked to that 'meta proposal' (I think that's the hip new buzz-word for it =), but it only has 3 votes! =P