Discussion on the Script/MyAvatar Security


#1

So, continuing from the Friday conversation, and from @thoys reminding us that this can be abused. I will push this up for more visibility.

This Issue has been around for quite a while, but lets discuss it that it doesnt get forgotten again. It would be preferable that this is addressed before we bring more attention to our self through platforms such as steam.

To those uninitiated, the issue stems from the MyAvatar Object. Any Entity with a script on it can manipulate it, without any interaction required for the entity. Additionally we have no way of identifying who made the entity, or added the script to the entity.

This means anyone could technically make a mass orbiter without anyone being able to identify who caused it in the first place. This is basically a griefer’s paradise. Sure its been earlier discussed than intention is for the domain owners to control who places what, but completely making it impossible for anyone to rez anything even temporary should not be plausable, .

So lets make some suggestions on this thread on how to curb tail this, without going beyond of what could be possible:


###Here is my suggestion:

Tiers

There should be two tiers of scripts:

  • Authored Scripts / Trusted Scripts: Able to modify MyAvatar properties. Works like it does now.
  • Passive Scripts: Scripts which the user has loaded, but not necessarily interacted.
    They can access most MyAvatar properties, but cannot modify any of them.

Lets expand on this.

Authored Scripts

Authored Scripts are scripts that are loaded from Domain trusted sources. By default, atp source, hifi market (released scripts) are trusted. Meanwhile a custom domain / path are added by the domain owner’s discretion.

This could just a unmodifiable boolean value that the domain determines when it gives out the entity tree to the clients, depending if the scriptUrl matches a whitelist of the domain…

If this boolean value is true, any script running on that entity, can automatically have access to the MyAvatar object.

They can also use Script.load liberally.

Trusted Scripts

Trusted scripts would be scripts the user has interacted with: Specifically grabbed, or clicked on, but through no other means. When a user interacts with something, it should be enough of a “permission” for the object to have access to modify some of the users info, such as rotation, velocity, position. However as soon as the object is unequipped or the click is release, it no longer should have access to modifying the MyAvatar setting.

These however should not have Script.load access, without first asking the user to do so.

Passive Scripts

Passive scripts are scripts that arent trusted or authored by the domain. They work pretty much as they do now, however: They shouldnt be able to modify the MyAvatar object.


Thats my 2 cents.

CC: @Caitlyn


#2

Nice feedback Menithal. We really appreciate it!


#3

Great useful summary, thanks Menithal. Let’s see what we can do here. I think the simplest thing would be to start with a tier (‘trusted’) meaning, for now, that this is an entity script gotten from the marketplace. Let us think how to actually do that efficiently in the code.


#4

Additionally, it seems to make sense to not have another person’s client run an entity script attached to an avatar (and therefore able to be created regardless of rez rights). We will also make that change.


#5
  • What is the best way to report potential security issues related to scripting?

  • Will the proposed MyAvatar restrictions be enforced on scripts loaded from file:/// URLs?

  • Will End Users have an explicit way to override these restrictions? (ie: to bless certain script URLs as they see fit and separately from the Marketplace distinction?)


#6
  • Probably best way would be to message the fellows through their email addresses or through fogbugz.
  • My suggestion would include those in “authored” scripts as they are usually your own scripts and no one else can use them, similar to atp.
  • This is the reason I was mentioning the Authored/Trusted scripts. Domain owners can say what scripts clients can automatically trust, but clients them selves can have authority over that and can make their own whitelist methods. The entire issue is just to solve the Scripts that you wouldnt want to trust automatically to have access to the MyAvatar parameters.

#7

Does this mean, people cannot wear a plain as example. and go flying with that from one domain to another domain. while you still wear and run the script ?

Yeah a few catches that are problematic.

  • Script run in new domain.
  • Rezzing mabye.
  • Location you start with the plane in new domain.

I name the plane as example. because i only see a way to move that by teleporting. So possible soemthing that’s not easy possible.