Securing "transfer proxies"

By a "transfer proxy" I mean a no-copy yes-transfer object that's used as a delivery agent for a yes-copy no-transfer object. You buy the proxy, then give it to someone as a gift or similar if you want to; then to get the actual product you rez or click on the proxy, and you get the no-transfer object sent to you by a server elsewhere. Several scripted items I've seen use these.

I'd like to make some of these for my products, and I already have a server set up that could do the delivery - the problem is, I'm having a nightmare trying to secure them (I'm having to be a bit ambiguous here to avoid giving information to hackers):

* It's necessary to validate that the scripts are in the right object, which usually means creating the object with an alt.
* The e-mail can't be sent by the main script because it will have to sleep for 20 seconds afterwards and can be attacked in that time.
* If a secondary sender script is used the communication with it can be attacked.
* If the object is rezzed in a laggy area it can be attacked while it is lagging after the delivery is requested.
* If the object is rezzed at the border of a no-script parcel it can be quickly moved into the no-script parcel after the delivery is requested.

Has anyone managed to make one of these that's properly secured at all?

I'm assuming that the transfer proxy deletes itself after calling home. However, as you point out, there's that 20 second email delay. I think you're already thinking along these lines, but if you can manage to convince one of these proxies to send a request and then yank the script out of it into your inventory, then you can put it into a new object and get another copy of the product. Using a secondary script to avoid the 20 second delay just opens you up to someone sniffing for link messages.

I'm not really sure that there's any "secure" solution to this, to be honest.

States are your pal here.

On rez it's in the "wait for activation" state. This state is not the default state, I'll explain why later. The lucky gift reciever clicks or says passphrase or whatever activation you care to use (including the rez itself).

On activation it switches to delivery state. It does all the prep work and says whatever you care to have it say first, then delivers the e-mail to the serving object, with llDie() coming right after.

In this delivery state, the on-rez event contains only an llDie(). This makes the no-script land/take back into inventory problem pretty much moot. It does leave dragging the script into inventory and plonking it into another object, so:

To get the final bit of security in, the default state of the script looks for your or your authorised av (alt, whatever) via a sensor. If your av isn't there to help prove it's you inserting the script into an object, it just llDie()s. If you are there, it switches to the wait for activation state. You can and protably should add that it needs to happen in a certain sim near a certain location and maybe even require you to speak a passphrase, thought it gets to be a gargantuan P.I.T.A. at that point.

That just leaves securing the serving object against being e-mailed - MD5 signatures and passphrases will help here.

Hope this helps! =^.^=

An alternative method that may be better (avoiding the script delay problem and also tightening up your control over the environment) is a "gift certificate" that must be "redeemed" at a particular location - and using signed chats (way off in some negative-number chat channel) authenticates itself and requests delivery by way of a redemption prim. Same basic security as above, sans the worry of that delay.

What about having the no-mod/no copy script (which cannot be reset) store the key of whoever redeems it before emailing? Since the product is a copiable item, they can request as many as they want after that, and anyone else they give it to will be unable to reset the script to get more.

This is way too much work for something that can be done without scripts.

Rez object A, set permissions to copy/no transfer, pickup object.
Rez new object B, put copy/no transfer object A in contents, pickup object B.
Right click object B in inventory, go to properties, set properties to no copy/transfer.
Give object B to a friend, note that it shows up in their inventory as no copy/transfer.
Have friend pass object to several other friends, note they can all pass it along.
Have final friend rez object B and remove a copy of object A to their inventory, then pick up object B.
Note in inventory object A is copy/no transfer, and object B has suddenly become no copy/no transfer.
Final friend is no longer able to pass along object A or object B.

This is a feature of the permissions system, no scripting required.

I have heard of this, but I've tried it and not gotten it to work. It sounds too much like a glitch that might be fixed at some point to really want to depend on it, although I know some things (like Tringo) use it..

Permissions have to be set on the containing object in inventory, not in world.

Or the default state checks the creator and owner of the current object. That should protect against someone else resetting it or dropping it into another object. Unless they get your alt's password

or have a moddable prim you made, from a freebie for example.

Combinations work best

That would fool a creator check, but not an owner check... oh, I see, unless it was set to "Anyone can modify". Never mind

As it works right this moment. It hasn't worked this way in the past, and there's no guarantee that it will stay this way in the future.

So, yes, while it is a way to do it without scripting, *I* would recommend doing it with scripting, to be a good bit safer in case this changes at some point. A scripted solution is much more dependable in the long term design aspect than depending on the permissions system, which gets broken and "fixed" a lot.