Easier Scripted Updates - make llRemoteLoadScriptPin GLOBAL

Currently, the LSL function llRemoteLoadScriptPin only works in-sim, meaning that if you want to send a script from one prim to another using the function, you've got to have both objects in the same sim.

However, for those of us who create commercial products, in order for us to allow other people to update their software, we have to either 1.) Send them all a new copy every update or 2.) Have them come to our sim to update their stuff.

This could be avoided.

If llRemoteLoadScriptPin could be made to work grid-wide (as opposed to a single-sim) it would allow us scripters to let our customers (the most important people in the world) the simplicity of automatic updates.

For example, currently if anyone wants an update of my Movie Screen, they gotta send me the old screen and I send them the new one.

This is a hassle, but is the only way I can be sure people aren't just handing out my screen and getting free updates.

However, if llRemoteLoadScriptPin were global, I could simply have each screen query a centralized update server and it would automatically update each screen individually, thus removing the entire problem.

People wouldn't have to transfer anything, there'd be no delay in useability (no waiting while I send your TV back), and I wouldn't have to worry about whether or not my items are being stolen. This would allow for people to transfer ownership of my item without worrying about it not being updated.

SO, IN SUMMARY:

Make llRemoteLoadScriptPin a global function rather than only being in-sim. Life will be easier.

lllRemoteLoadScriptPin also only works if the object doing the updating is owned by the same person as the object being updated (thus the "updater disks" which some people distribute). And there's a good reason for that - otherwise, it would be too easy to infect other people's objects with scripts without their permission.

Kind of...

Yes, it would be possible to brute-force an update on someone, if you could brute-force the key.

But if the llRemoteLoadScriptPin function were to incur a delay of say 2 seconds, it would make brute forcing practically impossible.

Also, there could be a grey-goo fence imposed, checking to see how often a prim attempts a llRemoteLoadScriptPin and how often it tries different PINs.

Also, if a prim were to incur a grey-goo fence, the llRemoteLoadScriptPin would be frozen and inaccessible from any script inside the prim. (Grey-Goo Freeze)

A true updater wouldn't have to cycle pins much, and wouldn't need to update hundreds of times a second.

So adding a delay and a grey-goo freeze would make this viable.

There would still be quite a danger though. As soon as anyone happened to find the PIN for your objects, suddenly any griefer could cause anyone using your product, silently and without their knowledge, to run any script they wanted with their owner name and rights. Bear in mind that LL do not have a contract with scripters to make sure their remote load systems are secure (eg, they aren't using a PIN of 1), and not everyone can be guaranteed to be as security aware as you!

I created a Feature Proposal, here's the link:

http://secondlife.com/vote/vote.php?get_id=2549

And here's the text of the proposal, PLEASE VOTE FOR IT:

Currently, llRemoteLoadScriptPin only works when the server and client prims are in the same sim (and, I believe, when they're owned by the same person).

This needs to be changed.

llRemoteLoadScriptPin should be global and allow for the remote loading of scripts to anyone's prims - so long as the pin is correct.

This would allow scripters the ability to automatically update scripts they've created for their clients and customers.

For example, my video screens require updates occasionally. Rather than have my customers send me their old screen so I can send them the new one (to prevent theft), I could just have the screens update themselves and the problem would be solved.

I understand that the fear would be of a grey-goo attack, or of the brute-force replacement of other people's scripts.

This can be prevented with the following measures:

1.) Enable a grey-goo freeze which prevents any llRemoteLoadScriptPin calls when a grey-goo fence has been raised.
2.) Raise the grey-goo fence if llRemoteLoadScriptPin is called too frequently in a short amount of time (this would occur if someone were to try to brute-force someone else's pin)
3.) Enable a 2-second delay to llRemoteLoadScriptPin, causing anyone attempting a brute-force to have to wait impossibly long for it to ever work (this would make a brute-force practically impossible)
4.) Make it impossible for one person's llRemoteLoadScriptPin to replace a script created by someone else (so my scripts can only update my scripts, not someone else's)

The function already has the defenses of being unable to work unless the following two requirements are met:
1.) PINs must match
2.) PINs must exist


With these two restrictions, plus the ones I've suggested, it would be possible to make llRemoteLoadScriptPin a grid-wide function, allowing for us scripters to better serve our customers and clients with easier updates to their products, without enabling griefers to abuse the system and abuse the function in any way.

To make this work, you have to know the UUID of their screen anyway, so...

Why don't you give them a no-copy update object that fetches the UUID of their screen (say, from a webserver), does the update, and deletes itself?

state_entry()
{
  httpid = llHTTPRequest(my_url+"?"+((string)llgetOwner()), ...)
}

http_response(key id, integer status, list metadata, string body)
{
  if (id == httpid) 
  {
     integer p=llGetSubstringIndex("pin=",body);
     if(p == -1)
     {
       llBitchAtUser();
       llDie();
     }
     integer u=llgetSubstringIndex("uuid=",body);
     if(u == -1)
     {
       llBitchAtUser();
       llDie();
     }
       // The rest is an exercise left for the student
       // ...
       llRemoteLoadScriptPin(...);
     }
   }
}

That's a wonderful idea!

However...

Here's the problem.

1.) I need the update to be automatic, as little user interaction as possible.
2.) I don't want the user to steal the script.

If I were to send out a box containing an update, what would prevent the user from just taking the script from the box, putting it in their own prim, and then giving their screen to someone else? They'd be able to get free copies of my screen! For them and all their friends!

Now don't get me wrong, I definitely wanna share the love, and I don't mind people getting my affiliate vendor in order to get a 75% discount on their stuff...

But that would allow them to get free copies of my script.

BUT WAIT!!!

I discovered the solution.

The other day, I was sitting with my lover in the coffee shop, talking about politics, when suddenly out of the blue I figured out the solution, and it has absolutely nothing to do with coffee OR politics OR my lover.

She's my muse, I guess.

The solution is the following:

Check who created the object in which the script is running.

See, this means that I can have my scripts contact my update server automatically if they're out of date, and the server can send their owner an update cube. I can have my script be disabled while it's inside the cube, and then upon being loaded into the screen, voila it works.

And, if someone attempts to take the script out of the cube and put it in something else that WASN'T made by me, the script would delete itself and the object they put it in. (Harsh, eh?)

Since the script is no-copy, and since it'll delete itself and the object it contains as soon as someone tries to put it in an object I didn't create, this will prevent script-theft.

Simple!

So...

llGetCreator solves everything.

See, my previous idea was to get the UUID from the update-me email their object would send mine.

But that's completely unnecessary now.

The user still has to make sure the object is rezzed when the update happens, so having them rez the updater is not a big deal.
They can only steal the script if you give them a transferrable copy. Set it to "no transfer" and there's no problem. No need to have the script check the object creator or anything else, SL will prevent them from giving it away.

Sorry, i vote no. SL is free market. So, rent engineers to design an internetworking architecture. Linden Lab has not to do it for free.

When I first read your proposal I thought what a stupid ideal and an invitation to grievers. But I see the necessity in your case of having items transferable so you just can't send out the update, but the solution would be an 'update' button on your product that sends a request to a server with IM and/or email as backup and it then self destructs by either deleting itself or deleting all the internal scripts. No need to make SL more complicated as it is.

This isn't possible; the engineers have no parts to build it out of.

I still don't understand why he doesn't just hand out *no-transfer* copies if he doesn't want people to *transfer* them.