[sldev] Cache politics: performance vs obfuscation

[Jason Giglio]

Dale Mahalko wrote:
> The best possible caching performance would require storing raw data
> in ways that would make it all so much easier to "rip" and reuse
> copyrighted assets without the creator's permission.

It is not difficult now.

> This whole secondary decoded image cache discussion... will LL's
> senior developers allow this project to exist in the release viewer?

Linden Lab is not accepting *any* outside contributions currently.  That
said, if it really does perform better, I don't foresee them not taking
it because of some concern about the perception of easier ripping.


> JPEG2000 seems to have two purposes. Not only does it allow high
> compression, but it isn't a widely accepted image standard, so the
> texture cache as designed now is somewhat protected and obfuscated by
> locally caching bitmaps that way.

JPEG2000 has wide support in many applications.  It is in no way
security through obscurity.

> Decompressing JPEG2000 straight to video memory helps to hide the raw
> data from casual ripping. This is easily defeated with that OpenGL

That is not the reason it is done that way.

> A raw decompressed texture cache would be ridiculously easy to rip.

The current cache is just as easy.

> Can you imagine casually browsing to the SL cache folders with Windows
> and having it auto-create thumbnails of every single cached image? Or

Who cares?  A small utility anyone can write in a few hours can do this
today.

> having the texture cache folders imported into Picasa's catalog? There
> are people selling high-value avatar skins and sculpties who would
> probably have an apoplectic fit if they saw this.

I doubt it.  People that make a living selling these sorts of items are
well aware by now that they will always be easily copied.


> The VFS is another obfuscatory layer. As designed it is a RAM-disk,
> read into memory only when the client starts up, and it isn't written
> to the disk at all while the client is running. It consumes precious

This was never the intention of the VFS.  The VFS was created due to a
perception at Linden Lab that filesystems were not good enough to store
cache files.  It was kind of strange logic, but I guess at a time when
FAT32 was still common, it might have made sense.

> I think we'd be much better off to use the new folder-based texture
> caching system to store all asset types, and completely cease the use
> of the VFS and its totally-held-in-RAM design.

It is already mostly this way.

> A move to a local MySQL database may be needed not only to merely make
> the asset cache scalable and more efficient, but more importantly, to
> preserve the local asset storage obfuscation layers.

This is probably the stupidest thing I've ever seen you type. :)  Such a
solution is very much not scalable.  Databases store structured
relational data, not files.

-Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3253 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080609/5182c2bd/smime.bin