[sldev] Cache politics: performance vs obfuscation

[Strife Onizuka]

I've been playing with the client cache for years. Yes I said years.
Three years ago I wrote a tool that converted the VFS to a tar
archive. It then became trivial to open it in WinZip (which handles
large archives really well). It was during this time that I reverse
engineered the asset formats. At the time I opened a dialog with LL on
the issues of asset security, and so I was asked the question: "No
matter what we do, people can still steal assets, so why bother doing
anything?"

The problem is, to render an asset it needs to be in raw form. Even if
you encrypt the data stream and caches, the weak link is the end of
the chain where it gets rendered. There is no point in hardening the
front door when the back door is hanging off it's hinges.

LL will do what ever is easy and will provide good performance. The
question I have is this: Is it faster to read a decoded image from
disk or read a JPEG2000 encoded image from disk and decode it?

With the steady increase of the number of CPU cores in a system,
allowing for more simultaneous threads, is it really important?

On Mon, Jun 9, 2008 at 4:36 PM, Timothy Horrigan
<timothyhorrigan at mac.com> wrote:
> Robin Cornelius wrote:
>>
>>
>> just to pick a few, not the example i was looking for, there is/was
>> one somewhere with a pile of votes saying remove the texture console.
>> And this noise is heard so often and often gets associated with
>> anti-opensource.
>>
>> There are no real usable technical solutions to content theft, nothing
>> technical really works anywhere. As far as i see the only solution is
>> the social one, where people have the respect not to just rip stuff
>> off and thats a whole bigger issue than just SL.
>>
>>
>
> Anytime you make content visible to the public, you are running the risk of
> them "stealing" it.  Even if you make direct copying impossible, they can
> just reverse-engineer it.
>
> In the case of SL, the textures are "stealing" space on my hard drive, so I
> should be able to look at the cache files :-)
>
> I liked the people who wanted to eliminate the texture console. even though
> they were unable to explain how the texture console would actually enable a
> user to rip a specific console.
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>