Another Important Issue With Texture UUID Encryption

[SundanceHaiku]

Fred (and licensing experts), I need your advice. Let me tell you where I’m at in the process.

Thanks to Fred's suggestion on Me-We, I have found a work-around with the bug in the llBase64ToString function. That's squared away. I also have completed adding the XTEA encryption code to all Ruth parts that expose texture UUID’s. These include the following:

1. Skin HUD – Sender Script

2. Alpha HUD – Sender Script (this wasn’t absolutely necessary but it would have required extra coding to by-pass it. )

3. Body Receiver Script. (I re-worked the body receiver script so that it is backward compatible. In other words, if someone uses one of the older HUD’s which is not encryption enabled, the Body will still process the commands.)

4. Shin’s Injector. The Injector is a clever idea which keeps full perm textures in OS from being exposed. Unfortunately, I found that one could obtain the UUID when the Injector transferred the texture to the body. I have found a way to plug that hole by adding an encryption routine.

5. New Creator’s Skin/Texture HUD. Shin’s Injector does not work in Second Life, and something was needed in that platform to help protect creators. Consequently, I built a new HUD for creators that stores encrypted UUID’s. The customer can then transfer the UUID’s to the body. It uses the same Body Receiver Script used by the other HUD’s. I believe that this will also work in other closed grids.

At this point, I have about 40 hours of work into this. Fortunately, I had some extra time the last couple weeks to work on it.

Now that I’m nearly finished, here’s what I ran into . . .

In order to keep the contents of the notecard hidden, one has to set the permission of the notecard to “No Copy.” Unfortunately, “No Modify” does not do the job. If the notecard is "No Modify," it can be dragged out of the object and into your inventory where it can be read. You can test this by creating an object with a notecard, setting the notecard to "No Modify," and giving it to an alt. The alt, using this method, can read the notecard.

That got me wondering how exactly one can protect the contents of a notecard. To find that out, I ran a series of tests with an alt. The results are summarized on a spreadsheet found here:
NotecardPermTest.pdf

You’ll see from the spreadsheet that the only way to prevent the notecard from being opened is to use “No Copy.”

But this creates a problem. Once the notecard is set to “No Copy,” the Ruth Body, itself, will become “No Copy.” That will cause all sorts of complications for creators and individual users of Ruth. I won’t go into detail, but I’m sure you know what I mean.

Possible solution . . . Fred, I'd like to direct this question to you. What I’d like do is to include the license key with your code in the XTEA script. A "No Modify" script is very safe, and that way we don’t have to use a notecard. I was thinking that this might be possible, since you had included the following comment in your code: “The following code is licensed by Fred Beckhusen as CC-0. You do not have to publish this code under AGPL. You do not want this code to be set to modify in your product.”

If you have licensed the code as CC-0, wouldn’t that allow for making a modification and setting the script “No Modify?” The XTEA code in GitHub would still be public. The only thing that would be changed would be the license key. By doing so, we are able to provide some security for creators without resorting to making Ruth no copy. We are able to keep the communication channel public. And, most importantly from my perspective, all the work I’ve done won’t be for naught.

Fred, what is your read on this?

[aiaustin]

I understand your desire for the content protection on your elements Sundance... but I hope you are talking about a variant of Ruth and Roth released by you (“Secure Ruth”?) to support such content protection and not something we would encourage everyone to use.

In our open grids it is really inconvenient when items intended for widespread use cannot be copied and shared rather than reoriginated. Having the same underlying meshes and textures served to all users is much more efficient and will likely allow more rapid rezzing of Ruth and Roth in use across our grids.

[SundanceHaiku]

Ai, did you read my message? That's exactly what I'm trying to avoid.

[Outworldz]

I think you have done an really outstanding job. Thank you. It fixes the problem I tried to solve with a non-readable, transfer Notecard, which you have found is impossible to make. It solves the problem of people ripping off skins by wearing a simple listener script. Since they cannot get the XTEA key, they cannot decode the UUID's. The script is CC-0, which certainly allows the script to be used in this way.

[aiaustin]

I did see your comment about trying to keep the body mesh no copy, which is what I assume you are referring to Sundance. But would the other content changes make it no transfer or no modify?

I am hoping we can have a simple Ruth and Roth setup that is full perm and easily buiit into outfits, default avatars, vendors and NPCs that works over the hypergrid too. Sharing the content, as I sais, will enable faster load than if lots of seoarately uploaded copies with their own asset UUIDs get out there.

[Outworldz]

AI: The XTEA script would be the only thing no mod.

The idea is that someone can put full perm skins in it (full perm is required to make the technique in Ruth/Roth work), yet others cannot swipe the skin by listening to the well-known channel.

[SundanceHaiku]

Fred, that's wonderful! Thanks for your scripting work to get this underway. Creators like Chris Namaste will be delighted that we will have this option available for them. I will finish things up and post all of the new code.

Ai . . . people don't have to use the encryption system. That's totally up to them. A very simple Ruth currently exists - and you and others can continue to use and improve upon her.

But there are others, particularly creators, who have been hopeful for a solution to the texture rip-off problem. Creators - and when I say creators, I mean both people who give away their creations and those who sell them - should have basic protection from thieves. Because Ruth is open source under AGPL, we can't hide the communication channel which would have been an easy solution. We can, however, use an encryption method and yet abide by the project's licensing ground rules.

We're not offering a perfect solution. There are other ways to rip off textures, but at the very least, we can provide what has become in the virtual world an accepted standard of care. It's the right thing to do. Not to do so, in my opinion, is callous - and I don't think that is what Ruth is all about.

I have no idea whether it will be accepted. Creators will have to decide how to implement it and how they will distribute it. That's for them to decide. We'll provide the tools, and if they can use them, great. If not, at least we didn't leave them twisting in the wind.

I do want to say one last thing about speed. I have looked at the difference in processing time of HUD communication to and from the body. I could not detect a difference in OS, but I did notice a speed hit in SL. To correct that - and I did this for both OS and SL - I made some alterations in the code so that the processing is actually faster with encryption than without it.

[aiaustin]

Got it. Thanks Sundance and Fred.

[SundanceHaiku]

Fred, I am looking for a distribution point for Ruth with the encryption changes. Normally, I would give it to Shin, but his regions have been taken down. Could we distribute her on your grid (OutWorldz)? If it's not appropriate for your sim, no problem. I thought I'd check with you first since you have been so generous to the virtual world community and have been an important force in this project.

[Outworldz]

Sure, my Welcome region would be fine. I imagine many others would be better though. Why don't you ask on G+ or Mewe?