[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