[sldev] Cache politics: performance vs obfuscation

[Dante Tucker]

The only problem with changing the key every release is a lot of people
don't use the latest version. Then theres people like myself that use there
own custom build.

On Wed, Jun 11, 2008 at 5:09 PM, Thordain Curtis <thordain at thordain.com>
wrote:

> 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.
>
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/c03b3858/attachment.htm