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

No really, I want to know.

Why is it so easy to retrieve textures from the Cache and how hard would it be to protect it.

Seriously.

Everyone wants to know.

Thanks,

Johnny Mann

I thought the files are encrypted in SL client cache, actually.

Are you sure you aren't confusing SL client cache file with 'cache' of graphics card, which is what the unmentioned external texture ripper taps into to get its work done? o.O;

Actually both.

You can easily open and look at the SL Cache with ((program name omitted))

There is a minimal amount of encryption on the current cache, which has been broken, and is one of the sources of stolen content that is popping up all over SL. Unfortunately, it is kind of an arms race - they could add more encryption - but the more encrypted it is, the more time it takes to decrypt the files. Since the cache is used for (supposedly) quick access, anything added would slow down access even more. It's a difficult situation, unfortunately. One thing potentially they could do is to have the client use varying encryption techniques at random, and to regularly change them with each update - it would be sort of a cat and mouse game, but it would definitely make it much more difficult to create tools to operate on the cache.

Yay for LL not enforcing the TOS and stopping reverse engineering where and when they can.

No matter how much you encrypt the textures, your PC needs them unencrypted before your graphics card can display them to your screen. There's nothing that can be done to stop that level of interception short of nerfing everyone's graphics.

However, embedding watermarks or digital codes that don't affect display might be one solution, if LL ever decides this issue deserves time and attention.

THIS is the true weak spot of enforcing IP rights on textures. As Cindy pointed out nothing can be done about it.

Since there is no immediate technical solution, all we are left with are social solutions (i.e. DMCA reports and the like).

If the watermarks and codes Cindy proposes can be put in (and they have to be implemented on the asset server) then maybe we have some technical solution.

encrypting the disk texture cache: easy
encrypting video memory: hard, and not LL's balliwick

conclusion: what's the point of putting effort into disk cache encryption, when video memory dumping is so much easier and functional.

It sucks, but it there really isn't anything LL can do to help. Bug ATI and nVidia.

Sorry, I'd rather not have more DRM added to my hardware, even for this, kthx. Besides, this is way too small potatoes for them to care.

Yeah, they won't care. For 99.9% of the applications that use their hardware, ripping textures isn't really problematic; the games companies don't really care, and speed is an issue. The hit on performance from a hardware encryption/decryption routine would knock them down on the benchmarks and hurt their sales and they're clearly not having that.

Incidentally, I would like to say how much, much better SL looks now that I've moved from a G4 Powerbook to a PC with an GeForce 7600 GT. I never realised quite how much was being done client-side. I apologise whole-heartedly to the asset server.

On bugging AMD, and NVidia on this.

High atop a huge sky scraper, overlooking a cityscape, the president of the board is sitting in his office having his martini... when an aid in thick glasses and a clean black suit enters.
Aid: "Sir, some users of a game wish for us to add video encryption for OpenGL support of our existing and new video careds..."
Boss: "Users?"
Aid: "Yes sir..."
Boss: "So... not id software, or Valve?"
Aid: "No sir..."
Boss: "MPAA maybe, they love harassing us to add DRM..."
Aid: "No sir... like I said, users."
Boss: "Users don't ask for DRM features, users play the games, bug me when there's something to justify my attention..."

This has been perspective theatre with your hostess Ice Brodie.

No.

Can't be done.

Would require a full re-write of the graphics API.

Please don't. We're talking of tool which is primarily made to allow programmers debug drawing code while they develop games and/or applications. Yes, some people can use it to steal textures. But that's just like some people using code debuggers to break other people's code -- you don't see programmers cry to have their primary tool broken because of few 'bad apples', do you? :/

And not LL's portion of the API. but the Open GL layers.

No.

hehe, good point, but I was thinking less of encrypting the texture memory, and more protected mode memory access.

i don't understand that really , how peoples believe that everything can be protected with a technical solution. THe minute the data arive on a computer you don't control is the minute your data isn't protected anymore,

live with it.

your only protection is a legal one

There can't be that many textures stored in my client's cache that need protected as I go to the same places yet still have wait ages for the grey squares to fill in even though I've the cache size at max. A bit of a worry for me as I've a monthly download limit set by my ISP.

we don't believe everything can be protected via technical means... we just happen to think saying our only protection is a legal one is equivalent to saying we have no protection . In a technical sense there is no way to prevent people from doing whatever they want to data that they have access too. However, if the protection is done at a hardware level the number of people with the technical expertise to bypass it decreases drastically.

Very true. But to implement that would bean rewriting the very standards that make the PC industry work. Plus it would break SL for anyone who does NOT have that hardware, since to ensure hardware-level protection a person would have to have that hardware, so SL would have to be prevent from running on non-protected hardware. Hardware-level encryption is even more difficult to create/implement than software. You're talking 4-5 *years* before the market penetration is great enough for it to be practical, and that's if it was adopted immediately by all the manufacturers.

Really, you're looking at 10 years or so before hardware-level content protection will be practical.

Software will be the first step, but again, to prevent the useage of software that can read video memory, you're going to have to change the industry standards used for communication to/from the video card. This isn't going to happen voer night, and as was pointed out before, there would be a *HUGE* resistance to this from the very people who write these standards. Is it impossible? No. But you're still looking ate 5 or more years before you'd see this exist, and more for it to become practical.

The biggest hurdle of all is what foild both of these schemes. If someone REALLY wants to strip the textures, they'll just use an unprotected machine.

I don't think the problem is the actual theft, its whats done with said stolen artwork after the theft.

LL can and should be punishing people - and doing it publicly. Rather than what they are currently doing, which is sod all.

People get too hung up on the theft part which they should just forget because its out of LL's control and always will be.

I agree. We need LL to care about this when it occurs, order a cease and desist and implement punishments. People get suspended for name calling on these dopey forums and for a lot less, whilst thievery goes on without punishment. I don't blame LL that texture theft is possible. It is a fact and I see little they can do to prevent it technically, but if stiff punishments were implemented it might deter it from occuring.

This thread so so so funny

One high-profile reverse engineering system (since it's cool nowdays to not name names) is working on asset downloads. I know it works for creating and retreiving notecards (fron one's own inventory), so textures may (or may not) come soon.

I believe texture requests already work ;0 If i'm not mistaken