Potential for UUID ripping from system layers and consequent use with appliers

[Blush Bravin]

I stopped including system layers with my appliers because it was brought to my attention how easy it is to rip the UUID numbers of any worn system layer. So my question is if this project goes forward with an applier system in place what safeguards will there be to prevent use of a UUID# without actually owning the texture to make appliers?

[Fionalein]

I'm not into this, so no idea how easy, but I think if you crossed the line to rip an UUID form a system layer it's just a small step towards ripping a texture from a mesh ...

 

[Lillith Hapmouche]

Frankly, offering both system layers and appliers might be your best bet, since you eliminate a great deal of motivation for folks to rip your UUIDs.  

Besides that, the same can be done with appliers. Actually, system layers should be your better bet, since the textures get baked into a single texture, while applier textures should be a single file ... not sure, except for the baked single texture.
Everything you see on your screen is also saved on your machine. That's the way SL works.

The only really safe safety is reached by one foolproof method: to stop creating. Don't think you want to consider that just due to fear of potential ripping. 

[Theresa Tennyson]

I also believe that mesh textured with appliers actually send the original texture (including its UUID) to everyone who sees that avatar, so if they have a way of reading them anyone can steal your UUID's. With system layers at least you can only get the UUID of items you already own; everybody else will have the UUID of the bake so it's useless for repetition.

[Blush Bravin]

I asked this because back in the early days of the implementation of Omega there was a lot of UUID swapping going around as well as sharing of notecards that had info on them. Steps were taken to make it more difficult to do so such as having to have the actual texture and dropping it into the applier and the auto deletion of notecards. I know there is no way to guarantee that someone won't be able to rip your work but at least I don't want it to be easy. So I was wondering if anyone had been thinking about this already and if any steps were being taken in that direction. 

[Jenni Darkwatch]

System layer is a lot safer than appliers. Getting the UUIDs of applier textures is utterly trivial without even using a specialized viewer, as is getting ANY texture UUID for ANY texture you see in SL. The exception is system layers, because as Theresa correctly said, those get baked into one composite texture.

I don't know if bake-on-mesh does the same texture combining, but I would presume it probably does. Which would again make it safer than appliers.

[Blush Bravin]

54 minutes ago, Jenni Darkwatch said:

I don't know if bake-on-mesh does the same texture combining, but I would presume it probably does. Which would again make it safer than appliers.

I agree system layers are safer, but if the applier system being requested goes into effect we will likely find ourselves in the position that we have to provide both system layers and appliers.  Thus creating a situation where the UUID numbers will be easily obtained from the system layer, and then those UUIDs can be used to make appliers. I hope to get ahead of this to think of safeguards prior to release rather than play catch-up after a slew of original content has already been ripped.

[Vir Linden]

The baking service uses textures from your system wearables (skin, tattoos, shirts, etc) and composites them into 6 baked textures. The way this works is that you and the baking service know what all those individual wearables and textures are, but observers only see the result of the baking process. So in that sense the textures are a bit more secure - an observer has access to how the textures look when combined, but doesn't have access to all the individual textures that were used in the baking process.

[Theresa Tennyson]

47 minutes ago, Blush Bravin said:

I agree system layers are safer, but if the applier system being requested goes into effect we will likely find ourselves in the position that we have to provide both system layers and appliers.  Thus creating a situation where the UUID numbers will be easily obtained from the system layer, and then those UUIDs can be used to make appliers. I hope to get ahead of this to think of safeguards prior to release rather than play catch-up after a slew of original content has already been ripped.

What do you fear that these ripped appliers will be used for? You need to own a copy of the system asset in order to get UUID's from it, and someone looking to make and distribute an illegal copy of a skin can already do it more easily in a number of different ways.

I agree that there needs to be the perception of security - the equivalent of a "suitcase lock." The little locks that hold the zippers of a soft-sided suitcase shut are ridiculous as a security system - they all use the same key and even if you don't have a key you could probably pop them with a big screwdriver. They're just good enough to keep a random person from opening the zipper on a whim. On the other hand, there isn't much of a point to make them a lot more secure, as someone who wants something out of your suitcase can cut the fabric open almost as easily. 

I can think of one thing that might help without major restructuring. Right now you get the original UUID's of the texture files when you go into "Edit My Appearance"  because it's more efficient to use local copies of the textures (and years ago the baking was actually done by the viewer.) If, instead of sending the original textures, the baking service ran the file through the system to make a copy with a new, temporary UUID and sent that instead that would at least protect the original UUID and make appliers using the temporary UUID useless.

[Blush Bravin]

1 hour ago, Theresa Tennyson said:

What do you fear that these ripped appliers will be used for? You need to own a copy of the system asset in order to get UUID's from it, and someone looking to make and distribute an illegal copy of a skin can already do it more easily in a number of different ways.

Years ago when the Omega system was first released, before safeguards were established, there was a short time when people were passing around the UUIDs of system clothing they owned to friends. Then those friends passed them to other friends. It even happened in the beginning with the Catwa Huds when you could input a UUID for the skin layer. Catwa changed that part of the hud so that UUIDs couldn't be used directly in the hud because of that. 

The fact that it has happened in the past and measures where taken to reduce the ease of doing so, shows that it's something we would be wise to contemplate now rather than have to come up with a solution weeks if not months after the fact.

I don't have solutions. I don't script. I'm not very technologically advanced, but I know there are brilliant minds out there working on the project and are talented in this area. So I hope bringing attention to this might help get those minds thinking about the possibilities.

[Blush Bravin]

2 hours ago, Vir Linden said:

The baking service uses textures from your system wearables (skin, tattoos, shirts, etc) and composites them into 6 baked textures. The way this works is that you and the baking service know what all those individual wearables and textures are, but observers only see the result of the baking process. So in that sense the textures are a bit more secure - an observer has access to how the textures look when combined, but doesn't have access to all the individual textures that were used in the baking process.

Right now I can use the developer menu to access all UUIDs for textures worn on system layers. What I'm hearing you say and I hope it's what I'm hearing is that once the BoM goes into affect, all those textures will then be composited into one texture with a totally different UUID? Will that UUID be the only number shown on the appearance to XML report? If that's correct, I will be breathing one huge sigh of relief.

 

Although if someone really wants to steal the UUID number all they have to do is wear one item at a time and then get the report. So perhaps not as big a relief as I initially thought.

Edited May 1, 2018 by Blush Bravin
added afterthought

[Vir Linden]

15 hours ago, Blush Bravin said:

Will that UUID be the only number shown on the appearance to XML report? If that's correct, I will be breathing one huge sigh of relief.

 

Although if someone really wants to steal the UUID number all they have to do is wear one item at a time and then get the report. So perhaps not as big a relief as I initially thought.

Using bakes makes it harder to access the UUIDs of other avatars, because all you know is the UUID of the final bake. For your own avatar, you still have all the system wearable UUIDs available - the viewer has to know all the UUIDs, because when you're editing your appearance the "baking" is being done locally using those textures. And as you say, with your own avatar you can control exactly what items are worn as well.

[Callum Meriman]

On 5/2/2018 at 7:28 AM, Blush Bravin said:

Although if someone really wants to steal the UUID number all they have to do is wear one item at a time and then get the report. So perhaps not as big a relief as I initially thought.

You can do the same with the old system layers through an empty cache. UUIDS of system layers have always been absolutely trivial to find if you have them in your inventory.

Edited May 4, 2018 by Callum Meriman

[Coffee Pancake]

Hopefully the upcoming image cache rework will help to resolve this.

[Callum Meriman]

10 minutes ago, CoffeeDujour said:

Hopefully the upcoming image cache rework will help to resolve this.

Something (maybe) as simple as salting the file names so they were not stored with the UUID as the file name would be a huge, and fairly simple first step.

Edited May 4, 2018 by Callum Meriman
Added the word Maybe, as nothing in programming is straight forward. heh

[Coffee Pancake]

I would rather see textures stored with a hash of the UUID.

[Callum Meriman]

12 hours ago, CoffeeDujour said:

I would rather see textures stored with a hash of the UUID.

https://en.wikipedia.org/wiki/Salt_(cryptography)

[Blush Bravin]

.

 

Edited May 6, 2018 by Blush Bravin

[Blush Bravin]

On 5/2/2018 at 7:37 AM, Vir Linden said:

For your own avatar, you still have all the system wearable UUIDs available - the viewer has to know all the UUIDs, because when you're editing your appearance the "baking" is being done locally using those textures. And as you say, with your own avatar you can control exactly what items are worn as well.

Sorry if I did this the wrong way, but I wanted to be sure to get your attention on the JIRA I filed. https://jira.secondlife.com/browse/SEC-6258

It's my first time to file one and I've probably left off important steps.

[Kyrah Abattoir]

On 5/1/2018 at 4:00 PM, Blush Bravin said:

I stopped including system layers with my appliers because it was brought to my attention how easy it is to rip the UUID numbers of any worn system layer. So my question is if this project goes forward with an applier system in place what safeguards will there be to prevent use of a UUID# without actually owning the texture to make appliers?

Ironically system layers are (only slightly) more troublesome to get out than anything on an actual object.

Congratulations on providing a worse service to your customers for no gain.

This is the wrong battle, you can't prevent people from ripping any assets from SL anymore than you can prevent it in any other game/game-like application. You should focus on providing good support to your customers and witholding system layers doesn't qualify for "good support".

Edited May 13, 2018 by Kyrah Abattoir

[ChinRey]

On 1.5.2018 at 4:00 PM, Blush Bravin said:

I stopped including system layers with my appliers because it was brought to my attention how easy it is to rip the UUID numbers of any worn system layer.

That is a problem, yes. Unfortunately it is even easier to rip the UUIDs from applier clothing for mesh bodies.

Or to put it this way: with bakes on mesh, it should be possible to upgrade the texture UUID security for applier clothing to the same level as system clothing has now.

Edited May 14, 2018 by ChinRey

[Kyrah Abattoir]

36 minutes ago, ChinRey said:

That is a problem, yes. Unfortunately it is even easier to rip the UUIDs from applier clothing for mesh bodies.

Or to put it this way: with bakes on mesh, it should be possible to upgrade the texture UUID security for applier clothing to the same level as system clothing has now.

If we can call that "upgrading" yeah. I wish we could shake this delusion that there is some way to protect art assets while still displaying them.

In the realm of computer, read right == copy right.

Edited May 14, 2018 by Kyrah Abattoir

[Blush Bravin]

3 hours ago, Kyrah Abattoir said:

Ironically system layers are (only slightly) more troublesome to get out than anything on an actual object.

Congratulations on providing a worse service to your customers for no gain.

This is the wrong battle, you can't prevent people from ripping any assets from SL anymore than you can prevent it in any other game/game-like application. You should focus on providing good support to your customers and witholding system layers doesn't qualify for "good support".

99% of my customers use mesh bodies and therefore not providing a system layer has not been an issue; however, with the implementation of BoM, I will naturally want to provide system layers. My issue had nothing to do with the results of copybotting, and everything to do with the ease of access to UUID numbers in the developer menu. I did file a JIRA about this and am encouraged by the responses I've received.

[Kyrah Abattoir]

System layers are a convenience tho, personally I routinely use my system body as a "glue" for mix and matching parts, so I definitely see the value in having them provided.

[Theresa Tennyson]

7 hours ago, Blush Bravin said:

99% of my customers use mesh bodies and therefore not providing a system layer has not been an issue; however, with the implementation of BoM, I will naturally want to provide system layers. My issue had nothing to do with the results of copybotting, and everything to do with the ease of access to UUID numbers in the developer menu. I did file a JIRA about this and am encouraged by the responses I've received.

I see this fairly often and my question is: how do the people who say this know? Of course, now 100% of your customers use mesh bodies because you don't provide anything that's usable for someone who doesn't. I only use mesh bodies on some accounts but many of my purchases for the non-mesh accounts are for items that contain both appliers and system layers or standard size meshes and proprietary fitted meshes, either because they're the only things available that I can use or because I'm future-proofing. How do you as a merchant know which I'm using?