[sldev] How Far For Security?

[SignpostMarv Martin]

Q Linden wrote:

> Personally (I'm not speaking for Linden here), I think that if we want 
> to change the way we do caching, we should make it slightly 
> complicated to grab items out of the cache by NOT storing them in 
> standard formats. 

Jason Giglio wrote:
> It's definitely a possibility.  The thing is, recompressing into another
> lossy format will lose some quality.
>
> If we are going to do that though, S3TC is probably the way to go,
> that's video card native.

Argent Stonecutter wrote:
> If you use a raw format that's efficiently decoded by the client, with 
> a header containing metadata, in an undocumented format with an 
> undocumented size, then you'll have as much obscurity as you have now 
> in a format that is perhaps bulkier but certainly will consume less 
> CPU time to extract.

If a non-standard format is used, it'll only be useful in the short term.
1) Code gets released
2) Code is either documented or becomes documented
3) Wide adoption of Second Life makes said non-standard format become 
de-facto standard for virtual worlds.

A standard image codec that is "native" to OpenGL encapsulated in a 
container format which allows metadata to be embedded that is either 
standardised but traditionally unrelated to 3D software assets (Ogg ?) 
or a proprietary non-standard format would seem preferable to using a 
non-standard image format.

Not that I am likely to develop software that would use such a system, 
but I would think that using unrelated standardised container/codec 
formats would still have a security-through-obscurity edge, since 
although all the tools for working with the individual formats are out 
there, people would have to scratch their heads while they figure out 
how to glue them together (unless working directly with the SL source 
code, which would be intended for loading assets into a 3D environment, 
not viewing/editing said assets via an image editor)


~ Marv
-------------- 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/20080610/1eaa6cc2/smime.bin