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

[Dahlia Trimble]

Following this path may be quite difficult. Many countries including the US
have laws restricting the export of encryption hardware and software. Unless
it is a trivial process to acquire the necessary approvals, I dont see this
as a viable alternative for a company with an international customer base.

On Tue, Jun 10, 2008 at 2:29 PM, Dale Mahalko <dmahalko at gmail.com> wrote:

> 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. :)
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080611/aed37507/attachment.htm