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

[Dale Mahalko]

I am of the opinion that this discussion belongs on the developer
list, because as yet we still don't seem to know what is the best
direction to take regarding the handling of cached assets. The current
somewhat obfuscated solution isn't the greatest in terms of
performance but it is there and it works for now. We and need to
figure out what direction to go if that is going to change.

I see the coder-geeks complaining about people like me not
"contributing code" and so our participation is deemed worthless, but
you cannot launch straight off into writing code without knowing what
it is you're supposed to be doing, or if LL is philosophically in
support of adding it into the client codebase.


I will mention that on the old SL forums years ago I was discussing
the possibility of a 3D video card with a dedicated, isolated memory
space and a public/private key DRM model. Textures would be sent from
the grid to the client in a pre-encrypted form, stored in this
encrypted state in the client cache, and only decoded inside the
protected memory space of the 3D card. By pairing this with HDCP this
would create a secured digital pathway for assets to be reasonably
protected from theft.

Of course this was attacked in the forums as untenable and that "it
will be hacked and you cannot stop it", which is not the point. The
point is that it creates a similarly locked front door metaphor. As a
thief you must be willing to go to some measures to break this
protection in order to steal the content protected inside, and which
gives a lawyer a definite case for prosecution since it isn't like the
files sit in a raw format in a folder just waiting for Picasa to
stumble across it and unknowingly catalog it.

Since there are now only two significant players in the 3D card
market, nVidia and ATI, it would be relatively easy for a copy
protection mechanism to enter the marketplace and silently slip into
place, as is already happening now as HDCP is replacing old non-HDCP
cards.

The overall performance may suffer somewhat due to the heavy
encryption, but this would give content creators the legal protection
they need to prosecute potential asset thieves. Besides with 3D cards
now pushing 1 gigabyte and more of onboard memory plus ultra-high
power processing, it's not like there would be a huge step back in
performance.

Perhaps a dedicated decryption pipeline could be developed so that
there is no performance taken away from the main 3D chipset. And, with
no need to obfuscate the downloaded cached assets, they can be written
directly to that fast massive terabyte local folder-based disk cache
with no need for obfuscation.

Perhaps as GPU power continues to increase, more than textures could
be encrpyted. Perhaps the whole asset system could be encrpyted and
most of the client code run inside the protected space with few ways
to send raw decrypted asset data back out.

It would be interesting to see if a "write-only" physical memory could
be created, where the only way to verify data was written correctly
into the protected space is via a return path that can only provide a
checksum on the written data.

If LL wanted a protected asset pathway, this is probably the way
forward, though it would take a few years to be implemented and rolled
out to the public. I could see the MPEG-V people possibly also being
interested in this for content protection purposes.

- Scalar Tardis / Dale Mahalko


On Tue, Jun 10, 2008 at 1:05 PM, JB Kraft <kwerks.sl at gmail.com> wrote:
> I apologize to the list if this particular discussion is somewhat too
> philosophical and out of bounds to its purpose but I feel strongly about it
> as both a programmer and a musician and think it bears the consideration of
> other approaches from both the the litigators asking the programmer to be
> locksmiths and the programmers somewhat naively seeing information as
> something that "wants to be free". Knowledge may want to be free but I'd
> rather you gave me a few cents for my information/music somehow. :)