[sldev] Cache politics: performance vs obfuscation

SignpostMarv Martin me at signpostmarv.name
Wed Jun 11 16:51:14 PDT 2008


Why not get the key via caps ? Then the key can be changed on the fly,
perhaps even during the same session.

~ Marv.

Dante Tucker wrote:
> 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 <mailto: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.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3249 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080612/dfd88cb8/smime.bin


More information about the SLDev mailing list