How hard is it to protect texture Cache with encryption, Lindens?

I don't suppose this works for modifiable scripts in one's inventory by any chance?

I have a ton of little free scripts that I would like to merge into one text file, so if someone asks for an example of how to use an LSL function I can just do a text search and (hopefully) voila- there is an example in a little script.

I am not going to do it manually by copying and pasting.

Actually... yes ;0 There is some work being done on a new compiler that will actually do some optimisations to scripts that Linden Lab's compiler has not been doing ;0 They won't make LSL a lot faster but they could save a lot of space in script memory usage

It would be great to be able to merge the scripts into one file, even better if the resulting file had the name of the script and the creator's name, followed by the script itself. If I had such a merged file I'd post this somewhere, wherever it would be most useful.

From what I understand, (though I could be wrong), it's almost impossible to encrypt the cache in a way that information cannot be retrieved. The simple reason is, at some point, an object is rendered on your screen - therefore, it's in the cache in a presentable form for your viewing pleasure.

This issue is mostly about growing up and supporting the community instead of the implications that lead to discussions like this.

Because you need to be able to see them on your screen.


It's flat out impossible. There is no technically possible way to deliver textures to users in such a way that they can display them but not copy them. You can fail to provide them with easy interfaces to the tools to do it, but you can't possibly prevent them from using their own interfaces or tools to do so.

No encryption exists that can avoid the fundamental fact that in order for users to be able to see the textures, they must be given all the tools necessary to decrypt them, including the decryption key. You can try to hide it, but your client program needs to access it sooner or later, and people can read that program code.

Technological barriers to copying are never good because they can't possible be any good while still allowing users to see the content. People who sell copy-protection and content-protection schemes are invariably snake-oil merchants, and people who believe such things are technically even possible are invariably gullible. It's like a perpetual motion machine. A lot of people would love to have it, too bad it's not even theoretically possible...


The only thing wrong with your statement is the word "almost".

Remove graphics card, shut down machine, etc. Most things along 'render the renderer useless'. I'd find myself hard pressed to find a method of retrieving said information were any of these in effect. ;3

Social problem, meet technical solution. I'm sure you guys will get along just fine.

There is one ***EVIL*** way that LL could lock down textures: the Image Constraint Token on HDMI (I think...) systems. But that's baaaaaad, evil DRM. And most people don't have HDMI-ready graphics cards/monitors.

and even hdmi is crackable, like everything else if itsnot on a computer at ll it is not secure, plain, simple

I believe it would theoretically be possible given the "secure processors" technologies they're working on. The way I understand this works is that Second Life registers itself as a secure process, and after that, you can't access any of the system or graphics memory it's using - the CPU won't let you. The only way around is to build your own CPU.. and if you somehow managed that, then Second Life won't start up on it because its program is encrypted and the key to decrypt it given only to manufacturers who confirm their CPUs enforce security.

Unfortunately from the sound of it there is a lot of other nasty politics going around concerning this technology, the most obvious example being that it would be a technical - not just a "network effect" - phenomenon locking in Windows forever more.

<yawn> Wake me up when this setup can't be easily circumvented with a CPU emulator. (A variation of the classic "man-in-the-middle" attack.)

If the user can see it, the user can copy it. You can try making it less obvious how, but it's not even theoretically possible to make it impossible, because if the user can see it, the user can decrypt it. They have to be able to, in order to see it to begin with. You can't put any real roadblock in their way, all you can do is make speedbumps. No system can make it impossible to decrypt without making it impossible to see, period.

The problem with "secure processors" is it's a lot of expense and effort to go through for a bit more snake-oil.

Encryption protects the contents of a conversation between a sender and receiver from an outside attacker.

The funny thing about combining encryption with DRM is that our receiver and attacker become the same person.

It is hilarious to assume that you can send a message to someone and then have them be *both* unable and able to read it.

The soultion to this problem can not be technical.

Your CPU emulator can't run the code because, not being a CPU that's been authorised to run secure applications, it can't decrypt it.

Texture ripping tools get the textures straight out of video memory, using industry standard OpenGL tools. The texture cache on the disk has absolutely nothing to do with this process, and because it's OpenGL being used to extract the textures, turning off the ability to do this would also turn off Second Life.

Nothing else to see here, move along, move along...

If all the people that keep whining about this would stop uploading textures LL may notice and take some sort of steps(read non-technical) to combat this. Untill then I doubt they do anything.

About the only thing they can do is have a person look at the two textures and make a judgement call.. there is not an encryption or watermarking solution that cannot be bypassed in some manner.

Even that is an ugly solution as has been mentioned in the past... just because you uploaded it first doesn't mean you created it. Your best(and only) course of action is a DMCA takedown notice.

Personally I am against LL stepping into this at all... I can see this being used abusively against people who happen to have the same texture collection CD's as me and use or source textures from it... or Google image search and so on. So really in the end, LL has no way to know for sure where a texture came from and who rightly owns it. This is why they are doing the right thing, taking a step back and letting the legal process do it's thing.

Here's a thought.. if you are so worried about someone else getting a copy of your image, keep it to yourself where nobody will ever get it. Short of accepting the fact that anything you send across the internet that winds up in a viewable/readable/listenable/watchable format can be intercepted and saved you will just be setting yourself up for frustration.

Quoted for hilariousness

ll should certify people who want to upload transferrable textures. if you have too many dmcas filed against you, then you risk losing your certification (which could have a bond associated with it as well).

see here for more information:

/108/f4/126017/1.html

I agree, this thread is great.

Eh, HDMI is crackable with a small beowulf cluster. For updatable software, that's enough of a barrier. For dedicated hardware that almost never gets updated, which is what the HDMI spec calls for...