[sldev] Cache politics: performance vs obfuscation

[Dale Mahalko]

>From the mention of pitchforks and politics in Robin's other thread, I
am getting the impression that some people don't really want to
improve the local caching performance as much as possible.

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.



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

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.

Decompressing JPEG2000 straight to video memory helps to hide the raw
data from casual ripping. This is easily defeated with that OpenGL
wrapper, but the wrapper also generates a ton of garbage that must be
sifted to find the desired texture to steal, so it isn't easy to use
for ripping by any means.

A raw decompressed texture cache would be ridiculously easy to rip.
Can you imagine casually browsing to the SL cache folders with Windows
and having it auto-create thumbnails of every single cached image? Or
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.



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
limited system memory at all times, but it also helps to hide
downloaded assets in a storage system that cannot be easily snooped
with file-access monitoring tools.

As a RAM-disk, the VFS absolutely does not scale, and trying to
improve network caching performance by making the VFS several
gigabytes in size just invites virtual-memory page swapping and poor
overall system performance.

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.

BUT this would remove all obfuscatory layers of the VFS and would make
it easier to directly examine and potentially rip downloaded assets of
any type. Non-texture assets are probably all in their raw file data
formats, and they would be laid bare and helpless in a folder-based
cache, so LL may not be willing to allow this.

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.



The developers on this list appear to understand that ultimately
nothing sent to the client can be protected from copying and
unauthorized reuse, and this is just the facts of life. It sounds to
me like some people at LL don't want to force the rest of the userbase
to accept this reality.

We may have to continue to live with lousy local caching performance
just to help assuage the fears of the angry and irrational
pitchfork-waving masses that are still running "anti-copybot" scripts.

- Scalar Tardis / Dale Mahalko