[sldev] Viewer-side scripting and 3rd-Party Viewer Policy?

Rob Nelson nexisentertainment at gmail.com
Thu Jan 14 12:54:01 PST 2010


Hello sldev.

I realize that I've asked this in IRC already, but the only answer I got
was from a non-Linden and I want to hear it from the horse's mouth
before continuing on my current path of feature additions.

I'm working on a viewer that will be adding viewer-side embedded
scripting (Lua, if anyone is curious, see http://lua.org) in order to
allow content creators to extend the abilities of the content they
create.  However, during development, a beta tester brought up a few
potential issues with the ToS and 3rd Party Viewer Policy (henceforth
known as the 3PVP).

The Lua implementation I'm adding is highly event-driven, so whenever,
for example, a sound is played in the sim, the following event is
triggered with the corresponding arguments:

	OnAttachedSound (object_id,audio_uuid,owner_id,gain,flags)

Notice that the UUID of the sound is passed to the Lua script hooking
into the event.  This is so I can, for example, produce an automatic
mute function by checking the UUID of the sound being played against a
list of known-bad sound UUIDs.

	if isInTable(gAutoMuteSounds,audio_uuid) then
		muteAvatar(owner_id)

However, it doesn't take any stretch of the mind to see how a user could
abuse this system by simply printing or logging the sound UUIDs.
Similar issues exist with particles and object textures.

What I would like to know from any LL employee willing to answer is:

1.  If I provide a reasonable level of permissions checking and
anti-content theft functions, and discourage such ToS/3PVP-breakage (and
moderate user-posted scripts in accordance with such policies), will the
viewer I am working on still violate the 3PVP/ToS for simply making
those UUIDs available to user scripts?

2.  What minimum restrictions must I apply to comply with LL policies?
Keep in mind that I cannot check Attached Soundsystems since the
permissions to that sound are not made available.  There will also be no
llGiveMoney-type function, nor will the messaging system be made
available to allow a workaround.  Login-related events will not be made
in order to prevent password theft. Alienating or exposing users is not
my intent, only to give them the ability to bend their viewer to their
will.

3.  What sort of policies would LL like to apply to viewer-side scripts
and their creators?  What should I have my users and content creators
read, aside from the SL ToS, community standards, and 3PVP?

The most ideal regulation structure for me and my users and developers
would be similar to the Digital Millenium Copyright Act safe-harbour
provision:  As long as the development and moderation staff make a
reasonable effort to mitigate content theft and content distribution in
accordance with SL rules and regulations, and add in
permissions-checking where necessary, the viewer itself would meet 3PVP
standards and would not be banned from SL.  LL would define what a
"reasonable effort" is, and I would have to conform to that definition
or risk losing safe-harbor status.

I appreciate your consideration of this matter.  As I've said, I do not
wish to break too many eggs here, just give my users the ability to do
what they like with their viewer while still conforming to SL's
regulations and LL's wishes.

Fred Rookstown
FlexLife Lead Developer



More information about the SLDev mailing list