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

[Blush Bravin]

41 minutes ago, Tomaltach said:

You are aware that Omega literally sells the tools needed to copy UUIDs on their own marketplace store for L$999, right? https://marketplace.secondlife.com/p/LNL-Mesh-Maker-Dev-Kit/6525668

While it isn't intended for that use, it can be used for it because of how SL treats linkset permissions.

@Chellynne Bailey care to comment?

[Tomaltach]

Here's a quick example of how linkset mechanics work in SL:

Those that understand the significance of this will know why this is very bad. This also means that ANY omega-compatible mesh that happens to be mod is vulnerable.

It should be pointed out that there is NO way via LSL to distinguish between a "really" no-trans object and a "temporarily" no-trans object.

To solve this, LL needs to do two things: Add an llGetLinkPermMask(category) function, and add an extra category that stores the unlinked permissions.

EDIT: Without naming names, it does indeed work on mod meshes that are omega enabled. Meaning it's possible for much less than 999L$. I'd like for LL to fix this.

Edited June 5, 2019 by Tomaltach

[Alyona Su]

2 hours ago, Tomaltach said:

Those that understand the significance of this will know why this is very bad.

It's kind of always been this way since the beginning. It is the same way if you drop a no-transfer object, notecard, script, sound, texture, anything into the contents of the Full Perms object. So, what exactly is it you want to change and why? I'm just curious. Objects have always presumed the tightest restriction that they are linked to or within their contents. This is how people create no-copy/no-modify/no-transfer objects: put a no-copy item and a no-transfer item into the contents. Done.

[Tomaltach]

I explained what I wanted to see change: A way to find out an object's "true" non-inherited permissions by script.

The reason for this is the way that llGetTexture(face) works. It will return a valid UUID as long as the script is in a full-perm object.

[Drake1 Nightfire]

1 hour ago, Tomaltach said:

I explained what I wanted to see change: A way to find out an object's "true" non-inherited permissions by script.

The reason for this is the way that llGetTexture(face) works. It will return a valid UUID as long as the script is in a full-perm object.

You realize that every texture you have ever seen in SL is stored on your computer, right?

[Tomaltach]

4 hours ago, Drake1 Nightfire said:

You realize that every texture you have ever seen in SL is stored on your computer, right?

Oh please, you know perfectly well that there's a difference between needing an external tool and patience to spot the one texture you're hunting for, and dropping a script in a prim and clicking it. Don't act like those two scenarios are even close to similar. That's BS and you know it.

It's blindingly obvious that SL should not include the tools needed to break its own permission system.

Edited June 6, 2019 by Tomaltach

[Cackle Amore]

On 6/11/2018 at 7:37 AM, OptimoMaximo said:

 This goes well, PERHAPS, for the mesh avatars that comply to the classic avatar's standards, but those that have proprietary UVs and/or different UV arrangements are being cut off from this anyway.

Actually we aren't, I've tried out BoM on my own avatar I been working on which has it's own dedicated UV, and I was able to plug it into the BoM stuff just fine, I actually had a slow left over cause I only had two textures to worry about for the main part of it. Obviously, if I want to use clothing and tattoos, etc with it aswell, those would need to be tailored to my specific UV, but peeps do that all the time already, it would be opening up the door to mix in old features to do it.

Hell, just look at how utterly sliced up and butchered we have to make avatars just to squeeze in Alpha Huds, won't have to do nearly as much of that anymore, just cover a few basic large chunks and the alpha layer system can cover the rest.

 

Now obviously, it won't work for every custom UV'd avatar, but that would mostly be the creators fault for how they set up their UV's. One that's got their UV's butchered into like 10 different pieces for example. BUT, if your smart about how ya set em up and keep it under three, you can easily hook it up into the skin layer. Hell, I even hooked up my characters eyeballs and hair into their respective slots.

 

Clearly it won't be a end all be all of 'layers', as there can still be use for those extra overlaying mesh, but it will greatly reduce the amount of em needed at the very least, and using this snippet from another post, a lot of the base things can just be baked directly on instead of having dedicated onion layers for each and every freckle and tattoo, and the other gal could use that onion for her latex body suit.

On 5/29/2018 at 4:14 AM, Theresa Tennyson said:

Main body of avatar: a single 8-face mesh that supports bakes on mesh, used for skins, tattoos/body detailing and alpha masks to wear under mesh clothing, and a possibility of underwear/hosiery worn as layering. Put on using system assets. With 8 faces, you could have an upper body, lower body, dimensional nipples that can be turned off individually, a "crotch cover" that can be turned off and three additional faces for a choice of neck sizes, etc. [Materials would be handled the same way mesh bodies are now]

Not everything has to be synced to BoM, only what's needed.

[OptimoMaximo]

1 hour ago, Digit Gears said:

Actually we aren't, I've tried out BoM on my own avatar I been working on which has it's own dedicated UV,

Read my post more intently, as i was referring to the default avatar STANDARD, meaning

1 hour ago, Digit Gears said:

BUT, if your smart about how ya set em up and keep it under three,

Therefore, what if i arranged my avatar differently? Auxiliary channels now can do the trick, but this feature is not nearly as advanced/useful as my proposal of dumping BoM for a more robust and versatile materials layering system, which would apply to ANY item, instead of relegating this feature to a baking service generated texture for worn avatars only. 

[Cackle Amore]

13 minutes ago, OptimoMaximo said:

Read my post more intently, as i was referring to the default avatar STANDARD, meaning

It was a very long post, my eyeballs probably missed some of it 😧

13 minutes ago, OptimoMaximo said:

Therefore, what if i arranged my avatar differently? Auxiliary channels now can do the trick, but this feature is not nearly as advanced/useful as my proposal of dumping BoM for a more robust and versatile materials layering system, which would apply to ANY item, instead of relegating this feature to a baking service generated texture for worn avatars only. 

Well, personally for me, I'd rather try to avoid using the aux slots for the base skin textures, as I don't want my avatar to hog up too much space, then there would be less slots for other things to be synced up to the BoM thing. And you can still put materials on the mesh, but ya, the materials thing is certainly rather limited unfortunately, maybe down the line they might find a way to improve on it, but certainly no reason to just scrap the whole project all together just because it lacks finer detail in materials.

 

I'm still quite looking forward to it personally, and hope it'll be coming around soon since it's been sitting in the RC's for a good month or so now.

Edited June 6, 2019 by Digit Gears

[Ramses Meredith]

On 6/13/2018 at 4:37 PM, Vir Linden said:

Sorry, I had planned to do a post about this. We are adding 5 new baked channels, called left arm, left foot, and aux1, aux2, and aux3. The left arm and left foot channels are specifically intended to help with the case that you want to make limbs that don't match left and right, although of course you can use any channel for any purpose.

Originally we had planned to add the new channels to the existing tattoo wearable. Unfortunately old viewers get very unhappy when they see new channels being added to their old familiar wearables, and tend to crash. So instead of modifying the tattoo, we are creating a new wearable type called universal. Universal wearables will include all the channels old and new. They basically work like a super tattoo. Like the tattoo, they have slots for textures, but nothing else - for example, there are no associated sliders, no automatic alpha masking, etc - by contrast with more complex wearables like the shirt. Universal wearables will layer above the current tattoo wearables and below all the other clothing. Old viewers of course won't know how to handle these new wearables, but they will just ignore them rather than crashing. 

Adding a new wearable type will also require changes to the simulator, baking service, and inventory service. After the next project viewer update, all these things will be working in supported test regions on Aditi. We will update you when it's all ready to try out.

Question: these channels will be available via scripts via normal outfit editing or via lourdes?

[carley Greymoon]

why can't an object using a baked texture use material textures? i don't get it. mesh avatars will still use HUDs, why can't they apply material textures just like they do now?

i'm not up on all this so maybe i completely don't understand, but as far as i know all BOM will do is flatten all diffuse textures into one texture, so how does that change how material textures are currently applied?

and even if it doesn't support materials, so what? it's not like that issue can't be figured out. in the end an object using BOM will also be able to use materials because this is not a problem of quantum physics, it's just applying a texture to an object.

it reminds me of the whole "ruth avatar can't be updated with new geometry because it would need different UVs"...........that was true until it wasn't.

[Kyrah Abattoir]

On 6/6/2019 at 5:21 AM, Tomaltach said:

Oh please, you know perfectly well that there's a difference between needing an external tool and patience to spot the one texture you're hunting for, and dropping a script in a prim and clicking it. Don't act like those two scenarios are even close to similar. That's BS and you know it.

It's blindingly obvious that SL should not include the tools needed to break its own permission system.

You are either delusional, or very stupid if you believe that this is even remotely relevant.

[Chellynne Bailey]

On 6/4/2019 at 9:33 AM, Blush Bravin said:

@Chellynne Bailey care to comment?

Do I have to?

On 6/5/2019 at 8:02 AM, Tomaltach said:

Here's a quick example of how linkset mechanics work in SL:

Those that understand the significance of this will know why this is very bad. This also means that ANY omega-compatible mesh that happens to be mod is vulnerable.

It should be pointed out that there is NO way via LSL to distinguish between a "really" no-trans object and a "temporarily" no-trans object.

To solve this, LL needs to do two things: Add an llGetLinkPermMask(category) function, and add an extra category that stores the unlinked permissions.

EDIT: Without naming names, it does indeed work on mod meshes that are omega enabled. Meaning it's possible for much less than 999L$. I'd like for LL to fix this.

Well first I will verify that this does infact work. I tested this awhile back.  It's a fact I'd have liked to not advertise to the grid, because Security by Obscurity does help, but here we are.

I'm not sure if this behavior has ALWAYS been this way. I remember doing tests along these lines when setting up the Mesh Maker Dev Kit, and didn't run across this behavior. But in more recent tests, it's definitely a hole. One I've been trying to think of a way to solve, but haven't had much luck. (If anyone has an idea, feel free to let me know x.x)

I do take security VERY seriously and do my best to keep my ears to ground and be aware of the various ways a texture could be compromised, so that if I can do ANYTHING to prevent it, I do. This includes occasionally lurking on ..lets say.. sketchy... sites and speaking to less then scrupulous people.  That's why over the years there's been various security measures added to protect the textures. Some I have advertised. Others I have not.  Sadly, there is never 100% security with textures. As stated earlier, on the Internet, Read=Copy. But anything I can do to make it easier for people to be honest and buy instead of steal without being a huge burden on creators or consumers, I do that thing.    

But this has to be the most convoluted method of ripping I've seen to date. While this is definitely a security hole,  it's one that requires a bunch of gymnastics to do.  I really don't see anyone using it. If someone is this set on getting your UUIDs, they aren't doing it this way.  If you are going to panic over this hole, there are holes that'll give you a straight up heart attack.

That being said, they are absolutely right in that we need SL to fix this. Unlike some other holes, this is absolutely a fixable one. 

I also need to point out, before this sprouts more fears about Modify Meshes, is that ALL meshs, mod or not, Omega or Not, are susceptible to this UNLESS  they are like Slink and have a designated Alt that NEVER gives out a Modify Prim under any circumstances. Scripts can't tell if a Prim is a Mesh body or a random gift the creator gave out 3 years ago. For this reason, this is a problem for all Meshes, Omega or not.   

Mesh Makers could start taking the Slink Approach to combat this, but I'm not sure that is reasonable to expect.  For myself, there's nothing I could do other then perhaps disable all Omega Kits EXCEPT Slinks. That, or demand all Omega Friendly Meshes be sold through me so I can verify I can control the Prims being handed out.  I'm not sure either demand is reasonable. 

Ultimately, the best thing any of you can do to protect your products is to keep providing the best customer service you can, including reasonable pricing and good applier support. Because 99% of the time, rippers start out as folks who just wanna get their skins onto the mesh of their choice.  But once they learn how, it's alot easier to graduate into more nefarious uses.
 

[Wulfie Reanimator]

2 hours ago, Chellynne Bailey said:

Scripts can't tell if a Prim is a Mesh body or a random gift the creator gave out 3 years ago.

They can with llGetObjectDetails and OBJECT_CREATION_TIME. It'll give you a string in the same format as llGetTimestamp.

default
{
    state_entry()
    {
        list details = llGetObjectDetails(llGetKey(), [OBJECT_CREATION_TIME]);
        llOwnerSay(llList2CSV(details));
    }
}

// Example: 2019-06-29T04:12:19.965463Z

New copies of the object will have the same timestamp as the original, even if you link more things to it.

That said, please don't bother setting your things to no-modify if your reason is "protection." It doesn't help and only hurts your customers.
There's only a handful of contexts where no-modify makes sense, like objects related to controlled environments like games/prizes/roleplay.

In general; bodies, clothing, and accessories should always be modifiable.

[Chellynne Bailey]

7 hours ago, Wulfie Reanimator said:

They can with llGetObjectDetails and OBJECT_CREATION_TIME. It'll give you a string in the same format as llGetTimestamp.

default
{
    state_entry()
    {
        list details = llGetObjectDetails(llGetKey(), [OBJECT_CREATION_TIME]);
        llOwnerSay(llList2CSV(details));
    }
}

// Example: 2019-06-29T04:12:19.965463Z

New copies of the object will have the same timestamp as the original, even if you link more things to it.

That said, please don't bother setting your things to no-modify if your reason is "protection." It doesn't help and only hurts your customers.
There's only a handful of contexts where no-modify makes sense, like objects related to controlled environments like games/prizes/roleplay.

In general; bodies, clothing, and accessories should always be modifiable.

That is an interesting idea. At the very least it'll make sure the script is in the intended object, mod or not. I'll play around with that.  Still, we need to fix that hole.

Edited June 29, 2019 by Chellynne Bailey

[Lucia Nightfire]

When I advocated for OBJECT_CREATION_TIME, the use case was to act as an unalterable identifier primarily for mesh but can be used for anything.

No two unique mesh assets or raw rezzed legacy prims from the same creator should ever have the same creation time.

Edited June 29, 2019 by Lucia Nightfire

[animats]

For what it's worth, animesh do not play well with the clothing permission system.

To put system clothing on animesh, you need the texture of the clothing item as a file outside SL. You need the texture of the skin as a file outside SL. If both are aligned to standard UV, you composite those, upload the result for L$10, and put it on the animesh.

Finding all those files is hard. Currently, I have all the files to make T-shirts, one dress, one set of jeans, and one set of socks and sneakers. Just enough for proof of concept work. Someday, Bakes on Mesh may allow reuse of system clothing on animesh, but that's apparently a long way off.

Rigged mesh clothing will work on animesh. It needs mod permission, because it's worn by linking it to the animesh. Mod mesh clothing is hard to find. Mod mesh clothing with reasonable triangle counts is even harder to find. Currently, I have two sets of hair, a ball cap, and a skirt that qualify.

It's all possible, but it's all uphill. Dressing animesh today means negotiating with creators for files.

[Da5id Weatherwax]

On 6/6/2019 at 4:21 AM, Tomaltach said:

Oh please, you know perfectly well that there's a difference between needing an external tool and patience to spot the one texture you're hunting for, and dropping a script in a prim and clicking it. Don't act like those two scenarios are even close to similar. That's BS and you know it.

It's blindingly obvious that SL should not include the tools needed to break its own permission system.

This is hard to refute without crossing the line into detailing "how to rip stuff" which is an obvious nono on any forum, but...

It's actually MORE hassle to get your hands on an object so you can drop a script in it to yoink its textures than it is to drop a hook into your graphics driver stack and then forget about it until you see something you want to yoink and then promptly rip every texture on your screen with a single keystroke... If you're the kind of guy who would do that you've probably got it configured to rip the triangles too and steal the whole object, not just its textures.

Look, I'm all for LL not facilitating content theft, and they don't. But they've got a LOT of better things to do with their available developer time than coding a completely ineffective figleaf to cover something that cannot be prevented at all.

For heaven's sake, most of the tools best suited to "ripping stuff" are, in their own right, perfectly legitimate developer tools. Plenty of folks have died from being stabbed with a screwdriver.... Just because something can be used for nefarious purposes doesn't eliminate any legitimate use cases it has, but we've already got a huge history of features with legitimate use cases being disallowed by LL because of the possibility that they could be misused. Let's not add to that list unless we truly have to, ok?

[Cackle Amore]

Ya, there's really not much you can do to stop someone determined enough to rip some clothing textures.

Where ya think most of those texture clothes use on the onion skins came from?

Edited June 30, 2019 by Digit Gears

[Chellynne Bailey]

On 6/29/2019 at 3:42 PM, animats said:

For what it's worth, animesh do not play well with the clothing permission system.

To put system clothing on animesh, you need the texture of the clothing item as a file outside SL. You need the texture of the skin as a file outside SL. If both are aligned to standard UV, you composite those, upload the result for L$10, and put it on the animesh.

You can also do what some have already done and come see me about getting Omega Installed.  It seems to work perfectly fine to set up an animesh like you would a mesh body with a couple clothing layers and then just throw it at my head for scripts.   Assuming of course you're the mesh creator and not an end user. (Sorry end users)

And frankly I'd be VERY disappointed if this hasn't already occurred to the major mesh bod/head makers that they could simplify their models and release "NPC" versions.  They wouldn't even need to come see me since it's already set up.

Edited July 3, 2019 by Chellynne Bailey

[animats]

2 hours ago, Chellynne Bailey said:

You can also do what some have already done and come see me about getting Omega Installed.  It seems to work perfectly fine to set up an animesh like you would a mesh body with a couple clothing layers and then just throw it at my head for scripts.   Assuming of course you're the mesh creator and not an end user. (Sorry end users)

And frankly I'd be VERY disappointed if this hasn't already occurred to the major mesh bod/head makers that they could simplify their models and release "NPC" versions.  They wouldn't even need to come see me since it's already set up.

Do you know of an Omega-based animesh character that's 30LI or less? I've tried turning avis into animesh, but I get LIs of 80-130 before adding clothing. I have some based on a body from uno.blokke that come in at 29-30 LI with hair and mostly system clothing. That model has one layer, the skin.

I'm working on behavior scripting, making animesh characters behave as effective NPCs that move around and react to people in the world. I'd much rather that others deal with bodies and clothing so I can focus on behavior.

Who should I be talking to?

Edited July 3, 2019 by animats

[Chellynne Bailey]

On 7/2/2019 at 9:14 PM, animats said:

Do you know of an Omega-based animesh character that's 30LI or less? I've tried turning avis into animesh, but I get LIs of 80-130 before adding clothing. I have some based on a body from uno.blokke that come in at 29-30 LI with hair and mostly system clothing. That model has one layer, the skin.

I'm working on behavior scripting, making animesh characters behave as effective NPCs that move around and react to people in the world. I'd much rather that others deal with bodies and clothing so I can focus on behavior.

Who should I be talking to?

-nods- I know what you mean. If I could get away from applier scripting for 5 mins I'd love to work on something like that. Would be an interesting project. 

As for who to talk to,  Sadly, everyone is still in the "We'll release soon, we're almost done!" stage or earlier.  And I don't release individual mesh information until they're ready for it to be released. Wooo privacy. But I'll keep your name in mind if anyone needs that sort of thing.

But yeah, you definitely need to simplify.. Stuff made to wear is going to explode your LI.  SL users have come to expect ridiculously detailed items to wear as they've never had to worry about LI on a pair of boots.   But now that lovely rigged hair and fitmesh boots that you've been wearing, while you can slap them on a NPC and it'll work... it'll wreck your LI. 

Same for bodys and heads... Frankly,  25-30LI with 4 layers is very doable from what has landed in my box, but the models gotta be fairly simple. You just can't have the sort of detail that's been poured into the parts marketed as attachments.   

Edited July 8, 2019 by Chellynne Bailey

[Otharious]

Soooo you do all understand that if someone wants to rip textures? they can just do it with openGL tool right? Nothing you can do INSIDE LL will protect your meshes or your textures or anything. at all ever "NO mod".....nothing. The second it hits any computers cash, the second it hits your graphics card it is at risk of being taken BY ANYONE that wants it. period full stop.

just my 2 cents

 

[Blush Bravin]

1 hour ago, Otharious said:

Soooo you do all understand that if someone wants to rip textures?

Yes, of course we all know this. The viewer issue that prompted me to make this post in the first place has been address and removed from the viewer. Thankfully more than just my jira had been filed about the problem. Just because it's possible for textures to be ripped doesn't mean we should put our heads in the sand and do nothing when we can at least plug some of the holes used by rippers. 

[Coffee Pancake]

To really labor the point ... ripping textures via the standard tools available inside SL is akin to bunny hopping over the gate on a unicycle and ignoring that the gate, while present, isn't even locked.