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

[Erwin Solo]

On 10/6/2019 at 9:55 PM, CoffeeDujour said:

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.

I second that.  Ripping textures is wrong, just like copy/pasting IMs, and both have the comparable level of technology protection in the viewers.  

Is someone going to become concerned that we can copy text out of no-copy/no-mod notecards? 

Edited November 20, 2019 by Erwin Solo

[Blush Bravin]

9 hours ago, Erwin Solo said:

Is someone going to become concerned that we can copy text out of no-copy/no-mod notecards? 

This was not the issue. The problem, which has been resolved since the initial post, was that doing an appearance to XML report garnered all UUID numbers worn by a person so that anyone could use the viewer to rip any UUID worn easily. In the early days of omega this report and knowledge of how to use the report was being blogged about ended up in the wide scale passing of UUIDs between residents. This was not an issue of copybotters using devious measures to rip textures but simply people using a report readily available to them in the viewer thereby giving them the false notion that what they were doing was not theft.

[Drayke Newall]

12 hours ago, Blush Bravin said:

This was not the issue. The problem, which has been resolved since the initial post, was that doing an appearance to XML report garnered all UUID numbers worn by a person so that anyone could use the viewer to rip any UUID worn easily. In the early days of omega this report and knowledge of how to use the report was being blogged about ended up in the wide scale passing of UUIDs between residents. This was not an issue of copybotters using devious measures to rip textures but simply people using a report readily available to them in the viewer thereby giving them the false notion that what they were doing was not theft.

Not sure if it is around anymore, but I recall that there was a script once that could be placed in an object that would give you the UUID of the texture in the object when clicked. If this script is still available wouldn't this generally give the same false notion to users?

[Erwin Solo]

6 hours ago, Drayke Newall said:

Not sure if it is around anymore, but I recall that there was a script once that could be placed in an object that would give you the UUID of the texture in the object when clicked. If this script is still available wouldn't this generally give the same false notion to users?

In ancient times, one could do so.   "On 5/15/2005 (give or take a day) llGetTexture was changed to check the host object's permissions and if inadequate return NULL_KEY."

http://wiki.secondlife.com/wiki/LlGetTexture

[Pussycat Catnap]

On 10/6/2019 at 6:11 PM, Blush Bravin said:

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. 

The UUID of every texture you encounter in SL is stored in your cache folder... in plain text... in both Windows and Mac.

All one has to do to rip ALL the content they see in SL, is open Windows Explorer or Mac Finder and navigate to the cache folder...

That's not a whole, it's the entire freaking Panama Canal...

 

BOM or Appliers or even going back to 2003 era system avatars - nothingcan solve for that other than a redesign of the caching system to use some kind of encryption...

Edited January 13, 2020 by Pussycat Catnap

[Blush Bravin]

11 minutes ago, Pussycat Catnap said:

The UUID of every texture you encounter in SL is stored in your cache folder... in plain text... in both Windows and Mac.

All one has to do to rip ALL the content they see in SL, is open Windows Explorer or Mac Finder and navigate to the cache folder...

That's not a whole, it's the entire freaking Panama Canal...

 

BOM or Appliers or even going back to 2003 era system avatars - nothingcan solve for that other than a redesign of the caching system to use some kind of encryption...

You are stating what I've already acknowledged. It's beside the point. Just because someone can speed down the road any time they choose doesn't mean law enforcement should just give everyone a pass or not use means available to make speeding have consequences. This is OLD news anyway. The issue I was addressing has been addressed by the Lab and removed as I stated. 

Those who were using the readily available UUID numbers listed in the report were passing those numbers around. They were not typical content rippers who rip something trying to make money off of the content by reproducing it and selling it. The argument they proposed was that since they had bought a system shirt then they now had a right to have the UUID number of the texture so they could use it in an applier. Had it stopped there it wouldn't have really been an issue, but that's not what happened. Some, not all, began sharing those UUIDs with friends, then friends shared with more friends. It was a mess! Those who were doing this were not likely to go sifting through a cache trying to find the UUID numbers.