WolfGang Senizen
In Brief
If a client side scripting solution is decided on, I would suggest either some form of official clientside script repository, or a way of scripts being signed to run clientside so that the script could be removed, or signature can be revoked incase of abuse.
The problem
There is a huge desire for products in sl to be able to load a script into the viewer for increased functionality. See this request
There is also a desire for the client side scripting to be very powerful. (For instance RLV like control of inventory may be an almost minimum level requirement desired for clientside scripting)
These 2 desires cause 2 main problems that this proposal could resolve to some degree.
  • Security
  • Shared Experience
Without a solution to this we could see a rejection of clientside scripts as they are regarded as unsafe and or unwieldly with further fragmentation of experience as users do or do not have certain scripts installed if there is no way for an LSL script to guranree a clientside script is loaded.
Security
For security we would need a very granular permission system, which will inevitably result in people either refusing them because they don't understand, or just clicking yes because they don't understand/care. Which are both bad outcomes....
This is also assuming that nobody finds some exploit to escape whatever sandboxing will be done on clientside scripts. And as scripts being signed/ in repo, can require them to be full and cleanly open source, some level of abuse can be prevented / inspected from the start.
A permission system would still be very desirable, but less critical and less of a problem if scripts that can run in a default setup are vetted somewhat in advance.
Shared Experience
For shared experience, we could end up rapidly devolving into "Script only works on X viewer because that's what I designed it for" kind of products.
With this solution an LSL script could prompt for a known good clientside script to be running/installed on the users viewer with user approval, and get expected functionality from it, Consistently across viewers as there would be little incentive for a TPV to break what is available to these scripts.
Propsed Solution Summary
A form of script signing, or official repository, managed by LL or some approved user group,
to be the only way remote code could be loaded
would solve most of those problems.
This would not prevent people from running custom clientside scripts, but allow LSL scripts to interact with "known good" clientside functionality provided by scripts.
I would also suggest to prevent people just telling others to "go download this zip and extract it here" that this signature/repository source, be enforced by default.
Thus lsl could run something like
llPromptForClientsideScript(<some_form_of_script_id>)
and get a response from the viewer once the script has either been loaded (installed and loaded or if it already running etc), or the user declined the script.
Problems I see with this proposed solution
This would require anyone wanting new functionality for a general sl audience to either get their script approved, or get their functionality added to an existing project that's in good standing. Though this could still be faster and easier than getting desired features included into current viewers.
To alleviate the above somewhat, I would suggest some form of "Good Standing" where once added, a source (be that a project or individual) can update their script with less manual oversight.
It adds some extra continuous workload to LL or whatever user group. is decided to be in control of approval.
Opinionated decisions will likely be a problem, with some features being deemed inappropriate by some and not by others.
Developers / Power Users
To allow for the creation of scripts and tinkering by power users, I would suggest the viewer needs to be launched with some sort of flag to disable the signature/repo requirement. With some clear warnings to less experienced users as to the risks this may entail.
April 5, 2024