Securing Remote Updates

Does anyone have any tips on how to make automatic remote object updates secure?

The problem is that if automatic script updates are offered on an object thats NC/YT, then some extremely irritating people will realise that they can request an auto update, not allow it to start, and then rip the scripts out of the updater box to create a free copy of the object. Or rip the scripts out of the original object then let the updater box put new copies in. Or, or, or...

Is there any canonical solution to this? I'm told there is a library for it somebody wrote but I haven't seen it around..

Yumi,

You could use a common encryption routine in both the receiving prim and the sending prim. The encryption routine could be based on something that changes so that they could compare a key or encrypted messages.
I use this in a product and the two prims communicate via llWhisper.
They share an ever-changing key, then the sender validates it and also has the prim's UUID via the listen event so it sends the inventory.
If you make the inventory NO MOD/NO COPY there isn't really any way to rip anything off.
Let me know if you need sample code or something.

What I'm talking about is the occasion where somebody can:

1 - Get an transfer-ok item that gives remote updates
2 - Walk up to the remote update machine, request an update, and get an update box
3 - Rez the update box somewhere where the update can't run and copy the scripts out of it
4 - Put the scripts into another object and transfer/sell it as an equivalent of the original scripted object
5 - Since their "real" item was never updated, it's still out of date, so go back to the update machine and get another updater box, go back to step 3

Secure communication isn't much of a worry.

The current solution I've come up with is to drop a "License Key" object in the inventory of the updatable item. The update box doesn't include the license key, and the script will fail if it doesn't see one in inventory. Since the update box can only test the name and creator of the object, it would be possible for someone to "fake" one by taking a modify-ok object I made somewhere and renaming it; so I created a holding account (named Licensing Widget ) to make the license keys, to be sure that that account will never create a modify-ok object that someone could rename. On the other hand, if they want to move the scripts to another object (to get a better build perhaps), then they can, by moving the license key too. Does this seem strong to folks?

Depending on your expected sales volume, you could also have the update server keep track of people it's handed out updates to. If you restrict people to getting at most one update a day, or a week, that might be enough to make any large-scale piracy pointless.

Can you test the creator of an object that's in an object's inventory? I didn't know you could do that.

I'll be running into a similar situation soon with one of my projects, and ever since you started this thread, I've been thinking about what I should do for this.

Your license file would work.
I have seen it on other SL projects and it is not overkill at all.

As for moving the license, I would make it NO COPY.
Each product only gets one license.
If you make a new build...call it an upgrade.
When you create a new line of a product they have to purchase it.
Updating scripts are one thing. Updating builds...well, you might as well just sell it as a new product.

That's just my opinion though.

BTW:
If you want to update prims as well, I have a solution for that.
The main build is stored and sold inside of a rezzing prim like a control panel.
When the customer runs the updater it can replace scripts as well as prims. That
way they can always have the latest updates to the design.