[sldev] Cache politics: performance vs obfuscation

Thordain Curtis thordain at thordain.com
Wed Jun 11 14:09:28 PDT 2008


>
> Argent wins the thread. Most are either completely downplaying any sort of
> deterrent to theft and actually encouraging it, while the other side is
> proposing ridiculously complex encryption specifications which would
> severely harm the ability of SL to function.
>
> Argent's proposal is balanced enough to make everyone happy. Sure, anyone
> with can get past a "Hello World" program will be able to break it. But the
> point is, 90% of SL users can't get that far. So as a deterrent, it will
> prevent casual misappropriation of restricted materials.  On the other end,
> it won't severely hamper anyone from doing whatever 'ubercool' stuff they
> want to do.


Agreed.  Using a slightly obfuscated raw texture format for cache will
prevent the usage of the cache files in any image editor (as written to
disk), and should speed up decoding in the client.  As an additional
measure, LL could consider changing the XOR key with every major release and
clearing the cache (many versions do anyways).  At least this would force
all the pirates to re-download their "decoder software" every month or so.

I do have to agree with Strife that the amount of benefit for such a large
overhaul might be minimal.  There are clearly more important things that LL
wants to be working on.  As it is written, the cache system works.  The same
thing cannot be said of other portions of the platform, and I think they are
trying to divert the majority of their resources to these other critical
issues.

As far as the proposal for implementing asymmetric encryption for assets...
It's a moot point until a major graphics chipset vendors starts working with
it.  Even if Linden Labs were to convince NVidia to create such
functionality, it would likely be years before it appeared on the market,
and nearly a decade before LL could say "OK....we're turning off support for
non-secure cards".  Not to mention the asset server would have to custom
encrypt every single texture request with the client's graphics card's
public key.  This would increase the asset server's work load by an order of
magnitude, and last time I checked ..... we don't want that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/27699903/attachment.htm


More information about the SLDev mailing list