Permission settings edit and entity list


#1

Greetings many do not know me or if they were in Second Life they knew me by a character name of xstorm Radek .
Examining a number of the domains and virtual world that is now in highfidelity it became apparent that a number of people did not understand the permission system or understanding locked items.
Hopefully everyone has backups of their virtual world.
And just because you make it so the world can not be edited this does not mean unlock items cannot be deleted.
For all a malicious user has to do is going to entity list through edit and find non locked items on the list.
Even without it being disabled these non-life items through the edit list can be deleted.
Causing the owner of said items to have lost hours of work if not weeks.
So hopefully in time everyone will be having their items locked in place.
Plus non locked items can have Scripts that can attack them.
Never underestimate a malicious user.
Hopefully in time when the edit command is disabled it too will disable the entity list in the edit menu.
Thank you for your time.
Sincerely bill windwalker


#2

For those wondering why this has been done like this:

Everything you move with the hand controllers or interact with is via scripts that drive the entity to do a specific action, you are basically “editing” the object on the fly.

Locking on object, makes it so that anyone without permissions will not be able to move the object around nor delete it via interactions.


#3

Is this not another thing that is being left to the people developing systems that will use the hifi platform, rather than being provided by hifi?


#4

This merely shows how inadequate the permissions grouping was designed. It shouldn’t be an all or nothing affair in the first place. The ability to grab objects/entities, toss them, kick them, run into them, rotate them is not editing. I cannot edit a real rock but I can kick, move, rotate them, etc.

What is a problem is that recent ability to resize things on the fly. That’s very nice but there was no property to let owners permit or deny that capability hence the entire object has to be editable which includes deletable. That’s a plainly huge mistake. It is fixable. If new capabilities are to be added, there must be consideration given and properties created to permit owners to permit or deny the capabilities. It is quite improper to subsume everything under the ‘editable’ group property especially when that group property also permits deletion. This is another one of those isssues that should be brought up an internal devs meeting.

[x] grabbable
[x] movable
[x] resizable

cc: @Caitlyn


#5

This is editing:


#6

This is an example of grabbing, moving, tossing, and also editing another object:


#7

I see it not only as edit problem. i know at some point you get things you want to interact with. Like switches.

Problem right now, how do you get a reliable user list ? one that always return the same uuid. If you not have the same uuid everytime how do you ever create access list for entities so only some people can control that entity ?

I do not see a reliable function right now. And we need really the option to create access lists for entities in the script you write. If there ideas i like to hear it, but for now it sounds impossible. It’s a bit the same problem @menithal have with inventory system. You get stuck on the same user identify problem.


#8

First, it is very clear gaining access to an avatar’s immutable ID, even an opaque ID, will never happen. @Philip has been very clear about that. So, forget it.

What is really bad about that is that even in the real world it is possible to identify people by their biometrics (their fingerprint, their iris scan, their facial/body composite look) and that will not be possible in HF. So, with that need never to be met in HF, making access lists in HF will have to be done old school as in done also old school in RL: keys and codes. Yes, you will have to make access tokens. Actual token entities that an avatar has to go buy from you and then wear. Then you add the token ID to you lists and your scripts can query that token for its ID. And as in RL, if the key is duplicated (although this can be mitigated) or given to someone else, oh well!


#9

I just got a bright moment, after you wrote old school . :bulb:
SO it means we need to create passwords users need to enter (not sure how right now, hud mabye) before the can access a control panel. Sounds like that is the only way for soem things.

ADD: No hud cannot work, because there’s no link with the entities that need to know the user. Hmmm.

ADD:
Other option mabye could be to use the LIST function you can buy. And we can link a list to entity. not a cheap solution. But mabye one that works.