3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible")

[Dale Mahalko]

On Tue, Jun 10, 2008 at 4:48 PM, Kitty <sldev at catznip.com> wrote:
> Wouldn't that just make it impossible to still take snapshots in SL? Or
> something like machinema?

A protected output channel that only produces watermarked snapshots
would help to prevent asset theft. In the case of screen recorders,
perhaps there would be a way to watermark the entire screen
continuously in real-time so that any captures are already protected.
(Is it possible to watermark an image "captured" by photographing the
screen with a digital camera?)

With regard to GL-Intercept, perhaps a modification of OpenGL could
appear, called "ClosedGL" or "DRM-GL", which functions only inside the
encrypted space and without direct output capability to local system
memory.


> It also wouldn't stop texture UUID grabbing/reuse, so would it actually make
> any significant difference that's worth what you'd be giving up?

The overall texture-access system might need to be changed to
accommodate a more secure environment. Why should you have access to
textures you don't own? It is currently done this way because the
client must be able to request textures for every object you see in
world, and the asset farm doesn't explicitly know in advance what you
"need to see". But the current design model could be changed for a
future virtual world.

The current model is geared for heavy bandwidth usage and light cache
usage, where primitives are separate from their textures, so that the
prims can load first and textures appear later. If local caching can
be enhanced to be huge and fast to reduce the network dependency, then
there is no need for a primitive to be separate from its component
textures.


Put the primitive and all its textures into a single encrypted asset
package that gets stuck in the local cache. When it is to be
displayed, this package is loaded into the protected space and the
included assets are used with the primitive -- but the user of the
client does not have access to those textures to copy them, and
doesn't know the UUIDs either since those are inside the package and
not externally revealed.

To load an object just requires a simple internal reference list, and
doesn't need UUID references. "Stored texture at position 1 is applied
to all faces of primitive in position 2, in this package."

Under such a model, the clients don't even need to know individual
UUIDs of objects within a package, to be able to manipulate the
package contents. The LL sims can change a texture on a prim's face,
by reference to the encrypted package ID: "Apply texture #2 to prim #4
in package X. Change the transparency of prim #23 in package Y." UUIDs
may be used in the scripting for simplicity, but becomes an abstract
reference for the client, which only knows the encrypted package ID.

This does not add additional processing per client, since all clients
can use the same offset references to items within a package, and the
package is the same across all clients, so the references can be saved
into the asset data in the LL asset farm when the encrypted package is
created or edited by the asset owner.

Encrypted asset packages containing textures, linksets, prims, and
sounds would also better fit the multiverse model since there is no
need for a global asset farm to store all "your" stuff. Your avatar
could cross over to another space with all its protected data held
within this single asset package.


For this design, the asset downloads would be larger, as unified
packages. But if the cache size were in the tens to hundreds of
gigabytes, and fast and efficient, then only a single download is
needed and that package does not change or need to be redownloaded
unless the content creator modifies the package in some way, which
requires a new updated package in the cache and expiring the old one.

So the initial visit to somewhere would need the assets to load
completely before the objects can appear, but the asset packages would
never need to download again after that initial visit, if sufficient
disk cache space is available.


Some form of the current open-access texture UUID system could
continue to be supported, but would be redesigned to explicitly warn
content creators that their work will be unprotected and can be easily
stolen if they use the old asset mechanism.


- Scalar Tardis / Dale Mahalko