[sldev] Cache politics: performance vs obfuscation

Thordain Curtis thordain at thordain.com
Wed Jun 11 21:40:36 PDT 2008


On Thu, Jun 12, 2008 at 12:27 AM, Tateru Nino <tateru.nino at gmail.com> wrote:

> Every encoded asset would have to be recoded. You'd also need to then mark
> which assets had been recoded and which had not. "On the fly" in this case
> would mean "Stop and rewrite hundreds of megabytes of data before
> continuing"
>
> SignpostMarv Martin wrote:
>
>> Why not get the key via caps ? Then the key can be changed on the fly,
>> perhaps even during the same session.
>>
>>
Ya... using the method described in preceding messages, changing the key on
the fly would be a terrible idea.  Once the cache is cleared you'll want to
maintain the same key until (at the very least) a new client is installed or
the user manually clears the cache.  I suppose a new key could be generated
each time a client is installed (or the user clears the cache), but then
this key would have to be stored somewhere, which adds little to no extra
security over using a globally used key per major client revision.

Remember, this type of "protection" is designed to stop only casual attempts
at asset piracy.  By storing the assets in a non-standard format and
obfuscating their contents you are ensuring that a person can't just browse
the directory and throw a file into Gimp or Photoshop.  Doing much more than
this is like adding 4 extra deadbolts to your front door.  You might stop
some trivial thug from kicking in your door and nabbing your laptop real
quick, but for a skilled thief it'll just take them a bit longer to pick
them all (or go in through your window).

In the end, the idea here is to speed up cache retrieval and image decoding,
while at the same time continuing to offer some measure of deterrence
against would-be thieves
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080612/2e4fcc05/attachment-0001.htm


More information about the SLDev mailing list