Proposal: Permissions revocability system with reduced management overhead

[Jenna Felton]

Hello

Well, this post will quite long so i better split it in a few. Also i am not sure where to post ths proposal, as it affects the SL infrastructure, hence the servers, but also the viewer. Choosen the SL Servers category, as this part is more affected.

The current system of run-time script permissions is (apparently) build of a bitfield storing locally into a script giving the run-time permissions granted to the script (if not, the suggestion will be probably not obsolete, but the suggested components would need a maping to the implemented.)

However, this solution is very efficient on run-time since to perform an action, the script has simply to read in the locally saved permissions bitfield if a permission to run this action is granted to the script or not. But this solution makes it hard to give a resident a way to revoke permission given to a script at least if the script is temporally not available, e.g. taken into inventory or if the script owner gone offline.

 

1. The challenge

The problems we are facing if making the run-time script permissions revocable:

 

• To make script run-time permissions revocable instantly, you have to store the granted permissions in a place not bound to the script, so you can revoke the script permissions even if the script is not available at time.
• The permission storage must be also available if the avatar granted the permission is not available, so the script is able to check if it is allowed to access to the money of the avatar for instance.
• By outsourcing the permissions out of the script, we create a traffic between the script and the permission storage every time an action, say animation of the avatar has to be started, and this is very often the case.
• The data volume of the permission storage will be extremely high, as every avatar could have granted a quite large amount of animation permissions (sitting on furniture, vehicles, and kiss&hug huds produce such a grant.)

This proposal gives a possible way to allow an instant revocability of run-time script permissions with less management overhead and data load.

 

2. Abstract overwiew


The permissions revokability system is roughly based on few things

• A permission item is an unique object holding permissions granted to the script. The permission item is stored in place of the permissions bitfield and represent the runtime permissions held by the script.
• A status storage maintains the status of the permission items and thus the run-time permissions granted to the script related to this item. The status tells if the permission is granted or revoked.
• A status interface is a floater in the viewer, with a direct access to the status storage. The floater allows to identify and revoke every permission the user ever grated to scripts, regardless if the scripts are available or not.
• The sync protocol between scripts and the status storage allows to revoke run-time permissions at the point the script to revoke permissions becomes available. The protocol uses ...
• ... the revocation event sent by the status storage towards the script (holding the permission item) with an effect of revoking permissions given to the script.
• The revocation message is again sent by the script (or possibly the status storage) to an agent affected by revoking the script permission. 

 

[Jenna Felton]

3. Permission item


In order we can revoke a given permission, we have to clearly identify it. This identification goes deeper than per object and per script: An object can hold different permissions via scripts inside, as well every copy of the same script (with same UUID) can hold another permission.

To do so, we bind permissions given to a script (a bitfield of permissions to be exactly) to a permission item. This item will have an unique UUID and store the bound permissions bitfield.

The permission item is only generated by the script as soon the requested permissions are granted. There is no other way to create the permission item.  Declined request will not generate the item. Also, not every accepted permissions request will generate a permission item, and in some cases even an already created item can be reused, 'recycled' so to say. In some cases the permission is given temporary resulting in a short-living permission item managed very locally.

As soon generated, the permission item will be stored into the script and the status storage(s). Now the script has an efficient way to check what permissions it hold, and the user granted the permission has a way to revoke it by changing the status of the permission item.

For implementation reasons you can divide the permissions and actions allowed by them in two classes:

• The avatar actions are actions affecting the avatar, the avatar permissions are TAKE_CONTROLS, TRIGGER_ANIMATION, ATTACH, TRACK_CAMERA, CONTROL_CAMERA and TELEPORT.
• The property actions are actions affecting the user’s property and are allowed by property permissions DEBIT and CHANGE_LINKS.

The avatar actions require the affected avatar to be available (online and on the sim) while the property actions do not require the avatar granted the permission (i.e. the script owner) to be available or even online.
 

4. Recycling of the permission items


A disadvantage of permission items is that they generate an UUID which is to be managed by the whole SL infrastructure. Generating an item for every granted or auto-granted permission request will create a new permission item and waste resources even if used temporally. The recycling technique avoids this by reusing already created permission items.

Generally said, if we have to create a permission item and we have already another permission item created for the same parameters (avatar granted permissions and the permission bitfield) so we would not tell the new item from the existing one, we reuse the existing permissions item instead of creating the new. Here are a few examples how we do this:

a) Copying of the script with granted permissions

If a script grants a permission, say to animate an avatar, and then copied by copying the holding object, every copy of the script holds a copy of the permission item, i.e. every copy of the permission item will have the same UUID and bind the same permissions.

This is similar to traditional definition: If a script holding run-time permission is copied by copying the holding object, every copy of the script will hold the same permissions.

The difference is now, that by revoking the (animation) permission of one object will revoke the permission for every copy of that object, since all copies share the same permission item. This is a new behavior, but since the revocation system is new, the existing content is not corrupted at this point.

b) Repeatedly requested permissions

If a script holding some run-time permissions, requests permissions again, the already created permission item may be re-used, if all this are true:

• The requested permissions are granted, 
• The avatar being requested and having granted the permissions is the same of the existing permission item,
• The requested permissions are the same of the permissions bound to existing permission item.

This way a script (for instance animation machines or poseballs) requesting the permissions repeatedly without checking if the permissions are already granted eventually, will not produce a bunch of permission items while only one of them is sufficient.

c) Permission cache

If a script holding the permission item has to remove it or to generate another one, say because

• The avatar granted the permission to actual permission item but declined the new request,
• Or because other permissions were requested and granted (but the avatar is the same)
• Or because another avatar was requested and accepted the permissions.

Than the actual permision item is not removed but stored in a limited cache (for example of 64 items.)

As soon an avatar is requested permissions and the new permission item to create would exactly match (avatar and permission bitfield is the same) the item in the cache, than the item from the permission cache is restored instead of creating a new item.  

This way for example a multiuser animation script would not produce a lot of permission items because a group of avatars use it sequentially.

[Jenna Felton]

5. Status storage


Status storage is an instance keeping states of permission items. The storage allows to manage the script permissions without access to the script, so script permissions can be revoked even if the script is not available.

The status storage must be instanced in an appropriate place, for example kept by the user agent if the avatar permission is handled, or the sim agent if the property permission is handled.

The connection between the script and status storage must be fast and short, as well the connection between the status storage and the status interface (of the viewer.)
 
The status storage binds more data to the permission item than the script created and stored the item: The permission item on the storage side holds also the UUID of the holding script, object, and the object's owner, as well also the region where the permissions were granted to the script.

I can imagine a few scenarios where to hold the status storage.

a) Global status storage

The simplest variant uses a global server holding all permission states. The scripts and viewers can find it easily, but we have a tight bottleneck here, even if we synchronize status due initialization of the script only and not in real-time, all scripts access the same place. Also the way is far for the data between viewer and status server and between the status server and the script VM.

b) Outsourcing avatar permissions

Because avatar actions make no sense without target avatar being available on the sim, we can separate the permissions in two parts:

• The pure avatar permissions, e.g. TRIGGER_ANIMATION|TELEPORT, will be handled by status storage attached to the user agent of the target avatar.
• The pure property permissions, like DEBIT, and mixed permissions like TRIGGER_ANIMATION|CHANGE_LINKS will be handled by the global status storage server.

In this case, the permission item in the script may need the reference to what status storage is handling it's permission status.

This way the viewer would always able to access the status storages, either the one attached to the user agent (pure avatar permission) or the global status storage. A teleporter device will synchronize the permission status as soon the avatar becomes available on the sim, and hence teleport-able. A vendor or device working on linksets will load the permission status from the global server accessible instantly.

The bottleneck is relieved, but not eliminated: The property permissions will need access to global status server and this may generate huge traffic on a single point, even if the hits are only generated while rezzing an object with script requesting the status.

c) Outsourcing all permissions

Here we eliminate also the global status storage:

• The pure avatar permissions, e.g. TRIGGER_ANIMATION|TELEPORT, will be handled by status storage attached to the user agent of the target avatar.
• The pure property permissions, like DEBIT, and mixed permissions like TRIGGER_ANIMATION|CHANGE_LINKS will be handled by the status storage attached to the sim agent of the sim where the script was rezzed last time.

To implement this the permission item in the script should definitely keep track about what status storage handles the permission status. If the script holding property or mixed permissions is moved to another sim, the status storages of the sim agents will have to move the status information, too.

This way we eliminate the bottleneck: The scripts access the right status storage easily and on a short way, also the status interface in the viewer will have access to all (pure) avatar permissions granted before, as they are handled by the status storage sticked to the user agent.

Access to the mixed and pure property permissions is only possible for objects on the sim the avatar is currently, which is insufficient. Imagine a bugged device requested and granted the CHANGE_LINKS|TELEPORT permission. As it is mixed, you would not be able to revoke the permission without return to the sim, and once there the device would send you out on sight.

To enlarge the range for mixed and property permissions, the viewer could store references to status storages of, say, 16 last sim agents. This way you can access and change states of script permissions remotely, without needing to visit the target sim.

Also connected regions like in a continent or estate could connect the status storages of each sim, than you can teleport to a sim in the continent and manage the status of permissions granted to an object everywhere on this continent.

d) Splitting mixed permissions

If the states for avatar and property permissions are handled by different storages, as suggested above, it may make sense to split mixed permissions into avatar and property permissions. The permission item in the script refers than both storage servers, one for avatar permissions and one for property permissions. Both storage servers may synchronize the permission states if needed and possible.

This way the viewer has a direct access to the status storage for avatar properties (it is sticked to the user agent), and the scripts an access to the status storage for property permissions (sticked to the sim agent), even if the user agent is not available. This way a device can not take the avatar permission like animation or teleport out of reach from the viewer just by making the permission mixed.


6. States of permission items


On the script side, a permission item has two states: Either it exists, the script is holding a permission item (actively, not in cache,) than the script is granted permissions bound to the item, or the permission item doesn't exist (or it is just cached but not held actively), than the script is not granted any permissions.

For the status storage, the permission item has three states: Granted, revoked and unconfirmed.

a) Granted permission state.

In this state is a permission item if saved into the status storage if the script has generated the item (the user accepted requested permission.) Say a script working in a kiss hud requested the animation permission which was granted. The script generated the permission item (if recycling was not possible) and it was stored inside the script and the user's status storage.

b) Revoked permission state.

In this state a permission item is in the status storage, when the user decided to revoke the script’s run-time permission. Say the owner of the kiss hud decides to grief the user by starting of nasty animations. Traditionally, the user has no other way to stop that but fill the abuse report.

Now, the user opens the status interface which connects to the status storage. There, the user finds the hud animating them and changes the state of the permission from granted to revoked. The sync protocol ensures that the animation script into the kiss hud is notified as soon as possible and looses the animation permission.

c) Unconfirmed permission state.

It is possible, that the status storage saves not every permission item:

• Permissions granted before the revocation system is established, will generate new permission items by first script action but those permission items will be not in the status storage,
• Status storage may remove items that are not used for long time, unter assumption the objects holding the scripts are temporally or removed meanwhile,
• The user may remove obsolete permission items to keep the list clean.

If a script executes an action due holding permission item allowing the action, but the permission item is not in the permission storage, this item is saved into the permission storage but with unconfirmed state.

The user receives a message, that a script is executing an action which was allowed before but this action is not confirmed. The message may be shown by a floater, which is fading out after a while. The user is now able to...

• To accept the action, than the permission item changes the state to granted.
• To decline the action, than the permission item becomes the revoked state and the revocation event is sent.
• Or to ignore the floater allowing the action to continue. At later point the user can find the new permission item in the status storage interface and change the permission state correctly.

d) Temporally granted permissions

Sat unowned objects may give the permissions TAKE_CONTROLS, TRIGGER_ANIMATION, TRACK_CAMERA and CONTROL_CAMERA automatically to the sitting agent. This permissions are given temporary, after standing up they are lifted.

Hence the permission items generated temporally for the sitting period must not be stored into the stats storage and managed by the status interface for instance. The same applies to other possible cases where permissions are granted temporally to scripts.

[Jenna Felton]

7. Sync protocol


Via status interface, the user can change status of every permission item holding permissions granted to a script before. The sync protocol ensures that the status storage provides the new status of a permission item to the script as soon as possible.

The protocol avoids generating too much traffic; it uses only asynchronous events that are sent on demand.

a) If the script is available while the permission status is changed via status interface, an event is sent to the script immediately.

If the new state is 'revoked' and the old state was 'granted' or 'unconfirmed' (which both means the script is granted permissions) than a revocation event is sent to the script. The script looses the permissions by receiving the event.

If the new state is 'granted' or 'unconfirmed' and the old state was 'revoked' (which means the script had no permissions granted) than a regranting event is sent, due this the script stores the permission item holding the permissions bitfield.  

b) If the script was not available at time of changing permission status, than only the new status is saved in the status storage.

c) As soon the script and the status storage become available to each other, for example while the script is in an attachment and the script owner is logging on, than the script connects to the status storage and requests status for the held permission item.

If the status is 'revoked', a revocation event is sent to the script with the same effect of script loosing the held permissions.

d) If a script recycles a permission item from the cache, the script sends a status request to the status storage and names the UUID of the recycled permission item. If its status is 'revoked', the status storage also sends a revocation event to the script.


8. Revocation messages


If a script was revoked a permission, this may also affect another person than the agent revoked the previously given permission. In this case an instant message should be sent to the affected agent.

a) If a script given say an avatar permission (e.g. animation permission) by an agent who is not owner of the script, and the agent revoked this permission, the owner of the script should be informed that the avatar actions are no more possible.

b) If the CHANGE_LINKS property permission was revoked, there is no affected avatar, so no messages must be sent.

c) If the DEBIT property permission was revoked, this can broke content potentially, because the debit action is used often to split money or to implement affiliate vending systems. Revoking this permission can create fraud affiliate vendors if the script relies on non-revocability of the DEBIT permission.

In this case, as soon a script tries to give money and the debit permission was revoked, the recipient of the money should receive an instant message telling the money transfer was aborted because of missing permission. This way the creator could ban the fraud affiliate from the vending network for instance.

[Jenna Felton]

9. Status interface


a) Permission confirmation floater (temporary)

If a script connects to the status storage, due the sync protocol, and the storage is missing the status for the script runtime permissions, a floater is prompted that is similar to the permission request but is 1) telling what permission the script has already, and 2) allows to confirm the permissions or revoke them.

In the shown example we rezzed a dance machine, which has already the animation permission, but the status for the permission is missing in the status storage. Now we can confirm the permission, revoke it, mute the device as usual. Because there will be many such floaters, we can here check the check box and the decision taken now will be auto-applied to all following confirmation requests.

The floater is temporary, it is fading out because there will be probably a quite number of such confirmations, especially if we cleaned out the status storage. The floater toast could collect the floaters and display the number of floaters not confirmed yet, so we can reopen the floaters at later point.

b) Run-time permissions floater

Here is the legend of the icons and also the view to open lists:

This floater demonstrates the interface to the status storage or storages. The floater presents a list of permissions granted to objects, i.e. the scripts inside. Each script requested permanent permissions produces an entry for an object, as it produces a permission item which is registered by a status storage.

The entries can be filtered by the name of the object and it's owner, as well by the granted permissions and their status. The displayed legend presents the filters and explains the used symbols.

Entries passed the filters are displayed page wise, since 3218 permission entries is not a unrealistic number, even if not every permission request produces an entry.
                
The list dislays the objects requested and granted run-time permissions, with

• Object name and name of the object owner,
• The region where the object requested the permissions. Revealing the current position of foreign object would be a privacy flaw, so for unowned inworld objects the position should be hidden. Attachments have no current position,
• The permissions holding by the object are shown by icons, if a script holds more than one permission, the entry for the script displays multiple icons.
• The status icon is clickable, if clicked a floater is shown with a possibility to set the permission status, i.e. revoke or re-grant the permissions.
• The last column 'last used' displays when the script into the object used the given permission and what permission was used.

If one object is selected and the entry shows the object position, we can teleport there by clicking a button. If at least one object is selected we can delete the selected entries (not the objects) or change the permission status for them.

The 'last used' column is a very nice to have feature, but perhaps not so easy to implement. It may require a permanent data stream from the script to the status storage. In return this allows to identify a griefer who used a script permission given to the griefer's gadget months ago.

The list displays some teleporting devices (TP Relay, Pingpong Teleporter, Personal Teleporter), animation devices (Dance Machine, Hug&Kiss attachments), a radar working on links, two vendors with access to the avatar's money, and a RC device holding a permissions set.

You can see, the dance machine still has unconfirmed animation permission, the permission floater was just ignored. You can also see how a grief was defeated: The Pingpong Teleporter gained the teleport permission but after we broke out of the grief, we just open the floater and revoke the teleporter the TP permission. At same point or earlier we revoked also the animation permission to the strange named ring device belonging the same griefer.

Here we are at the end of the proposal. I put it on discussion so we can find out if this idea can be implemented and must be implemented at all.

LG,

Jenna

[Darien Caldwell]

I'm not sure I see why having runtime permissions non-revokable is a problem.  The fact is 'unrevokable' isn't even accurate.

Permissions can already be revoked through reset of the script, copying the prim or script (copies do *not* retain permissions), or even from script memory rollback (admittedly a bug, but still valid). There are also many viewers that allow for revoking of permissions as well.

I think just reading this proposal shows a case of the 'cure' being worse than the 'illness'.

[Jenna Felton]

Yes Darien, and thanks for replay.

Yes, the script looses permissions if copied out of inworld object and if copied with object copied inworld. But it retains permissions if the object is taken into inventory and copied there.  And i am pretty unhappy with the fact that once granted permisions can not be taken back, unless the owner of the object holding the script makes some mistake like resetting the script.

The owner of the object gained avatar permissions can use the permissions in another means than the grant was intended to, and the victim can do nothing about it, or at leas i not know any way to, say revoke animation permission given to a griefing object pretended to be a hug attachment . However, i may be wrong.

I see there is a message for revoking permissions if the script is on the sim, as far i can understand the definition. Edit: To be honest, i can't figure out how this message works and even it this message is sent when you decline a permission request, or really to revoke a permission granted once. My indirect informations state, this message is sent to revoke permission granted to a script available on the sim but not to a script in an attachment.If so, returning to the sim to revoke teleport permission seems not a good idea for me, since the griefing teleporter may send you out on sight before you take it the ability to do so.

I've also not found a button allowing revoking permisions in Firestorm viewer. The only place dealing with permissions i found is Privacy tab in Firestorm settings. Permissions being revoked this are just two, animation and taking control, as far i can read on the help page.

Especialy for dangerous permissions like debit or teleport this is an issue.But also animation permissions can be used for grief. This proopsal was a try to give a possible answer to the issue. I tried to keep the overhead low, so a permanent traffic for every script action is not a good idea. This made the complete design very complex.

[Wacoede Unplugged]

ok nearly a year late to the party but i really do think we need this system in SL now people are now abusing this loophole via a hud that is not releasing animation permissions

one object i've become aware of is something called the Sparx Animator Hud so do we have any hope of seeing this?