Script Authentication System

This should be a simple proposal and one that should not be difficult at all to implement.

Suggestion
Allow any user to see the unique hash (MD5, for example) of any script, whether they own the script or not.

Reasoning
There are currently some questions of trust among certain vendors who market machines that charge and pay money. For example, slot machine creators are often accused of dishonesty and backdoor programming due to the opaque nature of their scripting. This would allow a trusted third party to verify this system, as in the following example:

Adolf writes a slot machine. The trusted third party, in this case Barney, steps forward and Adolf shows him the LSL script code. Barney verifies the code to ensure that no backdoors exist in the scripts and takes an MD5 hash of the script that Adolf gave him. This MD5 hash is then publicized to a website. When Chris wants to buy Adolf's slot machine, he compares the MD5 hash published by Barney to the script on the slot machine. If they match, gravy. If not, there's a problem.

This should be extremely trivial to implement and would be an absolute godsend for end users.

Thanks for your time,

Ed, tpb Shane

That's actually a really good idea. Not only would it prevent fraudulent scripts being "switched out" by vendors, but also can help people determine if their object somehow got modified without their knowledge.

If it was accessible via script, then it might also be useful for "validation" scripts, which verify the script contents of an object.

If you could check the key of an inventory item, that would do something similar, but there are security concerns about that, so there is no way to get a key for a script unless the script has full perms. Giving a hash of the script would work better, as it would not suffer from security issues.

Thanks for the positive feedback. This is something so screamingly basic that I'm amazed it doesn't already exist.

C'mon, Linden. Let's get a good, useful feature out there, huh?

I think the main reason it was never implemented in the first place was that no one thought it would be needed.
Reason it wasn't implemented later is that no one has been able to suggest a way to verify the script. This comes very close. The only issue remaining would be that Barney (in your example) would have to be a trusted source--like a Linden--such that they don't steal code and sell it for themselves and that they don't take bribes ("Here, it pays you L$1 and it pays me L$1 for every $L7 the owner gets paid" (gross income)).

The Lindens don't need to be involved at all, and shouldn't be. I would suggest that independent private groups--more than one--get into the verification trade. The quick reason is that it's not really feasible to buy off everyone, and if you're bought off, you'll quickly be smoked out.

And when it comes to "stealing code and selling it," let me let you in on something...there is nothing on SL that is that difficult to independently develop. The code in and of itself is worth very little, IMO. I can duplicate just about anything I've ever seen on SL; whether I'd want to is a different matter. Why steal someone else's and risk discovery when you can do it yourself on the cheap?

Sounds like a fine idea to me, and something I think (hope!) the Lindens would get behind. This takes them out of the loop, and allows us a way to police ourselves. I'd vote for it.

Great idea,

I have sploders from an In-World business that lost their reputation to people claiming backdoors were placed in the script, and now I wont use this item out of fear this would end that Sounds like a great idea!

Try to make a slot machine then, one that has the same odds that RW slots do, has reels that rotate (either prim or texture) to show what came up, as well as track profit and loss, or even what some of the big name slot machines do: track that profit/loss in such a way to control the payout so that the profit is >0 and the odds are on track exactly.

It's not easy. I've done it (minus the maintainence of odds). Takes about 3 weeks.
737 lines in 5 scripts.

The rotating reels were the only part I hadn't done with the script I wrote, because I didn't at the time know how to.

Took me about 500 lines in five scripts (and I've not been CG'd for even two weeks, so you can see how long it took by that), but in truth four of those five scripts were just the lever and three buttons. So they were pretty short. Granted, I'm a professional programmer IRL with a good whack of experience, but still--it's not that hard.

See here: /54/63/158231/1.html

for an LSL attempt at enabling "trusted" access to debit permission. It's not ideal but it should be better than nothing.

True, it was just an example I had on hand.
The roulete wheels where you rez prims and hand place them are beyond me currently.
As is anything that communicates out side of SL (XML RPC or HTTP)
Along with various games. I don't understand how to play some of them, much less how to code them.

Side note:
My slot machines went from actually spinning/rotating the reels/textures to a quick "gimme a number and we'll rotate to it." (such that 1 -> cherry and 4 -> cherry didn't show the same cherry)
Didn't use a lever or buttons on mine, when the machine stores how much money the player has it's easy for them to know how much they've made or lost. Make them do it themselves and it's harder and they lose track. (3 reel scripts, one main script, and one that did floating text for the payout board--I was on the cheap and didn't feel like texturing up another prim; it did what I needed and I left it.)