[dave at farber.net: [IP] Intel quietly embeds DRM in it's 945 chips firmware]

[Eugen Leitl]

----- Forwarded message from David Farber <dave at farber.net> -----

From: David Farber <dave at farber.net>
Date: Tue, 31 May 2005 08:17:59 -0400
To: Ip ip <ip at v2.listbox.com>
Subject: [IP] Intel quietly embeds DRM in it's 945 chips firmware
X-Mailer: Apple Mail (2.730)
Reply-To: dave at farber.net



Begin forwarded message:

From:
Date: May 31, 2005 1:15:49 AM EDT
To: dave at farber.net
Subject: Re: [IP] Intel quietly embeds DRM in it's 945 chips firmware



Dave Farber:  Please remove my name and identity from this mailing,  
due to fear of reprisal. (I still work in the entetainment business  
from time to time.)

I do not know all about Intel's DRM, but I do know more, perhaps,  
than I should.  What I do know is that Intel has been working very  
closely with the entertainment industry on a DRM that, I've been  
told, seeks to satisfy EVERYONE'S wishes.  Of course, such a system  
would mean, by definition, that it will satisfy either no one, or  
only the studios.

But I do know that the Intel "dream" DRM system would allow content  
to be moved from one platform to another on a network, presumably  
through a check-in/check-out procedure, to make sure only a limited  
number of (legitimate) copies would be made and in service at any one  
time.  Intel's system also acknowledges, for example, that a high- 
resolution (e.g. high definition video) copy of a film could be used  
to create low-res (like Quicktime, Real or Windows Media) versions  
that could be used in portable video players.  Users might even be  
able to "loan" time-limited copies or be allowed to make a small  
number of copies, like Apple's Fair Play DRM permits.  You can check  
out Intel's ideas for such a system, and the participation of an   
entertainment and consumer electronics industry panel called the  
Digital Home Working Group, on which Intel sits, which has been  
addressing such a system in this article from February, 2004:

http://www.infoworld.com/article/04/02/24/HNbarrettdrm_1.html

(Note: The Japanese system for hard disk and DVD recorders that  
Barrett alludes to is called CPRM.  It is neither new nor flexible,  
and there has already been some consumer backlash against it in  
Japan, where it is used for the transmission of digital TV b'casts --  
sort of their "broadcast flag.")

At the root of the problem, of course, is the personal computer  
that's used as a media player platform.  This is also, not  
coincidentally, Intel's cash cow.  Such a DRM system, with the PC  
playing a pivotal role, would also mean that IBM or other chip  
vendors would not be allowed to play without building in the same  
chip-level protection.  Without these important security pieces,  
Apple, for example, would be cut out of the picture for playing  
content protected by the Intel-endorsed DRM, as would (most likely)  
Linux-based devices.

This is a GRAND PLAN that relies on it being either almost completely  
transparent to consumers (like Apple's Fair Play) or simple to  
understand.  Unfortunately, almost no DRM is easily understood by  
consumers.  Even most of the customer's for Apple's iTunes Music  
Store only become familiar with the terms under which they've  
purchased their music when they bump up against the limitations that  
have been set.

The real nightmare scenario, in my opinion, is a world in which  
several such DRMs co-exist, creating a chaotic environment in which  
you never know whether content will play on one plaform but not  
another.  This is a potentially really sticky mess.

-------------------------------------
You are subscribed as eugen at leitl.org
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07100, 11.36820            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20050531/805eb2b0/attachment.pgp>