[sldev] How Far For Security?

[Buckaroo Mu]

How about this, then - to the same thing we do now, storing the header 
in the binary cache, and the bulk of the data in a raw file - just 
change it from a (CPU-intensive) JPG2000 decode to a (CPU-cheap) TGA or 
whatever raw format the client uses inside the code? Or even if you just 
stored the first (arbitrary-number) of bytes in the textures.cache file, 
with the rest coming from the existant UUID-named file? The bottleneck, 
as I have demonstrated through the use of a RAMdisk cache folder, is 
definitely the decoding.

-Buckaroo

ps - 'scuse my top-posting, I know it's frowned on, but damnit, it just 
makes it easier to read. -b

Jake Simpson wrote:
> I'd just like to make the point that a lot of LL reads these threads 
> and we have lots of internal discussions about exactly stuff like 
> this. We have one currently going regarding a feature we are talking 
> about adding thats very much along these lines.
>
> "How far do we go to obstrufacate the data stream?" is the question.
>
> Bear in mind that some of the economy of Second Life is built upon 
> people being able to build and have some degree of confidence that 
> what they build won't get ripped off immediately by those who can, so 
> they can be sure of getting some return on their investment of time. 
> I'm sure you can understand how many in LL will be sympathetic to this 
> thinking. Sure, technically anything can be reversed engineered (save 
> scripts since they don't come to the client in any way) so the 
> question becomes "how hard do we make it?" (or even "how hard CAN we 
> make it?") - which is basically paraphrasing what's already been said 
> in this thread. Stating "Well, because it's possible, don't even 
> bother trying to stop it" doesn't (unfortunately) solve the issue of 
> "how can I protect what I make" which is the root cry of anyone who 
> spends time building things; it just undermines the Second Life 
> economy to the point where it might potentially not be viable, 
> obviously something people within in LL are keen to avoid.
>
> Please understand we are having the same discussions internally and 
> what is said here is taken on board by those making the internal 
> decisions, so keep at it.
>
> I'd like to rename this thread since it's quote a contentious name.
>
> Cheers
>
> Jake
>